Jon Callas writes:
On Fri, 12 Mar 2004 09:23:44 -0800, Hal Finney said:
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.
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.
I want to clarify that in this case, it was not the signer at fault.
I wrote a legitimate message which send DON'T SEND THE DATA TO ALICE
and clearsigned it. Afterwards, an attacker (who happened to be me
in this case, because I didn't have a real attacker handy) modified my
clearsigned message by adding a CR and spaces to obscure the word DON'T.
This leaves the message apparently saying SEND THE DATA TO ALICE, the
opposite of what it is supposed to say.
The message still verified OK because we stripped off the CR and the
spaces for computing the hash, at the receiving end. These characters
were not present at the sending end (because the attacker had not yet
intervened). So both ends computed the same hash.
Now, the output of the clearsig verification includes a new copy of the
message, and that copy can (and should, and did, in my implementation)
have the trailing CR and spaces removed. So that copy of the message
does include the word DON'T. If the recipient only looks at the output of
the verification process, he won't be fooled, as long as the UI replaces
the message with the stripped version, or otherwise makes sure that the
user sees the version which is output by the verification process.
But if the recipient had read the initial message and gotten a sense
of its meaning, then did the sig verification and didn't closely look
for changes, he might have been fooled.
Or, more relevantly for our documentation purposes, if the OpenPGP
implementation had not replaced the input with the stripped version,
the verifier would also have been fooled. (One reason an implementation
might not want to do this replacement is to preserve the ability to
re-verify the signature at some future time.)
There is a general rule in crypto signature UIs: sign what is seen (i.e.
"what you see is what you sign"), and see what is verified. That is,
on the signing end, make sure that what your code signs corresponds to
what the user was seeing when he gave you the data. Don't transform the
data before signing, and don't add stuff that he didn't see. And on the
receiving end, make sure that the user sees what is actually verified,
and isn't confused into thinking that some other data was verified when
it actually was not.
We might want to include a reminder of these rules. If they are followed,
I think that whitespace trimming issues will not introduce security
vulnerabilities.
Hal