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.
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.
leaving the door open for instances like this.
PEBKAC conquers all, as usual.
Cretin - a powerful and flexible CD reencoder
... he hasn't posted an article since Jul 15th!
Is he still employed with OSDN??
Inquiring minds want to know!
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
ENCRYPTED.TXT ...but it is corrupt. Could you please send me a copy?
Here is my public PGP key:
First the SSL bug, now this? Looks like we have to go back to two paper cups and a piece of string for sending encrypted messages to each other...
Aw, fuck it. Let's go bowling. - The Big Lebowski
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!
Nonetheless, an update to the OpenPGP standard was to be released Monday to coincide with the announcement of the flaw. Many developers already have begun to write software fixes, Callas said.
looks like it might be a little more then something just in PGP, if they are releasing an update to the
openPGP standard.
altho i suspect PGP is the "most" vulenerable to this , It would be interesting to see what other openPGP software is really effected.
Nex6
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
I use alcohol to encrypt my email messages to specific people, people like ex-gfs, college professors, old bosses, etc. Example: Ihate tyou. WHY doaNt you JSust dddieee!@#! My MMMOOOM tlds mee yYoyu wass BadDS KNwesss. True its not the as secure as PGP but it has it's uses.
I thought he was just a bloviated wannabe essayist, not a crypto analyst. Surely this can't be the same guy...
DO NOT LEAVE IT IS NOT REAL
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
For my own sake, because I may not be reading this right:
If someone manages to get me to send (them? anyone?) a message they already know the contents of encrypted with (my?, the person I'm sending the message to?)'s private key then they can decrypt the message and (read it?, figure out the private key?).
1.) This seems pretty unlikely to work, unelss minor modifications don't bother the attack (like adding a > in front of each line of the previous email)
2.) let's say john.doe@someplace.com sends me a message and it's encrypted and signed. If I accept it and it shows that john.doe@someplace.com's signature is valid (which it must or I will delete it) then how can the attacker know the contents of the email unless they have already managed to get john.doe@someplace.com's private key? If they already have his private key, then they can decrypt any message I send to him anyhow. I don't really see how they could get my private key and at this point, if I can't trust john.doe@someplace.com and I send him an email then my comprimise is an issue of trust rather than a PGP flaw.
Please clue me in if there is anything in this that I have not really understood.
My $0.02 will always be worth more than your â0.02, so
It's nice to see someone's name in a slashdot story that you know for once. Just though I'd give Kahil some props ....
of an earlier announcement of a vulnerability here found by some folks at Bell Labs.
So is this new (albeit social engineering) vulnerability just "asking the million questions" in one shot?
"Provided by the management for your protection."
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.
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.
We just got back from our weekend on the beach. We got a little crazy and started exchanging public encyption keys. Just hit reply if you would like to see the pictures.
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.
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'll offer a second helping of props for that gold-toothed pgp-craxxor.
(INSERT EMBARASSING STORY HERE)
In the future, I would want to not be isolated from my friends in the Space Station.
Garage encryption... not difficult to acheive but dicey. That is, you can conceive of a great many encryption schemes that are trivial to the uninformed to break, thus obtaining an initial payoff. However, there is something often overlooked which can be abused. The reason why we have such old standards today is because they have been picked over and they appear to have no exploitable flaws (other than to brute force and social engineering attacks, as in this case).
Generally, two encryptions are not more secure as one. There is a theory (forget the name) that states that if some message K is encrypted by algorithm A, then encrypted by B, the result is no more secure than the stronger of A and B.
Black holes are where the Matrix raised SIGFPE
I'm confused. If party A sends an encrypted message to party B using B's public key, wouldn't party B reply to party A using party A's public key thereby making the garbled text unreadable to interceptor C?
-- Thou hast strayed far from the path of the Avatar.
How can "you should not quote a message to which you are replying" possibly be common sense? An algorithm that is vulnerable to a "social engineering" attack this simple should not be advertised as a secure algorithm. Encryption and signatures must become transparent and reliable if they are to be used by a large number of people.
I once participated in a similar discussion where I argued that headers like "to", "cc", and "date" should be included in the hash when signing a message, because people will send short messages such as "Today's meeting has been cancelled" whether you want them to or not. (I can't find that discussion now.) I was and still am shocked that the majority of participants in the discussion felt that the hole was the fault of the sender for not including enough context in the original signed message, or of the recipient for not noticing that the message lacked context and/or not suspecting that the e-mail might have been forwarded.
The shareholder is always right.
See this post.
Darnit, I thought I'd configured my prefs to filter out everything by Jon Katz but this article still got through! It's a conspiracy to make me crazy!
.
- First they ignore you, then they laugh at you, then ???, then profit.
Damnit, I thought my filter on Slashdot was supposed to take his stuff out!
CowboyNeal! Your stupid filter isn't working!
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
It's called "Secrets and Lies". Also, see the article at The Atlantic.
Best Slashdot Co
Yes, but it still fails on data that's already compressed. According to the paper (as opposed to the abstract), both PGP and GPG disable compression on data that's already compressed, thus allowing the attack to succeed.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Hotmail account picks up spam, it's good at that. I have to use IE at work because it's what everyone uses at work, and since I write web sites all day for people at work, I don't have much of a choice in the matter.
This is good work, because it illustrates the real-world importance (i.e., feasibility) of "chosen-ciphertext attacks." PGP and GnuPG are vulnerable to these attacks *by design*. It's not a mathematics problem, or an implementation problem, or a standards problem, but simply a requirements problem. Nobody thought to use CCA-secure encryption in PGP et al. Nor is anyone really to blame: these kinds of attacks weren't even formalized, nor reasonable solutions proposed, until a few years ago. It requires specialized cryptosystems, built from the ground up, to offer provable security against such attacks.
Chosen-ciphertext attacks take advantage of some kind of "malleability" in the ciphertext. For example, say Eve intercepts some RSA ciphertext C of a message M from Alice to Bob. She wants to know M, but can't solve RSA. Well, she just multiplies C by, say, 3^e (mod n) [where e is the encryption exponent in the public key] and sends it off to Bob. Bob decrypts it and gets some junky-looking message M', and sends it along to Alice, saying "what gives?" Little does he know that M' = 3M, whence Eve intercepts M', divides by 3, and viola. In reality the situation is more complicated (RSA is used to encrypt session keys, not full messages), but the principle is the same.
Chosen-ciphertext-secure cryptosystems generally embed some "proof" that whoever generated the ciphertext "knows" the message to which it decrypts. For example, they use (idealized) hash functions, or encryption of the same message under two different keys. This way, Eve can't generate a valid ciphertext by modifying something Alice sent to Bob. If the proof doesn't check out, then Bob can tell that he may be under a chosen-ciphertext attack, and will throw away the ciphertext. In the previous scenario, Bob can't tell whether the ciphertext was built maliciously, or was just the encryption of some garbage that Alice legitimately sent. Here, he can.
I like this work because it moves chosen-ciphertext attacks from the realm of "paranoid academics modelling an unrealistically powerful adversary" to the "real world." Now people may think twice before chosing weaker crypto than is currently available.