Subject: Re: cleartext signatures - trailing white space - proposal

From: "Hal Finney" <[email-masked]>
Date: Fri, 12 Mar 2004 09:23:44 -0800

There was a mention some time back of a possible attack on the proposed
algorithm:

DON'T SEND THE DATA TO ALICE

After signing this message, I've added a CR and 5 spaces to the above
line, which will obscure the word DON'T on some systems.  The signature
will still verify if we strip CR with the whitespace, but a superficial
look at the message may produce the wrong impression.

Hal

---

From: Ian Grigg <[email-masked]>
Date: Fri, 12 Mar 2004 13:10:37 -0500

I've thought about this too, but I couldn't come to a
conclusion w.r.t., the line trimming issue.

It seems that an attack succeeds or fails no matter what
is done with the trailing whitespace, and the real issue
is whether the display system will be fooled or not.

If whitespace is not trimmed, then the attack is done
pre-signing, so the result is a signed/verified message
that says two different things depending on which system
it is displayed on.  And the original intent is lost.

If whitespace is trimmed, then the attack can be done
post-signing, and the two different meanings are again
presented depending on the display system.  But the
original intent is clear.

Which is better/worst is not clear to me, YMMV.

Perhaps the answer is to put a warning in the ID that
states to effect of:

     Trimming whitespace may open a cleartext signed
     message to an attack of overstriking of key parts
     of text.  Display of cleartext signed messages
     should take care to strip whitespace before display
     (both before and after signing and verification).

?

iang

Hal Finney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: McAfee E-Business Server v7.1.2 - Full License
> 
> iQA/AwUBQFHx3asSfKQ41E4qEQJpoACg917UqU5xQNrAiKWbW5b8bFqkfHoAnRZU
> myqu4AvEwpkH+kpl9+Axztg4
> =tCiJ
> -----END PGP SIGNATURE-----
>

---

From: Werner Koch <[email-masked]>
Date: Sun, 14 Mar 2004 19:28:37 +0100

> look at the message may produce the wrong impression.

Right.  So better forget about cleartext and only use binary
signatures; then another application is reponsible to take care of
such things ;-)

  Werner

---

From: Jon Callas <[email-masked]>
Date: Tue, 16 Mar 2004 09:36:57 -0800

> signatures; then another application is reponsible to take care of

I think Hal gives a beautiful example of a thing that digital 
signatures both can and can't solve. If someone signs a message that 
has in it obscured meaning, it's not the signing program's fault the 
meaning is obscured.

And yet, a properly verifying signature shows that the signer was up to 
no good, and whatever the outcome, the perfidy is there for anyone to 
see.

In the past, we have discussed other semantic attacks where an 
encrypted and signed message is decrypted and then publicly displayed 
for all the world to see, possibly to the consternation of the sender. 
I think that this "attack" is in this case the purest form of justice.

However, this doesn't get us any closer to what we should do.

I think the discussion has drifted away from what *trailing* 
characters, if any, we should have stripped. Remember, it's only 
trailing characters we should trim.

It is also interesting to discuss what happens in weird files -- ones 
that mix different types of line ends, but that's not strictly 
relevant. Even thought this is adding fuel to a fire I'm trying to 
squelch, I feel compelled to add in that there are some file systems 
that are record-oriented. In those a line-end is an out-of band thing. 
Deciding what a line-end is, and therefore what is trailing is an 
implementation-specific issue, anyway.

The argument I see against trimming anything <= 0x20 is that it makes 
it difficult or impossible to sign a file with a form feed or vertical 
tab. That the RFC/draft itself is such a file is an amusing irony. So 
there goes that proposal.

Here's another proposal, which I have edited in, and is thus now my 
default solution:

5.2.1 is made more explicit thus:

    0x01: Signature of a canonical text document.
        This means the signer owns it, created it, or certifies that it
        has not been modified.  The signature is calculated over the
        text data with its line endings converted to <CR><LF> and
        trailing spaces (0x020) and tabs (0x09) removed.

In 7.1, the confusing and arguably (I have argued this) silly text

    Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
    any line is ignored when the cleartext signature is calculated.

is changed to

    Also, any trailing whitespace -- spaces (0x020) and tabs (0x09) --
    at the end of any line is removed when the cleartext signature is
    generated.

Should this not be acceptable, here is a more radical suggestion:

How about if I remove any trimming requirments (since this is 
inconsistently done) and put in an implementation note that says that 
implementations might want to do text massaging on textmode signatures, 
and trimming trailing whitespace (for some suitable definition of 
whitespace) is a reasonable transformation that an implementation might 
want to do. I'm thinking I'd also put in that there are also other 
reasonable checks a signer could do, such as checking for overstriking, 
scanning tags for foreground and background colors being close, 
deceptive statements such as "This is a verified PGP message" and so 
on. I think I'll leave out that a complete scanner requires solving the 
halting problem.

I am happy to entertain even more solutions, especially the one where 
we just removed any text about trimming or ignoring trailing anything.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 16 Mar 2004 16:13:30 -0500

>        trailing spaces (0x020) and tabs (0x09) removed.

There is a definite reason why whitespace removal is needed for
cleartext signatures, but is there any need for any trailing
whitespace removal for 0x01 signatures (where the huge majority of the
time the file is protected inside a literal packet)?  I do like the
consistency of it.

>    at the end of any line is removed when the cleartext signature is

How about:

    Also, any trailing whitespace -- spaces (0x20), tabs (0x09),
    carriage returns (0x0D) and linefeeds (0x0A) -- at the end of any
    line is removed when the cleartext signature is generated.

This matches what Werner and Ian proposed a few days ago.  I agree
that it is better to include CR and LF in the list.

David