gpg: malformed CRC

[vedaal at hush.com]

>Message: 10
>Date: Thu, 5 Aug 2004 18:34:51 +0300
>From: Seppo Laaksonen <slaakso at nic.fi>
>Subject: gpg: malformed CRC
>To: gnupg-users at gnupg.org
>Message-ID: <FDE0679F-E6F4-11D8-B159-000393CE2D60 at nic.fi>
>Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>On Wed Aug 4 22:09:09 CEST 2004,  vedaal wrote:
>
>> in general,
>> any armored pgp message that omits the checksum and the footer
>> (both at once) will cause a GnuPG error message of:
>> 'gpg: malformed CRC'
>> and be un-openable in GnuPG,
>> (unless the --ignore-crc-error option is used,
>> in which case, the error message is the same, but GnuPG will decrypt
>> it),
>> but will still be able to be decrypted by PGP,
>> without any error messages.
>
>Vedaal,
>thank you very much. Using the option helped opening the messages
>that 
>I have not been able to open before.
>
>Just out of the curiosity, what is the additional protection that
>the 
>checksum and the footer does provide? I'm wondering why I should
>not 
>use the option by default (or why is it not on by default)? Reading
>>
>from the man-page (now that I'm aware of the option), it seems that
>the 
>checksum and the footer are there just to show that message received
>is 
>exactly the same as the sent one. However, the content is still
>>
>protected.

gnupg provides the best solution here, by allowing you to ignore it,

and go ahead and decrypt,
but still informing you of an alteration,

there are some (admittedly far-fetched) spoofs that are prevented by
having the checksum intact:

for example,
let's say that Alice and Bob are corresponding about sensitive issues,

that Alice does not want anyone to know about, especially Alice's problem
acquaintance, Charlie.

it is possible for a middleperson to get Alice upset and Bob in trouble,

by intercepting the message,
and adding another packet of a session key encrypted to Charlie's public
key,
causing Alice to think that Bob simultaneously encrypted to Alice and
Charlie.

neither Bob nor Alice can prove that the packet with the session key
encrypted to Charlie's key, isn't the 'real' session key,
without being able to decrypt with Charlie's key.

this would be prevented by a crc and mdc authentication of the 'real'
message, and not allow any extra spoofing packets to be added.

using the 'ignore' options allows for the convenience in being able to
decrypt messages with simple benign e-mail mangling,
while still allowing for an 'alert' that the message was altered,
and leaving it up to the user to decide if further investigation is necessary,

(and if there are no 'unusual/unexpected' packets, then nothing further
is necessary)

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