[hashcash] Re: key management and signatures
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 2 Jun 2004 13:14:09 +0100
Meanwhile, the listserv benefits from positive identification of posts
from A and B, meaning that a spammer must impersonate C or subscribe
themselves in order to spam the list.
While I remember about it, let's deal with key revocation and multiple
keys per sender. The two are related problems, IMO.
A recipient or listserv can accept a second key (or third or fourth,
but not *too* many) from a sender, upon receipt of an additional
key-bearing large-stamp (30 bits in the preceding examples). This
means a sender doesn't have to maintain the same key across all the
machines he uses for e-mail. This is another usability advantage over
Similarly, a recipient can transfer senders' keys to multiple machines
by receiving the key-bearing mail on all of them. This can be done by
leaving mail on the server for some period after reception, and
checking mail on each machine more frequently than that period - many
people already do this, so it would be transparent.
A second option is for the recipient to forward key-bearing headers to
himself. This only requires that the MUA be able to forward with full
headers (most can - if not, the user can cut and paste the relevant
headers manually), and that the receiving hashcash implementation will
accept headers that appear to be in the message body.
A third option is for the sender to realise the recipient has
"apparently forgotten" the key, and react accordingly. The most robust
solution is to generate a new key, but continue to sign using both,
until one key expires without being acknowledged again. Because
signing is a computationally cheap operation in this scheme, and the
signature headers themselves are quite small, *and* there is a limited
number of signatures possible in any given sender-recipient pair, this
should be safe from DoS attack.
So, that takes care of multiple keys and machines. What about
I think revocation takes place when the recipient realises the sender
appears to be doing spammy things. Several MUAs already have a "this
is spam" button, which could invalidate all known keys used to sign the
spam in addition to it's present effects. This must be used with
caution in a mailing-list context, however. A better solution would be
an explicit "Don't let this person send me mail without hashcash"
button, which only appears if the mail was signed with one or more
valid keys, and which the MUA should disable for recognised mailing
A list moderator has two options to work with. If the spammy
subscriber is apparently well-known to the list and of previous good
character, and has multiple keys, and only one of them was used in the
spam, then the compromised key can be invalidated at the listserv
without badly affecting the real subscriber. If the above conditions
do not hold, then the moderator must unsubscribe the sender, optionally
telling him why and what to do about it.
from: Jonathan "Chromatix" Morton
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts: