Are there any best practices for opportunistic message signing?
ikindred at cox.net
Mon Nov 10 15:28:50 CET 2003
I am a developer on the Camram project (www.camram.org).
Camram is an anti-spam system that makes use of hashcash (proof of
work) stamps. Basically it takes X seconds of CPU time to generate a
valid stamp, thereby limiting systems that send spam to only sending
one piece of spam every X seconds. (For background on stamps, see
We are considering designing stamps so as to allow a stamp to
optionally be tied to a particular message body via a (SHA1) digest.
This would prevent a spammer from stealing stamps and reusinging them.
(This problem comes up on mailing lists, where one stamp is used to
send the same message to lots of recipients.)
We are aware, however, that many MTA will alter the message
body content in transit. I would like to know the following:
a) How does GPG normalize the message body when generating cleartext
and detatched signatures?
b) How immune to corruption are GPG's methods?
I have found this OpenPGP RFC:
Section 7 describes cleartext signing. Does GPG do more than
is specified by this RFC? Less?
I've also read over RFC 2015, which discusses signing MIME
It is anticipated that Camram may function as a mail proxy,
opportunistically stamping and signing email from trusted senders.
Are there (non-obvious) tradeoffs between using Armor Ascii vs. Mime
to perform this type of signing?
Since Camram (and in the future other systems), may
opportunistically stamp messages, unexpected alterations could
potentially cause problems delivering mail that the sender would not
expect. (Whereas, in the GPG context, if you signed a message, you
know you signed it. Also, alterations of GPG signatures invalidate
the signature but do not (usually) interfere with delivery.)
(Aside: I know that stamps do not use public key crypto, and
therefore astute reader may object to my saying that the hash is
"signed" into the message. "Signed" just seemed to be the most
approriate word to use.)
Please feel free to reply on or off the gnupg-devel list.
Many thanks in advanced from the Camram team.
The pursuit of perfection is the enemy of progress.
More information about the Gnupg-devel