gpg: malformed CRC // feature request

[vedaal at hush.com]

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)

(Please, Please ;-) )

Thanks!

with Respect,

vedaal

 




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427