small security glitches

[Post Carter]

If Tom McCune simplified explanation isn't detailed enough, check out Bruce Schneier's original paper describing the attack:
http://www.schneier.com/paper-pgp.html
 
The idea is that the decrypted "gibberish" is the encrypted form of the plaintext the attacker inserted.  If the naive user re-sends it to the original sender to ask, "Is this what you meant to send me?" then the eavesdropping attacker has a known ciphertext and plaintext.  (NOTE: The recipient need not send the sender the decrypted plaintext!  That would be no attack at all, just stupidity.)  From the known ciphertext and plaintext, the attacker can deduce the session key and then decrypt the original eavesdropped ciphertext.
 
Based on this attack, the OpenPGP standard was apperently modified, I believe to add a message integrity component.
This attack can also be prevented by always signing messages, since then the tampering is detected in the signature validation.  
 
Anyway, my motivation for posting is that there was a question on this in November 2011 and people responded that the reason you had to sign was to authenticate the message sender.  Although that is also true, it is not the point of the warning.  This attack and the "glitch" mentioned in the FAQ are specifically an attack against the ENCRYPTION that results in potential full compromise of the message secrecy.  The defect in the specification, per Schneier, was the lack of any message integrity check when the message is not cryptographically signed, allowing even the most rudimentary tampering to be undetected.
 
Ciao,
Carter


On 02/29/2012 10:33 AM, Post Carter wrote:

> An individual intercepts an encrypted email.  He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also "decrypts" the addition

> But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key.

The above two steps are clear so far.

>  If the originally intended recipient then sends this "gibberish" back to the original sender (to inquire about it), the interceptor again intercepts this, and now

i'm assuming that the intended recipient sends the "gibberish" back to
the original sender encrypted, right?  if they send it in the clear,
it's hardly the fault of the cryptosystem that the cleartext was exposed.

> has both his original plaintext addition, and the symmetric session key encryption of that plaintext.

eh?  how does it follow that the attacker has both of these?  afaict,
the attacker has:

A) the original ciphertext

B) the modified ciphertext (which they supplied arbitrary data for)

C) a re-encrypted version of the modified cleartext (reencrypted
    against a different session key, presumably).

>  From this, he is able to reverse the XOR processing of the original encryption to produce the plaintext of the originally intercepted encrypted message. 

I don't understand how this follows either.  where does XOR come in?
Which part of OpenPGP is using XOR here?
 
At any rate, this is indeed about message integrity; if you want
encrypted integrity, you need your peer to supply an MDC (gpg does this
by default).  If you want verifiable message provenance with message
integrity, you need your peer to sign their messages.

If Alice does something like take an un-verified message, decrypt it,
and then post the plaintext somewhere anyone can look at it, then the
cryptosystem hasn't failed; but alice has stopped using the cryptosystem.

--dkg
 
--------------
Original Message:
 
I too had seen and been perturbed by this unexplained statement on http://www.gnupg.org/faq/GnuPG-FAQ.html:
"There is a small security glitch in the OpenPGP (and therefore GnuPG) system; to avoid this you should always sign and encrypt a message instead of only encrypting it."
I use PGP for local file encryption and was concerned this applied to that as well, but I now think it seems to only apply to *messages*.  I would appreciate anyone else's analysis of that.
I believe I have found the actual information behind the "glitch," and it *absolutely* has to do with encryption/security and not just integrity/trust.
http://www.mccune.cc/PGPpage2.htm#Chosen-Ciphertext
http://www.schneier.com/paper-pgp.html
Tom McCune's summary from link above:
Chosen-Ciphertext Attack?
The report Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG discusses a potential PGP vulnerability.  This is my understanding of the attack: 
An individual intercepts an encrypted email.  He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also "decrypts" the addition.  But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key.  If the originally intended recipient then sends this "gibberish" back to the original sender (to inquire about it), the interceptor again intercepts this, and now has both his original plaintext addition, and the symmetric session key encryption of that plaintext.  From this, he is able to reverse the XOR processing of the original encryption to produce the plaintext of the originally intercepted encrypted message. 
Although the Open PGP standard needed to be updated to prevent such an attack, this attack was unlikely to actually succeed against a PGP user – PGP compresses before encrypting, in such a manner that this alteration would normally result in a corrupt package. 
If the original encrypted message was signed, this alteration will result in the intended recipient receiving a Bad signature verification. 
The attack would fail under any of the following conditions:
- The recipient takes no action in regards to the received “gibberish.”
- The recipient does not include the “gibberish” in any outgoing response.
- The recipient encrypts his outgoing response to the original sender (as long as the recipient is not fooled into encrypting the "gibberish" to the interceptor's key).
- The interceptor fails to intercept the plaintext response to the original sender. 

PGP Corp states that as of PGP 8.0.2 "special MDC support" includes additional protection against this kind of attack.




--------------
Aaron Toponce aaron.toponce at gmail.com Tue Nov 1 13:35:11 CET 2011 :

On Tue, Nov 01, 2011 at 02:04:31AM -0500, John A. Wallace wrote:
> Hello.  I was reading this page,
> http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-library , and I
> found this comment near the end of it in the section entitled "How does this
> whole thing work?":  "There is a small security glitch in the OpenPGP (and
> therefore GnuPG) system; to avoid this you should always sign and encrypt a
> message instead of only encrypting it."  If this is still applicable, would
> you explain what the small glitch is?  Are there any other small glitches
> explained elsewhere, which I may not have noticed?  There is a lot of
> documentation, and I am hoping to absorb it as much as I can. Thanks.
The "glitch" is exactly as described: you should always sign and encrypt a
message instead of only encrypting it. I could send you malicious encrypted
content, and masquerade as someone else behind a different email address-
maybe someone with a good reputation for security in the OpenPGP community.
Without signing the message, and only encrypting it to your public key, you
have no way to verify who really sent you the message.
Now switch sides. Suppose you're sending an encrypted mail to a collegue.
You're encrypting it for his eyes only. If you don't sign the message, he
may or may not choose to decrypt it. If you sign the encrypted mail, then
he can verify the signature, see if he trusts that key, and make a more
meaningful decision.
The "glitch" is that for security AND trust, messages must be both
encrypted and signed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120301/8f9f5335/attachment-0001.htm>