gpg: malformed CRC // feature request

[David Shaw]

On Fri, Aug 06, 2004 at 07:12:49AM -0700, vedaal at hush.com wrote:
> David Shaw dshaw at jabberwocky.com 
> Thu Aug 5 21:42:33 CEST 2004  wrote:
> 
> [...]
> 
> >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.
> 
> then i would like to request a feature to provide this type of protection
> ;-)
> 
> no new packet type need be involved,
> 
> it could work something like this:
> 
> [1] once a gnupg command of sign and encrypt is entered,
> the session key for the encrytion should be generated first,
> and encrypted to the public keys of all the recipients
> 
> [2] all the other packets (except for the signed and encrypted message)
> could then be generated
> 
> [3] after all the other packets are generated,
> gnupg could prompt the user with the following:
> 
> gpg: the following packets are included in your pgp message:
> (here it would list each type of packet, including the public keys the
> session key is encrypted to),
> 
> gpg: would you like a hash of these packets added to the end of the plaintext
> of your message , y/n?
> 
> [4] answering 'no', would proceed as gnupg ordinarily proceeds, with
> no hash done, and nothing different included
>  
> answering 'yes' would add the hash after the last line of the plaintext,
> 
> possibly as follows:
> 
> the following line is a hash of the above listed pgp packets included
> in this message, in order to verify their integrity after the message
> has been decrypted
> (hash listed)
> 
> [5] the plaintext plus hash is signed, and then encrypted with the session
> key, added to the other packets, crc and mdc, and sent.
> 
> [6] the crc and mdc still are there for e-mail-mangling alerts,
> and, after decryption and verification, the hash can be used to verify
> the packets and detect any packet 'additions/deletions'
> 
> no new packet is introduced that would require rfc 2440 changes,
> and the hash can still be verified by non-gnupg implementations.
> 
> (it can also allow for an option to include a verbose listing of each
> of the packets, and effectively solve any surreptitious forwarding issues,
>  and detect separations of signed and encrypted messages into clearsigned
> messages)

I think this sort of thing is safely beyond what GnuPG should do
itself.  Manipulating user-supplied input is a dangerous road to go
down.  Nothing stops a user from doing this via a front-end or script
if they desire, of course.

David