files with different md5, but signature checks out ok?

Ingo Klöcker
Thu Nov 22 00:37:01 2001

Hash: SHA1

On Monday 19 November 2001 15:08, Andreas Hasenack wrote:
> The only difference between these two files is that one has lines
> terminating with CR/LF, and the other uses standard unix format (only
> LF or CR at the end, can't remember which one right now).
> So, gpg seems to be ignoring these termination issues. How does it
> know this is a text file? How can it be sure?

In the signature there is a bit which indicates if the signature was 
calculated in binary mode or in text mode (treats all line endings as 
CR/LF). So it has to be specified during signature creation if the data 
is text or binary data.

> This raises another question for me. Some MTAs mangle the messages,
> converting them to/from 8bit, for example, and other things. This can
> potentially corrupt signed messages, right?

Not if you sign the message _before_ it's encoded for transport.

But the right way to do it would be to follow RFC 2015 (resp. its 
successor RFC 3156):
   Multipart/signed and multipart/encrypted are to be treated by agents
   as opaque, meaning that the data is not to be altered in any way [1].
   However, many existing mail gateways will detect if the next hop does
   not support MIME or 8-bit data and perform conversion to either
   Quoted-Printable or Base64.  This presents serious problems for
   multipart/signed, in particular, where the signature is invalidated
   when such an operation occurs.  For this reason all data signed
   according to this protocol MUST be constrained to 7 bits (8- bit data
   should be encoded using either Quoted-Printable or Base64).  Note
   that this also includes the case where a signed object is also
   encrypted (see section 6).  This restriction will increase the
   likelihood that the signature will be valid upon receipt.

Unfortunately signatures will still break if some buggy MTA 
automatically converts messages from Quoted-Printable to 8bit.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see