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.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
