gpg: malformed CRC // feature request

Atom 'Smasher' atom at
Mon Aug 9 23:04:16 CEST 2004

Hash: SHA256

> On Fri, Aug 06, 2004 at 07:12:49AM -0700, vedaal at wrote:
>> David Shaw dshaw at
>> 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'm not sure what you're trying to protect against... but this should 
 	gpg [encrypt] | gpg [sign]

which can be decrypted using:
 	gpg [verify] | gpg [decrypt]


  PGP key -
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808

 	"When you have eliminated all which is impossible, then
 	 whatever remains, however improbable, must be the truth."
 		-- Sherlock Holmes (Arthur Conan Doyle)
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?


More information about the Gnupg-users mailing list