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
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"
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
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.
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!