Slashdot Mirror
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.
leaving the door open for instances like this.
PEBKAC conquers all, as usual.
Cretin - a powerful and flexible CD reencoder
If you had read the article, the program isn't really flawed either. This is a case in which a human can be fooled into sending decrypted garbage back to the villian, who can then do his decryption to get the original text of the message.
I'm not sure the software should be able to prevent this. Of course, it would be nice if it did, but this is just one of those common sense things that hopefully users of PGP will be smart enough to understand.
I could always reply to the sender of an encrypted message and say "could you send that to me unencrypted, I can get it to work." If they fell for it and sent it to me unencrypted, you could say the software failed, I suppose, but really it's the human's fault.
My Karma was at 49, then they switched to words. All that work for nothing!
Every day it seems like there is some new vulnerability discovered in one of our beloved secure communication tools/protocols (PGP, SSL, SSH, etc). This really hurts me a lot, as I feel my trust has been shattered.
For this reason, I ask... no beg... all hackers, researchers, programmers, etc to please stop reporting these security problems. Find something? Keep it quiet! Don't tell anyone, and then no one will know, and we'll all still be safe. Maybe in a few years, you can quietly patch it up, and we'll all go on like nothing has happened. Sound good?
Let's all follow Microsoft's lead on this one. Thanks guys!
The abstract of the paper suggests that the attacks largely fail when the data is compressed before encryption. From the GNU Privacy Guard manpage of version 1.0.7, the default is to use RFC1950 compression (which is ZLIB compressed data format) and the default compression level of the zlib library (normally 6). Note that all this applies to GNU Privacy Guard 1.0.7. According to the same manpage, the NAI PGP implementation uses RFC1951 compression, which is the DEFLATE compressed data format.
Banu
Yeah, this exploit falls under the 'social engineering' side more than anything. Who on earth would use PGP for their communications, but have no hesitations replying to suspicious email from unknown people. Even if one were to reply, one shouldn't include the body of the mail in question out of sheer para^H^H^H^Hcommon sense!
"Old man yells at systemd"
Errata from the desk of Bruce Schneier: Pay no attention to p. 584-587 of Applied Cryptography - 2nd Edition... I didn't know what I was talking about... now I do.
come on fhqwhgads
Imagine a user who has configured his software to automatically decrypt any encrypted e-mails he receives.
An adversary intercepts an encrypted message C sent to the user and wants to determine the contents P of this message.
To do so, the adversary creates some new C and sends it to the user; this message is then automatically decrypted by the user s computer and the user is presented with the corresponding message P
To the user, P appears to be garbled; the user therefore replies to the adversary with, for example, What were you trying to send me? , but also quotes the garbled message P
Thus, the user himself unwittingly acts as a decryption oracle for the adversary.
PGP and GnuPG use both symmetric and asymetric encryption algorithms to encrypt data. First a random key (S) is generated and the data (C) encrypted with it (giving you C'). The symetric key is then encrypted using the asymetric key (public key) giving you S'. When the sessage is sent the encrypted key S' is sent along with the data.
What appears to be happening is that Mr Schneier and buddies have figured out a way to create a data part C', so that when it is decrypted, the orinal symmetric key (S) can be obtained from it.
This means that :
Even if someone tricks you into decrypting a message for him, then that attack will only reveal the contents of that particilar message. (your private key, and all other encrypted data, is still safe)
PGP has not be 'broken', nobody can read you encrypted emails without your help.
This is not the end of PGP/GnuPG.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Can't you see that everyone is buying station wagons?
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.
My journal has hot
The fact that human intervention is required also limits the damage that can be done.
:-)
The attack would need to be repeated for every new value of the session key, or in other words for every message.
Even the most naive person, after a few rounds, would either get suspicious or stop using PGP.
There are times when disclosure of even one or two messages would be catastrophic, of course.
I'd argue that there is a design flaw here: a failed decryption should only return one bit of information, namely "decryption failed", and not provide a potential adversary with algorithm output. The subtlety is that the attack doesn't involve a failed decryption. It's a valid decryption, with correct key, of unwanted ciphertext.
Signing before encryption would be a countermeasure.
This attack lends some support to a heretical suggestion Larry Randall made on the pgp-users mailing list. He suggested restricting distribution of the "public" key to only authorized correspondents. Sounds nonsensical at first, and doesn't apply to most threat models and usage models, but he's got a point. If you allow anybody in the world to send you encrypted email, you're allowing anyone in the world to operate your decryption system with chosen input. It's like going out in public without your tinfoil hat
Please, read this article a with an eye to word meanings and English usage.
This is a setup and usage problem in the email client, not in a flaw in PGP.
If a person is fool enough to leave their keyring available to the mail client (that's what the floppy disk in my pocket is for), to not remove their passphrase from memory, and to automatically include the plain-text version of an encrypted message when replying, they deserve no security.
This so-called "flaw" in PGP is on a par with calling an OUTLOOK email flaw a virus.
As the article notes, this isn't a new attack; Schneir and Katz had a paper on the general principle two years ago; it has been up on the Counterpane Labs site for some time now.
BTW, you don't get S, the session key. You get a new message, P which is related to M in a manner you chose.
Easy example (not real life): Suppose the message C is encrypted using any algorithm in Electronic Code Book mode. To sucker the user into decrypting that, I send him a message C' which includes all the ciphertext blocks which were in the original message C (but not in the same order). He decrypts that (giving P) and quotes it back to me as a garbled message. I now build a codebook with P and C', and use that to decrypt C.
If another mode is used, as in PGP, a more complicated method of constructing C' is required (and is given in the paper), but it still works.
This is how the allies broke the German enigma in World War 2.
//begin not-so-obscure geek reference //end not-so-obscure geek reference
I'm surprised that that counterpane is reporting this as though it were some new idea, it's not.
This is the problem with programs like PGP, they're so well made that they allow a user who has no idea how they work to use them. Unfortunately, that can lead to the simplest of attacks to work.
Cryptonomicon: Waterhouse breaks the cipher used by Shafthoe et al by ensuring that the word 'crocodile' was used in the ciphertext and using it as a crib. Same deal.
Sorta' Good Privacy.
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.
Want to Know How to Cheat the GPL? Read On!
If "Kahil Jallad, Jonathan Katz, and Bruce Schneier" write a paper, the abbreviation is "Jallad et al". If Schneier is the LAST author in the list, it probably means he did very little except motivate the paper and help brainstorm.
In case anybody is actually confusing him with another Meestah Katz:
This should put the confusion to rest.
Oh, you're using IE. My condolences.
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
-- Colonel Adolphus Busch
This is a well known attack, isn't it? I can remember giving a talk on how to use PGP and telling people to never:
a) Sign random garbage sent to them by anyone (and sent it back), or
b) Decrypt stuff and send it back.
I was wrong about signing. It is indeed performed as Encrypt(Sign(Message)). Furthermore, my suggestion that D(C') would be garbled so as not to be recognizable as a signed message was stupid. OpenPGP requires the decrypted message to be a valid OpenPGP message. The paper clearly pointed out the attacker must not garble the first block of the encrypted message, which includes the header indicating what type of OpenPGP message it is. Thus, a signed message would still be marked as a signed message, and since the part after the first block would be garbled, it would be definitely cause a major warning/error.
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.
... 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.
... =)
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
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
"Old man yells at systemd"