gpg: malformed CRC // feature request

[Atom 'Smasher']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> 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'm not sure what you're trying to protect against... but this should 
work:
 	gpg [encrypt] | gpg [sign]

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



 	...atom

  _________________________________________
  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?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJBF+bXAAoJEAx/d+cTpVcidw4IAJzhnjDnD16yYrk5EZbIyBGJ
pqBsNBxzT+mOo6erT2YQpstrRGUSEYWfCFxeEYWVvi3WtoRnyczUVWk2YTOPGL/M
WufZdok4Rph4w0yu5UvcMvdg0h6r0/pCArCC98NopzxWa6N4zzvRR1gddPfAjlIE
+GMQRLpliZh6lZ4Yo1XOaqngtGDOspJkU+9NK892nJUWUyBmZvogpyjMcHsEa/aK
d0uF8AmssWLXBp1xqPgEWf0u+g5p9McoXld0FKXnh+V5r4sR0NpvN65rmCvO19Dr
i2LTtVri+uXZmgy7znj8IDyxXfcq5gAZUCbH+6h7Asb6Q/hnmBA6FV1kd81APV8=
=B6BM
-----END PGP SIGNATURE-----