gpg: malformed CRC // feature request
atom at suspicious.org
Mon Aug 9 23:04:16 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
> 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'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 - http://atom.smasher.org/pgp.txt
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
-----END PGP SIGNATURE-----
More information about the Gnupg-users