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

Quick!

[Anonymous Coward]

Now that the interview isn't the main focus, downmod all score:5's and the other moderators will never notice!!

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

[Publicus]

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.

Re:Affects implementation, not the standard

[Clemence]

Actually, it looks like it affects the standard, but implementations that deviate from the standard (i.e., GnuPG in some respects) may be less vulnerable.

According to the Columbia University research paper (or at least one of them), the flaw does effect the OpenPGP standard, and specifically, they successfully exploited the flaw in GnuPG as well when compression was not used. The authors note that the flaw even exists when compression is employed, but that GnuPG deviates enough from the OpenPGP compression standards that compressed GnuPG messages are relatively safe. Apparently GnuPG employes a non-standards-required message integrity check that foils the attack.

Re:Affects implementation, not the standard

[SirSlud]

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!

Re:Affects implementation, not the standard

[Anonymous Coward]

Hey! You're a communist arn't you?

Re:Affects implementation, not the standard

[Dick Click]

I agree with the paper's assessment, and disagree with yours; specifically:

Typical users of e-mail encryption software are not educated in good security practices;it is therefore important to design robust software whose security is not compromised even when the software is used in a naive manner.

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. :)

Re:Affects implementation, not the standard

[Beryllium Sphere(tm)]

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 :-)

Re:Affects implementation, not the standard

[Gemini]

The message integrity check is part of OpenPGP - it is discussed in detail in 2440bis, the draft that will be replacing RFC-2440, which was the original OpenPGP RFC.

Remember, this is not a new attack. The potential for this attack has been known for a long time, and was one of the reasons the message integrity check was added quite a while ago. What is new with this paper is a demonstration of the exploit in action.

Re:Affects implementation, not the standard

[arkanes]

I see nothing wrong with that theory. It is, in fact, correct, that one of the main weaknesses of computer systems today is poor passwords.

Re:Affects implementation, not the standard

[jareds]

Signing before encryption would be a countermeasure.

How? I thought an encrypted and signed message was just an encrypted message with a signature tacked on. The adversary could just discard the signature and perform the attack.

Re:Affects implementation, not the standard

[Gemini]

An encrypted and signed message is not just an encrypted message with a signature tacked on. Rather, it is Encrypt(Sign(plaintext)).

The signature is inside the encrypted blob. If the attack here was tried, the signature would become invalid, and warn the user.

Re:Affects implementation, not the standard

[jareds]

An encrypted and signed message is not just an encrypted message with a signature tacked on. Rather, it is Encrypt(Sign(plaintext)).

The signature is inside the encrypted blob. If the attack here was tried, the signature would become invalid, and warn the user.

That's not much better. It seems more likely that D(C') would be so garbled that it wouldn't appear to be a signed message at all.

Re:Affects implementation, not the standard

[vsack]

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.

How would you ever be able to detect a failed decryption? The ability to detect garbage requires a restriction on the valid cleartext input into the algorithm.

Re:Affects implementation, not the standard

[p3d0]

I'm not sure how you came to that conclusion. Check out section 5 of the paper.

Re:Affects implementation, not the standard

[taernim]

That won't work either...

Smart: "Bob, can you give me a hand here?"
StupidBob: "Sure"
Smart: "Just grab this expensive looking little pad"
*beep*
Smart: "Okay, thanks."
StupidBob: "Ummm, sure"

And Bob has unwittingly (or dim-wittedly) done a similar thing as picking a poor password. Sure, you might have to be a little less obvious about it, but your security will always be as weak as your stupidest employee who holds power and can be social engineered...

Re:Affects implementation, not the standard

[rgmoore]

Signing before encryption would be a countermeasure.

Shouldn't you sign after encryption? The point of the signature is so that you can tell if the contents of the message have been tampered with. This approach requires that the encrypted message be replaced with gibberish, which would include the encrypted signature, too. But if the signature is unencrypted, there would be no excuse for it being turned into gibberish and it would serve as a valid check that the original message had not been tampered with.

Re:Affects implementation, not the standard

[Zeinfeld]

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

That is completely wrong. According to the paper it is the specification that is broken NOT the implementation

In fact the implementations turn out to be more secure than the spec for purely fortuitous reasons.

The attack is possible because of confused management of compressed and uncompressed message types. It is a flaw in the PGP envelope scheme.

It does not appear to me at the moment that the attack can be extended to S/MIME, certainly S/MIME does not use completely different formats for compressed and uncompressed data so the immediate cause is not there. I suspect that Bruce will have looked at S/MIME before publishing the paper.

I think that people need to rexamine a couple of things.

First the parrot like claim that people should avoid using S/MIME and that PGP is the one true security specification.

Second the claim that open review is a panacea for security issues. The spec and PGP code were both open and there is a significant flaw.

Third the gullability of Slashdot readers who all appear to have taken the first post in the thread as accurate rather than read the actual paper.

Re:Affects implementation, not the standard

[Zeinfeld]

Yeah, this exploit falls under the 'social engineering' side more than anything.

Not really, it is a significant protocol flaw. The exploit of the flaw is slightly cumbersome but there are plenty of circumstances where it can be applied, in particular any application where an encrypted PGP message is sent to an automated daemon.

The flaws in the Enigma cipher were equally obscure. Protocol design should be secure against social engineering. Had the German operators used the devices correctly the attacks would have been much harder.

Re:Affects implementation, not the standard

[Beryllium Sphere(tm)]

>just an encrypted message with a signature tacked on

That would be signing *after* encryption, which isn't the world's most useful concept anyway.

If a message is signed, and the message + signature is encrypted, then you've got something that an adversary can't spoof perfectly.

Re:Affects implementation, not the standard

[Beryllium Sphere(tm)]

>The ability to detect garbage requires a restriction on the valid cleartext input into the algorithm.

Yes, for example requiring it to have a checksum.

You can see this principle at work in your own copy of PGP. You get an "incorrect passphrase" error instead of a screen of garbage if you put in the wrong passphrase.

Re:Affects implementation, not the standard

[Beryllium Sphere(tm)]

There are problems with signing after encryption, depending on what your security needs are.

More detail than you want in
R. Anderson and R. Needham, ``Robustness Principles for Public Key Protocols,'' in Lecture Notes in Computer Science 963, Don Coppersmith (Ed.), Advances in Cryptology - CRYPTO '95, pp. 236-247. Springer-Verlag, 1995

My idea had been that if someone replaced the encrypted message with gibberish then the signature wouldn't verify. It wouldn't work anyway, for the reason jareds pointed out -- as long as you accept *any* unsigned messages then you're vulnerable to gibberish that doesn't look like a signed message.

Anyway, the best attack on PGP is still installing a keystroke logger in a Trojan. Or putting a fake public key on the servers and ensnaring people who don't check key signatures.

Re:Affects implementation, not the standard

[afidel]

That is why any good password system checks to see if their password is trivial and tells them they are stupid and to choose again =) Now I personally believe that the ideal password system is somehwere between password=last name and password= 9IbiH.5! (of course that is not nor has it ever been a real password of mine, I'm not that silly)

Re:Affects implementation, not the standard

[jesser]

Yes, we should try to eliminate passwords, for security against bad passwords, for security against social engineering (calling a victim, posing as tech support, and asking for a password), and for convenience. How about this:

Web sites would stop using passwords, or at least make passwords optional. The login procedure would be similar to the current "lost password" procedure, involving e-mail, instant messages, or perhaps something better integrated with browsers. Many users would log in, accept a permanent login cookie, and be happy that they didn't have to think up and write down Yet Another Password. Mobile users might choose to use a password for the few services that they use in multiple locations if they can only access e-mail from one location. Paranoid users would choose session cookies instead of permanent cookies and might disable logging in by e-mail after setting a password.

Re:Affects implementation, not the standard

[iabervon]

Restricting distribution of the public key isn't necessary. Restricting automatic decryption is a better idea: if you get an encrypted message, don't let the user include it in a reply to anyone who didn't sign it.

The attack message can't be signed (either by the attack or by the original sender), because it's a specially-constructed ciphertext where the attacker doesn't know the plaintext (until you send it back), and it's not the original message, so nobody could have signed it.

With this UI, you get a bunch of garbage and when you reply, your mailreader doesn't let you include the garbage, so you just say "You sent me garbage; you'll have to try again" rather than sending back the garbage.

Re:Affects implementation, not the standard

[Anonymous Coward]

In fact the implementations turn out to be more secure than the spec for purely fortuitous reasons.

"In fact", if you read the paper and know the OpenPGP standard, this problem was known about and fixed over a year ago. That's how open review is supposed to work - it doesn't mean there are no flaws. It means that when there are flaws (and there will be), they are fixed.

Re:Affects implementation, not the standard

[Zeinfeld]

"In fact", if you read the paper and know the OpenPGP standard, this problem was known about and fixed over a year ago. That's how open review is supposed to work - it doesn't mean there are no flaws. It means that when there are flaws (and there will be), they are fixed.

The draft was modified today specifically in response to the paper, not over a year ago.

Bruce has in the past done what you are accusing him of doing here - making a fuss about a well understood problem that is not actually an issue in a protocol implementation. In particular his IPSEC and PKI papers fell into that category.

However I have just read the PGP spec and Bruce is completely right on this occasion. The latest draft contains a mechanism that MAY be used to control the attack, however the paper demonstrates that the MAY needs changing to a MUST.

Reading through the latest draft posted today I think they still have a problem:

In late summer 2002, Jallad, Katz, and Schneier published an interesting attack on the OpenPGP protocol and some of its implementations [JKS02]. ...
Because of this happenstance -- that modification attacks can be thwarted by decompression errors, an implementation SHOULD treat a decompression error as a security problem, not merely a data problem.

Simply adding a note to the considerations section is not enough, they need to rewrite the draft.

Re:Affects implementation, not the standard

[Anonymous Coward]

I'm not accusing anyone of making any fuss. There is a problem. The authors are correct in pointing it out... something they did a YEAR AGO.

This paper is not news. Their paper a year ago was news. This paper is just a "Remember our theoretical paper a year ago? Well, here's an actual exploit."

The "fix", MDC, was added to the OpenPGP draft in late 2000.

This is...

[Anonymous Coward]

...bad!

There a HUGE amount of highly classified material communicated with the help of PGP. On the other hand, most people don't realize how much highly classified material is sent without encryption at all.

that's why they call it Pretty Good

[krog]

leaving the door open for instances like this.

PEBKAC conquers all, as usual.

Speaking of Jon Katz...

[FortKnox]

... he hasn't posted an article since Jul 15th!

Is he still employed with OSDN??

Inquiring minds want to know!

Re:Speaking of Jon Katz...

[HaeMaker]

He has been spending that time reading everyones' email...

Re:Speaking of Jon Katz...

[BitHive]

That's funny, I haven't seen a Jon Katz story since Februrary! This was about the time I got around to getting a /. account and discovered the wondrous user preferences page.

What ever happened to that CmdrTaco guy? Didn't he used to post stories too?

Re:Speaking of Jon Katz...

[dhaines]

And coming up with sneaky ways to get around our exclusion settings.

Re:Speaking of Jon Katz...

[tswinzig]

... he hasn't posted an article since Jul 15th!

Actually, he hasn't posted an article since I marked that little checkbox in my preferences section many moons ago...

Re:Speaking of Jon Katz...

[Strange Ranger]

Now he's getting other people to decrypt his articles?

I thought that was our job?

Re:Speaking of Jon Katz...

[David Off]

If you put timothy on your filter list you pretty much get rid of all the retreads on /. too.

Yeah, yeah, I know he posted this article, QED.

David

Re:Speaking of Jon Katz...

[Anonymous Coward]

Maybe Jon figured it wasn't worth posting anything since the /. statistics report 99% of users have checked that box.

Re:Speaking of Jon Katz...

[Anonymous Coward]

You're wrong. He finally checked the box himself last week, making it 100% of users.

Re:Speaking of Jon Katz...

[netsharc]

Yes he has posted things, you just don't see them.. if a tree falls in a forest and you were wearing earplugs and didn't hear it, doesn't mean the tree didn't fall..

Re:Speaking of Jon Katz...

[tswinzig]

You're not a lot of fun at parties, are you?

(That's my way of saying... DUH!!!)

Re:Speaking of Jon Katz...

[tswinzig]

Wow! So slashdot only has 100 users, total?

Your friend forwarded this to me:

[hackwrench]

ENCRYPTED.TXT ...but it is corrupt. Could you please send me a copy? Here is my public PGP key:

PGP has always been worthless

[Anonymous Coward]

It's not even based on the Navajo language! No wonder it's vulnerable!!!

What is with today and security?

[Verizon Guy]

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

Re:What is with today and security?

[Greedo]

Yeah ... with cups and string, it's pretty easy to detect a man-in-the-middle attack.

Re:What is with today and security?

[Anonymous Coward]

Not even that would work. It would be way too easy to tap into the vibrating string.

Re:What is with today and security?

[idontneedanickname]

Better be able to see all of the string or someone might tap the line!

beware

[Budgreen]

the DMCA!

ooooOOOOOOooooooo

Whuh?

[roc_machine]

The paper comes from Kahil Jallad, Jonathan Katz,

Where's the 9/11 reference? I couldn't find it anywhere...

Please stop

[Anonymous Coward]

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!

Old news, but...

[Anonymous Coward]

Before people jump on this -- yes, it's old news, and it doesn't only affect PGP. But this is something which hasn't gotten the attention it deserves. Many people are still working with dual key support and don't even know it.

SCOTT19U

[Anonymous Coward]

Damn, now we'll never get to shut him up on sci.crypt.

OpenPGP standard

[Nex6]

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

Re:OpenPGP standard

[Gemini]

In reality, by default, no OpenPGP software is really affected by this. Both PGP and GnuPG compress the messages which halts the attack. On top of that, GnuPG uses a message integrity check which also halts the attack.

A given message is only vulnerable if the sender disables compression and message integrity checking. It is unfortunate the news reports don't say this (not as good a story, I suppose), but the paper makes it quite clear.

Re:OpenPGP standard

[Zeinfeld]

In reality, by default, no OpenPGP software is really affected by this. Both PGP and GnuPG compress the messages which halts the attack.

Actually that is not accurate. PGP and GPG will both use compression if the payload is compressible but send the content plaintext otherwise.

Both programs are vulnerable if you send a gzip file.

Stop spreading Complacency and False Certainty, it is just as bad as FUD

Re:OpenPGP standard

[Anonymous Coward]

Actually that is not accurate. PGP and GPG will both use compression if the payload is compressible but send the content plaintext otherwise.

Actually, no, that is accurate. If you look at the source code of GnuPG 1.0.6 (the version tested for this paper), it compresses everything regardless of whether it was already compressed.

More recent versions of GnuPG change this, but the text of the paper is incorrect on this point.

ouch!

[Anonymous Coward]

...Jonathan Katz...

Anyone wanna bet they called him Jon Katz before the idiot reporter on this site ruined his good name?!?

Katz

[krog]

i'm not sure, but i think he's been spending a little vacation with some hacker friends in Afghanistan.

Compressed data

[mukund]

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.

Re:Compressed data

[Anonymous Coward]

I heard (on the internet, so it must be true) that using compression with SSL may result in weaker encryption (ie mod_gzip over https). Anyone know if this is true or not? Is it safe to use mod_gzip and friends over https?

Re:Compressed data

[AftanGustur]

The abstract of the paper suggests that the attacks largely fail when the data is compressed before encryption.

True, but it also mentions:
In the case of GnuPG (when compression is used), the attack fails only due to the presence of a message integrity check which is not explicitly required2 as part of the OpenPGP specification.

So, yes the attack doesn't work on GnuPG compressed data, but it looks like the GnuPG developers will have to close some other potential security flaws.

Re:Compressed data

[Gemini]

This is not how it works. GnuPG always uses a message integrity check unless it is communicating with PGP which does not understand the integrity check. At the same time, when it needs to communicate with PGP, it uses ZIP (not ZLIB) compression, which foils the attack. That section of the paper is incorrect.

The authors were informed, but unfortunately not in time for the conference deadline.

Re:Compressed data

[John Hasler]

The attack also fails if the reply containing the "garbled" message is encrypted. Always encrypt replies to encrypted messages to avoid giving attackers a plaintext.

Re:Compressed data

[jelle]

Compressed streams often have a 'signature' at the beginning of the stream. When this signature is encrypted, then the attacker knows a little bit of unencrypted data and the 'corresponding' encrypted data. This will make a plaintext attack more feasible. It may still require the attacker to eavesdrop many packets and spend a lot of cpu time on them, but it will be less than with completely random data. However, not compressing also aids the plaintext attack, especially when the data is known or patterns of it are guessable, such as english text (alphabetic statistics), protocols "GET /cgi-bin/login.cgi", "HELO myserver", headers "X-Mime-Type:", etc.

To be most secure, you should only encrypt and transmit absolutely random data.

Re:Compressed data

[Anonymous Coward]

RFC 1950 (ZLIB) is just a wrapper around DEFLATE (RFC 1951), they aren't different compression schemes.

Re:Compressed data

[t00tie]

> To be most secure, you should only encrypt and transmit absolutely random data.

lol! Which is about as useful as not communicating at all, the other totally secure solution to all your communications problems ;-)

Re:Compressed data

[jelle]

bingo

Phew...

[DTC]

I had been wondering what John Katz has been up to, so it's good to hear that he's been keeping busy. Now perhaps he'll have some time to review some movies; I've been seeing entirely too many, since I don't know what NOT to watch anymore ;)

I use a simplier solution

[papasui]

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.

Re:I use a simplier solution

[peterpi]

1 F1|\|D T|-|4T 1337 5p33k 5T0pZ 4|\|yB0|>Y Fr0|\/| R34|>1nG |\/|y m41|_z!!111111111 (including the recipient... howzat for privacy? ;)

Re:I use a simplier solution

[Anonymous Coward]

I find that elite speak spots anybody from reading my mails!!!!!!

Re:I use a simplier solution

[mriker]

Blame the idiot that invented English. Man did he screw a lot of stuff up.

Re:I use a simplier solution

[.com b4 .storm]

For law-abiding minors and those who dislike alcohol, there is a simpler solution. ;)

Another mirror/story

[bloatboy]

From CNN here.

Katz?

[babbage]

*Slashdot* Jon Katz? A cryptographer??

I thought he was just a bloviated wannabe essayist, not a crypto analyst. Surely this can't be the same guy...

Re:Katz?

[RealTimeFreeAgent]

He learned all he needed to know about cryptography from his Afghan hacker buddy, Junis.

Re:Katz?

[tbmaddux]

Surely this can't be the same guy...

It's not. This is the guy.

Re:Katz?

[GodHead]

With enough hot air, I guess you can do anything.

Applied Cryptography - 3rd Edition?

[Shamanin]

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.

Re:Applied Cryptography - 3rd Edition?

[AftanGustur]

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

Huh ? those pages are part of chapter 24 "Example Implementations" and describe how pgp works and explain key-signing and the trust-model that Philip Zimmermann built into it.

The text is in no way wrong or even outdated. Mr. Schneier writes good text who wouldn't be written much differently today.

Re:Applied Cryptography - 3rd Edition?

[Shamanin]

I totally respect the work of Schneier (why else would I have his book on hand to cite from). It was merely a joke.

I appologize if you took offense, but I have to say "Lighten Up".

Re:Applied Cryptography - 3rd Edition?

[AftanGustur]

I totally respect the work of Schneier (why else would I have his book on hand to cite from). It was merely a joke.

It is a common practice to mark text that should not be taken to seriously with at least one smiley.

It's not as broken as you might belive..

[AftanGustur]

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.

I just want to verify...

[SkyLeach]

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.

Re:I just want to verify...

[jareds]

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?).

If someone intercepts a message C encrypted with your public key, and they can get you to decrypt a message C' that they create by modifying C, they can recover at least part of the original message that was encrypted to produce C.

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)

You don't understand. It doesn't matter whether your reply is ecrypted or signed or whatever. What matters is that your reply includes the decrypted C'. Presumably, your adversary will be able to notice and remove a couple of "> ".

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.

Two points:

1) Even if the attack didn't work for encrypted and signed messages, but just for encrypted messages, that would still be a very big deal.

2) I think that a signed and encrypted message is just an encypted message with a signature tacked on, so the adversary could just discard the signature and perform the attack.

Re:I just want to verify...

[SkyLeach]

"You don't understand. It doesn't matter whether your reply is ecrypted or signed or whatever. What matters is that your reply includes the decrypted C'. Presumably, your adversary will be able to notice and remove a couple of "> "."

This is exactly my point, every '>', changes the hash of the block before encryption. A '>' on every line would make a significant, if not unpredictable difference. Nonetheless it could be, eventually, figured out how many '>' + ' ' are before each line. The attacker would also have to predict any line wrapping.

"2) I think that a signed and encrypted message is just an encypted message with a signature tacked on, so the adversary could just discard the signature and perform the attack."

PGP signatures are not simply tagged onto the end of a message. They are an MD5 hash of the original message which is then encrypted with the private key of the sender (which allows the public key to be used to verify the signature). When the message is recieved, the decrypted (plaintext) of the sent message is then hashed by the recipient (i.e., my) PGP and then I compare the two hash values. Someone wishing to modify the contents of the message must have the ability to sign the message with the "sender's" key. In order to do that, they must have their private key.

If signatures were simply tagged onto the end of a file then they wouldn't matter at all.

Which is my point, you can't trust any content, even encrypted content, unless it is signed. This is a social eneneering hack and has nothing to do with the PGP standard as far as I can tell.

Re:I just want to verify...

[jareds]

This is exactly my point, every '>', changes the hash of the block before encryption. A '>' on every line would make a significant, if not unpredictable difference. Nonetheless it could be, eventually, figured out how many '>' + ' ' are before each line. The attacker would also have to predict any line wrapping.

True. I didn't think that was what you meant because it didn't seem like it would be difficult at all to figure out how many "> " there were on each line. Presumably that would be either 0 or 1.

PGP signatures are not simply tagged onto the end of a message. They are an MD5 hash of the original message which is then encrypted with the private key of the sender (which allows the public key to be used to verify the signature). When the message is recieved, the decrypted (plaintext) of the sent message is then hashed by the recipient (i.e., my) PGP and then I compare the two hash values. Someone wishing to modify the contents of the message must have the ability to sign the message with the "sender's" key. In order to do that, they must have their private key.

If signatures were simply tagged onto the end of a file then they wouldn't matter at all.

I simply don't understand what you're talking about. Of course signatures would work fine if they were just tacked on the end, for exactly the reason you describe. Indeed, most implementations let you generate a signature for a file as a separate file.

I may indeed have been wrong, PGP may produce Encrypt(Sign(Message)) for encrypted and signed messages. However, the decryption of C' would be garbled, and would probably not be in the format of a signed message at all. It would appear to have no signature, not an invalid signature.

Which is my point, you can't trust any content, even encrypted content, unless it is signed. This is a social eneneering hack and has nothing to do with the PGP standard as far as I can tell.

Well, of course a chosen chiphertext attack may require social engineering. However, it is absurd to use a protocol subject to a chosen chipertext attack when one is available that cannot be so attacked.

Re:I just want to verify...

[jkramar]

I'd like to clarify, as you don't seem to fully understand how key encryption works. If I am wrong, please disregard this message. You have two keys: a private key, available only to you, and a public key which anyone can know. If a message is encrypted with a private key and the corresponding public key, or several such pairs, in any order, it remains plaintext.

The signature, as was stated, consists of the MD5SUM of the message, and both the message and the signature are separately encrypted with your private key. This way, the receiver will know that the message came from someone knowing your private key, because he/she can decrypt the message with your public key. Furthermore, to ensure that only your intended recipient can read the message, you encrypt the whole thing with the recipient's public key.

However, if someone intercepts the message you sent, encrypts it with his/her public key, and sends it to your recipient, whose mail reader automatically decrypts this message with the recipient's private key, and says that the file is garbled and he needs help, then when the recipient replies, the whole thing will only be encrypted with the attacker's public key (because the recipient's private key decryption cancelled the encryption by the sender with the recipient's public key), and from the reply, the attacker can find and read the message by decrypting with his private key. (In the preceding passage, encryption and decryption describe the same algorithm, just performed with a different purpose.) However, as has been oft-repeated, this is a social engineering hack and depends on the stupidity of the recipient.

Re:I just want to verify...

[jareds]

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.

Re:I just want to verify...

[jareds]

I'd like to clarify, as you don't seem to fully understand how key encryption works.

I incorrectly thought that PGP performs Sign(Encrypt(Message)) for encrypted and signed messages, and I did miss a detail of the attack that lead me to believe that it would work still on Encrypt(Sign(Message)), but I'm pretty sure I understand what's being said in this discussion.

However, if someone intercepts the message you sent, encrypts it with his/her public key, and sends it to your recipient, whose mail reader automatically decrypts this message with the recipient's private key, and says that the file is garbled and he needs help, then when the recipient replies, the whole thing will only be encrypted with the attacker's public key (because the recipient's private key decryption cancelled the encryption by the sender with the recipient's public key), and from the reply, the attacker can find and read the message by decrypting with his private key. (In the preceding passage, encryption and decryption describe the same algorithm, just performed with a different purpose.) However, as has been oft-repeated, this is a social engineering hack and depends on the stupidity of the recipient.

That really isn't how the attack described in the paper works. In PGP, only the session key is encrypted by the public key, but the encrypted session key isn't modified in this attack.

Way to go Kahil

[Special Agent K]

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

Re:Way to go Kahil

[Anonymous Coward]

when did he stop writing poetry and start working on cryptography...ph yeah I guess they are related

Reminds Me

[4of12]

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?

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.

DMCA

[Screaming Lunatic]

Is it just me or are they breaking the DMCA?

Maybe they'll throw JonKatz in jail. Well a geek can hope can't he?

Yeah, I know this is a troll. But I have karma to burn. And if I'm gonna burn karma, I can't think of a better way than by trolling JonKatz.

This is such old news.....

[Anonymous Coward]

This type of attack was mentioned in Applied Cryprography by Schneier himself, p42.....

Yawn....

Flash Player bugs open Windows/Unix to attack

[burgburgburg]

A news.com article discusses two separate new flaws found in Flash Player. One allows malicious code to be run on Windows/Unix OSes. The other allows an attacker to read files on a person's local hard drive. For the first flaw, All Windows and Unix versions of Flash Player before 6,0,40,0, are affected. Any application capable of reading SWF files (email, instant messenger, browser) can be used. For the second, it relies on the XML functionality of Flash Player 6 and tricks the browser into reading local files.

Encryption make your own

[RedElf]

So, if I were to create my own encryption, Would it be better then someone elses that is widely spread? what all would it take to make it really secure?
Help me out here I'm thinking of doing something like this for a portal system I'm itching to write in perl possibly having 2 different encryptions, everything goes through the first encryption so the entire database is encrypted, then all passwords, etc. go through a 2nd encryption algorithm after the first to make them more secure, Does this seem like a good idea?

Re:Encryption make your own

[qurob]

sure, something you throw together in perl in 5 minutes is going to beat some widely known and secure algorithim

Re:Encryption make your own

[Boss, Pointy Haired]

Hi RedElf,

IANAC (I am not a cryptographer) but a real one could bore you for hours in answer to this question, so i'll try and be brief.

Re: writing your own encryption; the short answer is no, it would not be better. Truly good encryption techniques have been through years of peer review, to the extent that if they are executed properly, you are safe. Remember that there is a cost associated with breaking encryption, so unless you have something extremely valuable, and consider yourself a master cryptographer, just stick with a well known method.

Re: double encrypting passwords; this is kinda what happens anyway if you use an algorithm such as 3DES (triple DES). The traditional attack against passwords is one where you create a dictionary of known encrypted passwords and compare these to the encrypted password you are trying to crack. In this case, double encryption doesn't gain you much, because the attacker will just double encrypt the dictionary in the same way.

Also look at using one-way-hash functions for your password system.

Hope this helps!

PHB.

Re:Encryption make your own

[Anonymous Coward]

I think you are in over your head, and you should go read as much as you can about cryptography before you even start. Your question indicates to me that you have a long way to go, although I m admittedly making a few assumptions, based on your post.

First, inventing your own algorithm for cryptography is generally not a good idea (except for learning purposes). There are proven algorithms on the market, and widely available libraries to perform the crypto. Various algorithms have different uses - for example, some are very strong but slow. Others are quick but weaker. Some employ public keys, others have some sort of key exchange. Some are good for streams, others require the entire data packet prior to producing any results.

Many common implementations (like SSL, PGP) use a combination of crypto algorithms (RSA, blowfish, DES3, many others) to optimize their results for their purpose. For example, it's common to use RSA (slow, strong, but only for a small amount of data) to establish a key pair and use another algorithm that is faster, but using the keys exchanged previously.

Public disclosure of your algorithm is the only way to insure appropriate peer examination and find the flaws. Writing your own algorithm is unlikely to provide that sort of peer review. And commercial viability depends on this sort of peer review (unless you are M$, writing the Excel protection routines...)

Go read all you can before you start! It's a very interesting topic! Best of luck.

Re:Encryption make your own

[Anonymous Coward]

oh yeah, it's not like Red Elf isn't a massive troll that you just wasted your afternoon being all 'splainy 'splainy to...

Re:Encryption make your own

[moogla]

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.

This is a EMAIL CLIENT flaw, not a pgp flaw.

[TrentTheThief]

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.

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[gerf]

This so-called "flaw" in PGP is on a par with calling an OUTLOOK email flaw a virus

Well, actually, it's a flaw with the plug-in for Outlook. This shakes people a bit, but it's really not quite as big as we'll make it out to be. There've been a lot bigger flaws in M$ products that haven't gotten as much attention....

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[SEWilco]

Is Outlook more susceptible to this type of error, or was it just Outlook's bad luck that the error happened in a plugin for it?

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[Kahil]

Please, read the paper and not the articles. News articles are written designed to get you attention, not inform you. The attack has nothing to do with including the plaintext of an encrypted message, it is a chosen - ciphertext attack aginst the the CFB chaining mode used in PGP/OpenPGP. They _have_ known about it for a while, and a new version of the standard addresses it. Not to mention that signing and compression mitigate the attack as it is . . .

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[TrentTheThief]

Uhmmm... Perhaps I misunderstood, but: a)The paper still talks about the email client performing automatic decryption of the received text. b) The defender must also reply with plaintext of the garbled decipher:

"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. Using information obtained in this way, the adversary may be able to determine the original message."

That sounds like plaintext to me. ++++++++++ Using encryption implies a need for privacy. If this is the case, then leaving your keyring unattended (yes, if it's automatic, it's unattended) and your passphrase in memory (how else can an automatic decryption be performed?) begs for compromise.
This is an attack in name, only. It is actually poor security, i.e., user compromise of keys and materials.
Flog 'em 'round the fleet keel 'aul 'em if there's anything left.
Perhaps my expectations too high. But, IMHO, there is no excuse for physical compromise. If a message arrives garbled, you ask for a resend. A keyring should only be available to PC when required and removed. The passprhase should not be stored in memory.

If you expect security, you must be responsible for your actions. Anything less than exacting procedures will always come back to bite you. Of course, the little things such as guarding the keyring, never writing down the passphrase, good physical security of the workstation are what count the most. Now that U.S. agencies can legally perform what were previously illegal entries and illegal monitoring, these little things have become extremely vital...
I'm good for anything short of a Van Eyck attack.

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[Dahan]

I'm not sure why they put the word "automatically" in there--I don't see how that would matter. So you have your keyring on a floppy... you get an encrypted email from someone, so you put your keyring in, key in your passphrase, and attempt to decrypt it. You get a garbled message. Continue with the rest of the steps outlined in the paper...

Sure sounds like a PGP flaw to me if they decided to change the OpenPGP standard to prevent this problem.

Re:This is a EMAIL CLIENT flaw, not a pgp flaw.

[TrentTheThief]

You are entitled to hold any opiion that lets you sleep at night. However, it is that opinion that is flawed, not PGP.

Follow this chain:

1. PGP either decrypts or it fails.
2. If a PGP decryption presents you with garbage, then garbage was encrypted.

If the operator compromises the decrypted results, and thereby the private key/passphrase, then it is operator error. Period. Sounds like a court martial, a $100K fine, and ten years in the brig getting your ass kicked by mean Marines to me.

If you want to base your comm sec on hare-brained ideas, that's your lookout. It ain't happening in my shop. You handle either handle _everything_ like the keys to the kingdom, or you may as well just type it out and snail mail it 'cause it ain't worth encrypting to begin with. It's your call.

Security not based on forethought and intelligence is fantasy. That is truth.

Re:It's not as broken as you might belive..

[russotto]

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.

Same article at www.news.com

[trajano]

http://news.com.com/2100-1001-949368.html

Yahoo Links

[cheinonen]

I know it's off topic, but since everyone seems to have pop-ups here with such a passion, why doesn't Slashdot adopt a policy to not link to stories (like this) at Yahoo!, who has pop-ups, and instead only link to sites that are pop-up free? I'm sure this story is going to be picked up by many other sites, but Yahoo! will get all that traffic, and keep serving up the pop-up ads, as we all go there.

Re:Yahoo Links

[Anonymous Coward]

...which is a big part of the reason why I don't bother to RTFA hardly anymore, as it's easier to tell with less time what kind of article it is in the first place.

However, if I post, I educate myself about the situation, including searching for info on more than the stupidly single /.'d link the idiot poster gave the hordes.

Re:Yahoo Links

[jandrese]

Popups???

Didn't popups disappear from the web back around Mozilla M17 days? Isn't it silly to deprive yourself of all sorts of informative content just because your browser is dumb?

Re:Yahoo Links

[crawling_chaos]

The article had popups? I didn't see any.

Oh, you're using IE. My condolences.

Re:Yahoo Links

[idontneedanickname]

And Hotmail too....

Poor guy, must be going through hard times...

Re:Yahoo Links

[cheinonen]

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.

The most surprising part

[Anonymous Coward]

Was the inclusiion of Jon Katz in the study.

I assume they used all his civil rights encrypted emails from his excellent Hellmouth series to demonstrate the exploit.

I would be surprised if he actually had time to study anything between his pandering to children, and RPG'ing to understand the socio-economic realities of the real world.

he must be really multi-talented.

cribs

[56]

This is how the allies broke the German enigma in World War 2.

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. //begin not-so-obscure geek reference
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. //end not-so-obscure geek reference

Re:cribs

[Fizyx]

Pardon? I don't recall that at all. Waterhouse was breaking Japanese codes, not American. And he tasked Shaftoe with covering up the fact that they had broken Axis codes. But he never broke Shaftoe's codes. Can you provide some more context of this?

Re:cribs

[armchairlinguist]

The "secret conspiracy" consisting of at least Rudy, Shaftoe, Root, and Bischoff was using an uncrippled version of Arethusa (the crippled version was indeed being used by the Axis, under the name Azure/Pufferfish) - Rudy had given it to Goering but crippled it first) and Waterhouse breaks one of the messages because he knows that there are a number of possible cribs, one of which is "crocodile" (others of which include "Shaftoe) because Shaftoe has died and they are holding a meeting of the conspiracy at his funeral. See p. 877 of the large paperback edition for details, a chapter called, appropriately, "cribs."

Re:cribs

[karlm]

All of the ciphers (except single DES and IDEA) used in PGP are believed to be strong against known-plaintext and chosen-plaintext linear and differential cryptanalysis, related key attacks, etc. If you're looking for known plaintext, you've got it in the compression headers. (PGP uses zip compression by default.) Since PGP uses CFB mode, you can simply rearrange the code blocks and trick the user into decrypting the message (adding an extra random ciphertext block at the end or keeping the last block in the same position) and then have the user send you the decrypted garbage and piece back together the message. This attack would also work if you could trick the user into encrypting a chosen message with the same key and IV as the message you wish to crack. (Not feasable with the PGP user interface.) This break has nothing to do with cribs.

Also note if you keeep everything the same but the last byte and trick the user into quoting the entire decrypted message, including the garbled last byte, in his/her reply, you can break PGP that way.

Note that PGP and GnuPG both use zip compression by default and so this attack only has a probability of 1 in 4 billion of suceeding and requires user interaction for each attempt. If you turn off compression AND are dumb enough to quote all of the garbage back to the attacker, this attack can be used agaisnt you. This attack is somewhat feasable, but requires some social engineering or some users that are dumb in just the right ways.

Note that if OCB mode were used instead of CFB mode, this attack would not work. Unfortunately, OCB mode is patent encumbered.

Re:cribs

[Beryllium Sphere(tm)]

>This is how the allies broke the German enigma in World War 2.

I haven't read about any chosen-ciphertext attacks during the Enigma crack. One line of attack was that messages began with a repetition of a three-character sequence, so certain keys were known to be impossible for given ciphertext. Another was that some operators got sloppy and used guessable keyboard combinations (the Hut 6 people called those the "sillies"). Then there was the commander who sent the exact same status report every day with a different key.

Unless "This is how" refers to depending on mistakes by the target. The German Navy codes took longer to crack because the operators were better disciplined. Venona is a superb example of waiting for the target to do something stupid -- the US was decrypting one time pads. Absolutely impossible even in theory, except that the cipher clerks at the Soviet embassy were re-using keying material.

>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

You've got a point there. On the other hand, a hard-to-use program just makes it easier to screw up. For example, early versions of PGP required a manual step to self-sign your public key. The result was that even a professional cryptographer wound up putting a non-self-signed key onto the key servers.

I worry about just your point -- security may absolutely require users to be knowledgeable. If so, it becomes in general impossible.

Re:cribs

[56]

I was just saying that cribs are what enabled the allies to 'break' (well, not really break, but effectively break) enigma, not that they used chosen text. My point was essentially that this is textbook use of cribs, and not really anything new. It seems to me that there is a fine line between being too user-friendly and not being user-friendly enough. I think that we need to err on the AOL side of things. If the user is able to use the product, it is possible for them to use it correctly. If the user cannot use the product, it's a moot point. I would sincerely hope that anyone who is transmitting data that they feel absolutely must not be intercepted would be smart enough to learn how to use the program correctly. Unfortunately, this is probably not likely.

Re:cribs

[lars_stefan_axelsson]

I haven't read about any chosen-ciphertext attacks during the Enigma crack.

Oh, there were some of those to. When they couldn't find a suitable crib for a particular day, the Bletchley boys sometimes reverted to more devious methods. One method relied on the fact that the german harbour masters on the french coast used a three wheel Enigma with the same day key as everybody else.

They also had the german naval map of the area outside the ports with the "secret" map references. So they'd task coastal command with laying a mine (by airplane) in so and so an area (in plain view of the germans) who would, predictably, proceed to sweep the mine, and then dutifully report back: "We've swept three mines at grid reference so-and-so."

Of course, in doing so they unwitingly provided the allies with a nice crib. Other variations of this game was also played, such as bombing weather bouys, having the servicing submarine report back that "Now the verdamten Engländer... etc".

Now, it may not have been a perfect chosen ciphertext attack, in that the messages couldn't be varied exactly to the specification of the Bletchley park staff, I'd still say we've clearly left the realm of guessed plaintext.

Re:cribs

[epsalon]

So, to make this attack viable this has to happen:

1. Alice sends encrypted message to Bob.
   
2. Eve intercepts message and rearranges blocks.
   
3. Bob receives message from Eve, saves it and decrypts it by issuing gpg message.gpg. Then, Bob looks at message.txt, sees it's junk and sends an unecrypted message to Alice with message.txt attached to it. I can't think of anyone dumb enough to do that.

Re:cribs

[Fizyx]

Wow, thanks for the detailed answer. The funeral rang a bell for me.

'Ask Slashdot' works!

Re:cribs

[Fizyx]

>I haven't read about any chosen-ciphertext attacks during the Enigma crack

I saw a TV documentary that referred to this: the Brits would depthcharge the hell out of some random piece of ocean, then wait for those coords to be radioed back by the wolfpack. They called it 'seeding'.

oh, great...

[Anonymous Coward]

Does this mean that one has to consider yet another problem when implementing pgp in an application?

How can this even be avoided?

recompile.org

IN RELATED NEWS, A NAME CHANGE...

[Eric_Cartman_South_P]

PGP Announces today that it will change its name to SGP.

Sorta' Good Privacy.

Re:IN RELATED NEWS, A NAME CHANGE...

[Anonymous Coward]

In other related new,

Eric_Cartman_South_P's Beneficiary found dead of serious anal rape from Subject_Line_Troll

duh

[Alethes]

And if somebody sends you an encrypted e-mail that is automatically decrypted by your mail client with whatever PGP implementation you happen to use, what do you suppose will happen if you FORWARD it? The recipient might actually be able to *gasp* READ IT!

Is this a problem with PGP or is it a problem with lusers?

We just got back from the beach...

[capt.Hij]

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.

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.

jonathan katz?

[Anonymous Coward]

heh. looks like jon katz is at least good for something :-)

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

[Gemini]

You are correct. This is only an attack on encrypted messages. If the message is encrypted & signed, then the signature failure will give away the attack.

This is why the message integrity check in GnuPG foils the attack - it is similar to a signature.

Basically, the only message that is vulnerable to this attack is unsigned, uncompressed, and having no message integrity check. On top of all that, the attacker has to persuade the victim to forward back the decrypted gibberish.

Remember also that no version of PGP or GnuPG generates uncompressed messages by default.

Re:This is a very specialized attack

[Anonymous Coward]

A larger concern would be if you could send a garbage message to someone, and their vacation auto-reply would send it back to you (after decrypting it).

Then the entire attack could take place from any mail server, without having to intercept messages (until you were trying to intercept and decrypt critical messages), and the person wouldn't even know they were attacked (presuming they are on vacation.

I wonder if auto-reply ever forwards the message back, and if it decrypts it first. Probably not, but an interesting thought...

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:This is a very specialized attack

[jareds]

A larger concern would be if you could send a garbage message to someone, and their vacation auto-reply would send it back to you (after decrypting it).

That's about the stupidest thing I've ever heard, and I'm now dumber for having read it.

Re:This is a very specialized attack

[Beryllium Sphere(tm)]

Somewhere else in this forest of responses there's a discussion of whether signatures have protective value.

Signatures do make the message tamper-evident, they can't be forged the same way a CRC could, but so what? Do you break interoperability by having the software error out whenever a message doesn't have a valid signature? Or do you have humans check the signature? OK then, what do you tell them? Not to forward the decryption? You're not any better off then than you were with unsigned messages.

Maybe if you used a MAC with the session key...

BTW, assuming that the attacker can intercept and modify messages is just standard procedure. If you could trust the network you wouldn't need crypto. The only thing that's specialized is depending on getting a quoted reply.

>The foundation is still sound, the attack is only useful on a per-message basis, and your keys are not affected by this strategy

You're batting a thousand. Correct on every point.

Re:This is a very specialized attack

[Anonymous Coward]

How the hell did the AC above get moderated and not the flamer parent to him? Talk about a sad failure in the moderation system, hopefully metamod will come through...

Hrm, second though, it's more likely a sad commentary on the moderators. My bad.

Re:This is a very specialized attack

[Shardis]

Nope, if a sig isn't there, well, it's just not there.

I believe the standard assumption is that if the sig and the message don't correspond, you should consider the entire message as tainted. So, I believe, you are *much* better off knowing that the message is tainted than not knowing anything at all. All information means something.

That'd be the logical way that I would see it anway, please excuse me if I'm missing something...

Oh, and why tie things to a MAC? Why do you want specific hardware dependancy on what should be a purely software approach to preserve portability across the same operating hardware? It's just one more extra piece of information you don't really need, or in my case want, even encrypted.

lame..

[Anonymous Coward]

what a lame vunerability, its not the program which is flawed, its the human!

Bad Headline!

[tqbf]

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.

Re:Bad Headline!

[Slak]

Perhaps the order is alphabetical by last name?

Regards,
Slak

Re:Bad Headline!

[ph0enix]

If Schneier is the LAST author in the list, it probably means he did very little except motivate the paper and help brainstorm.

No, if he's the last author on the list, it means his name is last when sorted alphabetically. However I agree that it's too bad the others don't get credit in the headline.

Re:Bad Headline!

[i0lanthe]

If "Kahil Jallad, Jonathan Katz, and Bruce Schneier" write a paper, the abbreviation is "Jallad et al".

Can't argue with that. But listing the "most well known" author makes better headlines (and he's certainly the most mentioned of the three in the Yahoo article).

Re:Bad Headline!

[Anonymous Coward]

Or, alternately, it means they didn't want to argue about who deserved more credit and they simply listed their names in alphabetical order.

Re:Bad Headline!

[phraktyl]

Yeah, but if it had anything remotely like Jon Katz in the headline, no one would have read it at all!

Re:Bad Headline!

[tqbf]

No, if he's the last author on the list, it means his name is last when sorted alphabetically.

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

Re:Bad Headline!

[3rdQ]

I was taught that the rule for scholarly papers is: Listed alphabetically, all contributors are equal. Not alphabetically, primary contributors are listed first.

Re:Bad Headline!

[rgmoore]

Sorry to shatter your faith, but not all papers list the primary author first with futher authorship sorted by merit. Many large collaborations, for instance, couldn't even begin to decide who the most significant authors are, so they just list them in alphabetical order starting at a random place in the list. In some other fields (the one where I work, for instance) the last author is understood to be the Principal Investigator and is put there no matter how much he may have contributed (unless he did enough to justify being primary author). In some other fields, the PI is always listed first, even if he did little beyond writing the grant that funded the project. Conventions on authorship vary a lot, to the point that some journals are now requiring authors to give a brief summary of each person's contribution.

Re:Bad Headline!

[UtSupra]

That's only done in the weak sciences (Physics, Chemistry, Biology, etc.). In real intellectual stuff (Mathematics, Computer Science, etc.) use alphabetical order and no one gets listed for doing little, those just get thanks...

Re:Bad Headline!

[Sangui5]

Bzzt! Wrong. While listing in order of importance is one way, also common is listing alphabetically, especially if a paper had few contributors (unlike, say, some physics experiments where the contributors list may be longer than the paper).

Since the order isn't Katz, Jallad, Schneier, we can't assume that Schneier is a minor contributor. Since RSA published as RSA rather than ARS, we _can_ assume something about importance there. But that's not the case here, is it?

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:Bad Headline!

[goodmanj]

My colleagues often informally refer to a paper like this, in which the famous author isn't first, as "et al and Schneier."

Also note that in some fields, the last author denotes the senior scientist who runs the lab and/or provides the funding and direction.

Re:Bad Headline!

[normiep]

In general you are correct, but in this case I think it had more to do with the amount each contributed.

This paper stems from a research project that Kahil did in Jon Katz's cryptography class at Columbia back in the Fall of 2001. I believe the project was inspired by one of Katz's other papers (the one in this paper's references by Katz and Schneier).

I was in this class... obviously Kahil did a much better job than I did.

Re:Bad Headline!

[Anonymous Coward]

Why do you call the sciences 'weak'? Just trolling?

I'm amused to see you list 'computer science' as an intellectual subject, while at the same time dismissing physics...

Re:Bad Headline!

[Sanga]

Looks to me the authors could have been named in alphabetical order.

The article on Yahoo does convey that S did most of the work and was involved with J and K when in Columbia.

Probably he is closely involved in getting the news to the world ... anybody have other insight (the counterpane page is also mum about the actual contributions to the paper)

Re:Bad Headline!

[mindriot]

Not if it plays any role that the names of the authors are sorted alphabetically (J, K, S).

Re:Bad Headline!

[cpeikert]

The overwhelming standard in computer science academia is to list the authors in alphabetical order, by last name. This is even true when the first author is a grad student, and the second is a fully tenured and famous professor. (See, e.g. the Liskov and Rivest paper in Crypto'02 this summer.)

In other fields (biology and other physical sciences, most specifically) the principal investigators tend to be listed first, followed by the "lesser" contributors (even if most of the work was performed by the latter).

Jonathan Katz

[lblack]

In case anybody is actually confusing him with another Meestah Katz:

This should put the confusion to rest.

Re:Jonathan Katz

[Anonymous Coward]

Isn't Katz that evil cat on Cartoon Network's " "Courage, The Cowardly Dog" ?

The "Katz Candy" episode is on today. I'ld hate to see Jon Katz's candy.

yowza yowza

Question: is the compression really a fix?

[Anonymous Coward]

Correct me if I'm wrong:

The vunerability occurs when the target of the attack replies to the attacker's special message, quoting the decrypted version of the special message. Attacker analyzes the decryption -> uses that info to figure out original message -> takes over the world.

If the compression feature is enabled, however, the inflation process during decryption will PROBABLY fail because the attacker's special message will PROBABLY be meaningless under inflation and thus will PROBABLY translate into something that will not be useful when the clueless victim quotes it in their "hey what is this garbage" reply. In other words, the decompression is also a test for validity.

Now I am a crypto newbie, but shouldn't we get really nervous around the idea of using an algorithm designed for one thing (compression/decompression) for something completely different (validity checking)? Obviously PGP wasn't designed to use the compression algorithm for verification - but the paper seems to present the compressed-data fix with a sigh of relief. "Don't worry, there just happens to be this compression thing in there that makes this attack difficult." How difficult?

Re:Question: is the compression really a fix?

[Kahil]

Compression makes the attack very difficult to perform, because PGP does not output anything for the attacker to use if decompression fails. Basically, the compression problem is as follows : Is there some way to insert random data into a compressed message and ensure that the decompressor will not choke on it and die ? If so, the attack would become workable even with compression enabled. It actually does work, on the off chance that the random data does not mess up the decompressor - that only seems to happen when the message is very very short though.

Well known "flaw"

[srn_test]

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.

Me too

[mekkab]

I'll offer a second helping of props for that gold-toothed pgp-craxxor.

(INSERT EMBARASSING STORY HERE)

Re:Me too

[Ralquin]

Gotta give up props! The gay pirate strikes again!

Some must-reads

[lordcorusa]

Pardon me if my assumption is wrong, but you sound like a relative newbie to secure systems development. Unless you are an expert cryptographer, you cannot make an algorithm even approaching the quality of today's widespread algorithms. But even having excellent crypto is not enough. Security is built in each part of your app, both in coding and overall design, as this vulnerability demonstrates, and it will take a lot of work to make a secure app.

I don't mean to discourage you, so if you are serious about implementing a secure portal, or just learning more about secure systems development, here are some of my favorites:

By Schneier:

Secrets and Lies -- on why crypto and technology arent enough.

Applied Cryptography -- Howto make good crypto

By Viega and McGraw: Building Secure Software -- The whole process of secure system development.

Good luck and good reading!

New Vulnerability announced!

[Anonymous Coward]

Iamidiot corp announced today that a serious vulnerability in every email program available. Sending your credit card number to someone you dont know could have a serious effect on your account!

It's "et al."

[Anonymous Coward]

It's "et al.", al. is an abbr. for alldamofos, so et al. means "and all the mofos". Or is that mofus?

Re:It's not as broken as you might belive..

[dfn5]

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?

Re:Please stop [trolling]

[XSforMe]

From meridiam webster online:

sarcasm:...
2 a : a mode of satirical wit depending for its effect on bitter, caustic, and often ironic language that is usually directed against an individual b : the use or language of sarcasm

Common sense???

[jesser]

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.

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 ... =)

jareds is right

[Beryllium Sphere(tm)]

Ack. Yes. The only way to use signing to protect yourself would be to adopt a policy of only accepting valid signed messages, either in the software or in meatspace. And if you can enforce policies in meatspace, you might as well bypass the whole issue and adopt a policy of never disclosing the result of a decryption.

That's what I get for speaking off the cuff.

Re:It's not as broken as you might belive..

[Shamashmuddamiq]

Exactly! How is this news? I have here on my desk a 1996 book by Schneier himself telling me that you shouldn't blindly encrypt and decrypt stuff...

In the section "Resending the Message as a Receipt" on page 43 of Applied Cryptography:
If Bob checked the message for comprehensibility before [automatically] sending a receipt, he could avoid this security problem.

Just like any other good security scheme, there's nothing wrong with PGP, assuming it's used correctly.

jareds is wrong

[jareds]

See this post.

There's no stopping him

[sacrilicious]

The paper comes from Kahil Jallad, Jonathan Katz, and Bruce Schneier.

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!

.

Katz? Damnit!

[DarkHelmet]

The paper comes from Kahil Jallad, Jonathan Katz, and Bruce Schneier

Damnit, I thought my filter on Slashdot was supposed to take his stuff out!

CowboyNeal! Your stupid filter isn't working!

He wrote an errata

[wiredog]

It's called "Secrets and Lies". Also, see the article at The Atlantic.

And the toilette bowl over-flows?

[SlashdotTroll]

Human or bad plumbing?

Duh?

Re:Please stop [trolling]

[Anonymous Coward]

And that proves it's not trolling how?

Re:Please stop [trolling]

[Anonymous Coward]

Because it wasn't trolling. Trolling would be much more straight forward. This is clearly meant to be funny.

Already-compressed data

[p3d0]

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.

In other news...

[thelinuxking]

I found out that if you e-mail out your passphrase and private key, and the e-mail gets intercepted by a malicious user, the malicious user might be able to use the e-mail to decode your PGP encoded messages...

Chosen Ciphertext Attacks

[cpeikert]

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.

If I wanted to scare terrorists

[Anonymous Coward]

It seems pretty unlikely for anyone to be unaware enough to go along with all the requirements for this to work.

But it occures to me that this could have been on interesting disinformation opportunity to scare less technically aware terrorists to avoid using PGP (who knows, they might try a less secure alternative that the Fed can decrypt).

Jonathan Katz?

[eddeye]

The guy mentioned in the article wouldn't be the same Jon Katz who used to write rants^H^H^H^H^Heditorials for Slashdot, would it? I thought he died 3 years ago. Right about the time I discovered the Slashdot story filters.

Smiley Hell

[Shamanin]

Did you actually believe that it was an errata from Bruce Schneier? Obviously not, but by your "common practice" I should have put a smiley after that sentence also.

I don't believe in emotion icons, for centuries we have done without them yet communicated our ideas accurately. This "common practice" is just another step to dumbing down quality sites such as this.

I am not 6 years old and thus not amused by simple key combinations.