small security glitches
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Mar 2 08:50:24 CET 2012
On 03/01/2012 07:44 PM, Post Carter wrote:
> 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.)
Have you read the paper you reference above? If not, i recommend
reading it. It's a good paper, and clever cryptanalysis.
That said, the attack described does indeed rely on the victim
decrypting arbitrary text sent by the attacker and sending it back in
such a way that the attacker can read the cleartext. Quoting the paper:
>>> 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.
Do you see how the above suggests that the victim must transfer the
(apparently-garbled) cleartext to the attacker for the attack to proceed?
> Based on this attack, the OpenPGP standard was apperently modified, I believe to add a message integrity component.
Yes, the Modification Detection Code packet was formally introduced in
RFC 4880 as a mechanism to defend against producing garbled decryption
like that shown in the referenced paper:
https://tools.ietf.org/html/rfc4880#section-5.14
I believe that GnuPG had its own implementation of such an integrity
check before the standardization was settled.
> This attack can also be prevented by always signing messages, since then the tampering is detected in the signature validation.
This attack (or class of attacs) can only be fully prevented by the
victim; A responsible crypto user should only quote from encrypted
messages (when replying) if the original message was signed by the
person to whom the sender is replying. So the fix isn't "always sign
messages" (though that's nice and helpful), it's "don't quote when
replying to unsigned encrypted messages".
The clever move by Jallad, Katz, and Schneier was to show a way that a
ciphertext could be modified such that its "cleartext" would look like
gibberish to the victim, but could also provide a decryption oracle for
the attacker. Since the "cleartext" looks like gibberish to the victim,
they might be more willing to forward it to anyone (incluing the attacker).
However, comparable attacks could still work in situations with
significantly less cleverness than that shown by Jallad, Katz, and
Schneier. For example, Alice could send Bob an unsigned,
integrity-protected encrypted message which says:
---------------
The password for our next meeting at the clubhouse is "Pajamas".
---------------
If Eve were to intercept this message (preventing it from reaching Bob),
and then simply replay it to Bob with her address in the "From:" field
instead of Alice's, and Bob decides to respond to Eve with:
---------------
Eve wrote:
> The password for our next meeting at the clubhouse is "Pajamas".
What are you talking about, Eve, we don't even go to the same
clubhouse!
---------------
Then Eve has taken advantage of Bob's credulousness to compromise the
confidentiality of Alice's original message.
Note that even the MDC does nothing to prevent the above attack.
If Alice wants to help Bob avoid this kind of breach of confidentiality,
she can (and probably should) do all of the following when sending
encrypted mail:
0) use an MDC
1) sign her messages
2) make sure the encrypted content of her messages always clearly
indicates that they are coming from her (e.g. concluding the message
with something like "Regards, Alice")
However, even if Alice always does all of those things, if Bob isn't
paying attention (to the warnings from his OpenPGP implementation, to
whatever warnings his MUA shows that highlight discrepancies between the
message signer and message "From:" address, to the content of the
message, to general common sense), he might well still leak the contents
of the message.
This is an unhappy state of affairs, but Bob might also be in the habit
of reading his e-mail out loud to himself at the pub, in which case even
the message interception and replay are unneeded. Eve just needs to show
up at the right hour and drink a pint from a nearby stool :(
For a message to remain confidential, both the sender and the recipient
need to exercise care.
> 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.
I believe the original responses you're referring to were correct. I
don't think that the paper you cite above suggests otherwise.
Regards,
--dkg
More information about the Gnupg-users
mailing list