Schneier et al Report PGP Vulnerability

SpaceTaxi writes: "Researchers reported that they were able to intercept and modify a PGP encrypted message so that, IF it is sent back to the attacker, the original message could be read by the attacker." The paper comes from Kahil Jallad, Jonathan Katz, and Bruce Schneier. Here is the Yahoo! article.

Comments

Affects implementation, not the standard

[cos(0)]

The flaw affects software using Pretty Good Privacy, the most popular tool for scrambling e-mail.

Only the PGP *program* seems to be affected, not the actual OpenPGP standard. Thank god.

Re:Affects implementation, not the standard

[Surak]

By your theory, we should eliminate passwords...let's examine your logic:

Typical users of password-locked software are not educated in good security practices; it is therfore important to design robust software who's secure is not comprompised even passwords are used in a naive manner.

In other words, passwords aren't good enough because because stupid people pick easy-to-guess passwords.

Better start using biometrics I guess. :)

repeat after me

[Anonymous Coward]

Security is a process, not a technology.

What are they teaching you kids in school these days? Let's try that again:
Security is a process, not a technology.

If Typical User of E-Mail Encryption Software is not educated in good security practices, then there's no technology in the world that's going to help him out. Plug up one "naivety" hole? Wow, I guarantee you he'll find 100 more. Teach him about security processes, not technologies.

Human factors

[Beryllium Sphere(tm)]

Yes, given that human error is inevitable, it's important to design systems to limit the damage it can cause.

The aviation industry has been doing that for generations.

The aviation industry has also put enormous effort into educating pilots so that they make fewer errors. There are some errors that can't be contained or corrected, like flying into a mountain range or failing to check the fingerprint on a public key.

This is a very specialized attack

[Featureless]

It hinges on being able to intercept a message, add some random data to the encrypted blocks containing its payload, and then for the recipient to decrypt it, and respond "hey Ed, what's with this garbled message you just sent me?" with that decrypted message quoted below. And, naturally, for the attacker to be able to intercept that response as well.

The basic idea of a "chosen cyphertext" attack is that if you can see a decryption of blocks you mangle, you can work backwards to get the plaintext in the unmangled blocks. You might consider this an attack on the user interface or the protocol rather than the algorithm. You should just never be quoting failed decryptions...

The talk about compression preventing the attack is not referring to the compression of cyphertext by you (i.e. ZIP'ing the payload before sending). That doesn't make a difference. It involves the DEFLATE compression the PGP/GPG software applies (and it generally does so only for uncompressed plaintext) both before and after encryption. You may already be realizing, randomizing compressed data will cause the decompression to fail with an error; that will make it much less likely for the user to disclose the failed decryption.

Fixing this is a good idea. Until it is fixed, if someone sends you garbage, don't reply, or if you do, don't quote their message in your reply. However, this is not the end of the world. The foundation is still sound, the attack is only useful on a per-message basis, and your keys are not affected by this strategy.

I do have a question for the crowd; it seems to me that this is an attack on "encrypted" messages, as opposed to "encrypted and signed" messages. I am assuming that the use of signatures will also foil this attack, but I would welcome comments from others on that subject.

Re:This is a very specialized attack

[Featureless]

Thank you. That's what I figured.

I'm not feature-for-feature familiar with the various versions of PGP and GPG, but their paper did make the claim that GPG does not do compression for already compressed plaintext (.zip,.gz,.bz files?). Obviously that statement is short on detail, and as I think we're realizing, this is all pretty academic anyway, but what they're doing is very good - they're being extremely thorough, and considering every angle.

If they hadn't pointed it out, I'm sure a number of people including myself would not have considered the threat of disclosing "failed" decryptions.

Re:Bad Headline!

[Thorsett]

No, the primary author of a scholarly paper is always listed first, and authorship is generally sorted by merit.

Being the author of some scores of scholarly papers, let me assure you that there are no rules about author order, even within fields. Some particular group may have its own patterns (ie, we tend to put the lead student first), but it is usually impossible for an outsider to know for sure without asking. And I don't even know what you mean by "merit." The person who crunched the most data? The person who raised the most money? The person who pointed in the right direction and then stood out of the way? The person who spent the most nights writing code? The person who massaged the work into timeless prose? The person with the most famous/attention-getting name?

There are really only two things you should infer from an author list:

1. every author contributed something essential to the work described, and
2. every author has read and approved of the paper (unless explicit disagreements between authors are noted, as sometimes happens).

(Unfortunately, there are a number of famous cases where rule two breaks down, usually involving a senior scientist taking a share of a junior scientist's work while forgetting that they must also share the risk and blame if something goes wrong. So maybe there is only one rule.)

Re:Common sense???

[SirSlud]

Oh, there's always perfection to strive for - its simply a matter of weighing the cost of making some foolproof vs. placing some amount of onus on the user to understand the scope and mechanics of the tool they are using.

Personally, I think the smarter and more transparent you make tools, the dumber people are allowed to be. In that respect, I'm very wary of fully transparent solutions for the simple reason that once you become sufficiently detached from the mechanics of a tool, you become *much* more susceptable and vulnerable to social engineering (cause your brain isn't used to the mental safety checklist of your actions), and more vulnerable to being a victim of an attack and not knowing it. I think you should only the take "The Technology Should Be Fully Transparent" route if you are 100% sure you will never introduce a bug into that technology and expose unprepared people to social/tech engineering exploits.

I guess that makes me an elitist, although the argument has held up pretty darn well in the physical technology world ... I prefer the term realist. People are never going to be perfect, but the more foolproof you make the technology, the more people are free from any responsibility or accountability from accidents stemming from the use of the tool, even if that accident ends up having been easily avoided with a little common sense.

This also brings up a more interesting point; should this kind of technology be accessible to somebody with no investment in education of encryption tools and concepts? I believe that anybody who requires truely secure communication, from your CEO to your Anthromorphic Fetisher who's terrified those jocks in dorm room 4B are going to sniff his porn emails might consider that some investment in learning the tools that will offer them protection are simply a fair cost of requiring a truely secure communication pipe. Thats also the conclusion that the physical technology world made - generally, technologies with smaller user bases require more training to use those technologies, simply because the cost to foolproof-ize that technology isn't worth it given the low amount of users.

All that said, to be honest, I don't use PGP, so I'm really not aware of the installed user base, nor the various pros and cons of trying to entrench PGP to Every User and Every Desk. Is that truely the intended goal? Secure communications for every email flying about? Sure seems like alotta wasted cycles ... =)