gpg: malformed CRC

[David Shaw]

On Thu, Aug 05, 2004 at 11:32:53AM -0700, vedaal at hush.com wrote:

> gnupg provides the best solution here, by allowing you to ignore it,
> 
> and go ahead and decrypt, but still informing you of an alteration,
> 
> there are some (admittedly far-fetched) spoofs that are prevented by
> having the checksum intact:
> 
> for example,
> let's say that Alice and Bob are corresponding about sensitive issues,
> 
> that Alice does not want anyone to know about, especially Alice's problem
> acquaintance, Charlie.
> 
> it is possible for a middleperson to get Alice upset and Bob in trouble,
> 
> by intercepting the message,
> and adding another packet of a session key encrypted to Charlie's public
> key,
> causing Alice to think that Bob simultaneously encrypted to Alice and
> Charlie.
> 
> neither Bob nor Alice can prove that the packet with the session key
> encrypted to Charlie's key, isn't the 'real' session key,
> without being able to decrypt with Charlie's key.
> 
> this would be prevented by a crc and mdc authentication of the 'real'
> message, and not allow any extra spoofing packets to be added.

Neither the CRC or MDC protects against packet addition as you
describe.  The CRC is not secure at all (nor is it intended to be),
and an attacker can just make a new CRC after modifying the message.
The MDC cannot be trivially replaced, but it protects just payload
data, and not the entire OpenPGP collection of packets.

The CRC is really just a quick way to see if an armored message got
mangled in email or Usenet.

It is very easy to create a message that looks like it should be
decryptable by three people, but only one of them can really decrypt
it.  Similar games are possible, like a message that looks like it was
encrypted to Alice, but it's actually secretly encrypted to Baker.

David