From: Michael Young [mailto:mwy-opgp97(_at_)the-youngs(_dot_)org]
[snip]
Assuming the usual PGP public key model, the attacker doesn't need the
sender to participate in this plan. In this scenario, the attacker
can alter message traffic from sender to receiver, so he could simply
replace a message with is own well-formed PGP message.
Nothing new here.
Good point. If the message is being secured with a passphrase instead of
the recipient's public key, however (which OpenPGP supports), the attack is
more serious, since the attacker would not normally be able to forge
passphrase-encrypted messages.
This assumes that the receiver's public key is really public.
If it's not, but you can convince the sender to encrypt arbitrary
messages to it, then it's not really very private anyway.
The messages might not be totally arbitrary. You might send a seemingly
innocuous (Word or PDF or XML or JPEG or whatever) document to Alice, and
say "forward this to Bob". Alice reads the document and it looks fine, but
in some hidden field you've squirrelled away a more insidious message which
you plan on cutting out and using later.
But if this is the scenario, then two facts complicate the attack:
M and M' must be formatted as OpenPGP packets; and,
the OpenPGP OFB scheme includes two redundant check bytes.
I believe the redundant check bytes reduce the probability of this attack
succeeding to 2^-16 when the insidious message is not located at the
beginning of the innocuous-looking message. The attacker would have to cut
out the ciphertext block previous to where he spliced in his evil message,
and claim this is the ciphertext of the prefix block. When the legitimate
recipient decrypts this first block, using CFB with an IV of 0, it will
produce bytes that are random from the attacker's perspective, and thus the
attacker won't have been able to anticipate and set the check bytes
appropriately. If the attacker tries to modify the check bytes by bit
flipping the ciphertext and then submitting multiple tries to the recipient
until they match the prefix bytes, these modifications will be fed into CFB
and will destroy the next block of plaintext, thus invalidating the MDC
(even though the check bytes themselves aren't part of the MDC).
If the attacker places the evil message bytes at the very beginning of the
innocuous-looking message, then this caveat doesn't apply cause the sender
will set the check bytes appropriately, and the attacker just needs to
truncate.
(I'll explain in more detail in a separate note when I get time.)
The MDC in OpenPGP is really no more than a checksum, intended to
detect accidental damage. (In fact, during the discussion, I believe
that some folks suggested that it be just a checksum.) Before the
MDC, there was little ability to detect *any* sort of accident -- not
just truncation, but fairly arbitrary internal damage as well. (When
the payload is a compressed packet, the decompression might discover
damage, but then again, it might not.) There was discussion of a
stronger MAC, but I think this was dropped given that OpenPGP has a
strong signature mechanism.
The security note at the bottom of page 65 in the current draft indicates
that this MDC is a security feature, and is intended to provide message
integrity.
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt
It stills seems like switching from SHA1 to HMAC-SHA1 would yield the
desired level of security, possibly using a key derivation function on the
session key to generate seemingly-independent encryption and authentication
keys, though I'm not sure if that's necessary.
Trevor