gpg: malformed CRC // feature request
dshaw at jabberwocky.com
Sat Aug 7 04:40:55 CEST 2004
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:
>  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
>  all the other packets (except for the signed and encrypted message)
> could then be generated
>  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?
>  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)
>  the plaintext plus hash is signed, and then encrypted with the session
> key, added to the other packets, crc and mdc, and sent.
>  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
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.
More information about the Gnupg-users