[hashcash] Re: key management and signatures

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 PGP.

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 revocation?

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 lists.

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
mail:     chromi@xxxxxxxxxxxxxxxxxxxxx
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


Other related posts: