what fields to hash with hashcash (Re: A Trial Balloon to Ban Email?)

Adam Back adam at cypherspace.org
Wed May 14 08:34:23 PDT 2003


On Wed, May 14, 2003 at 02:49:34PM +0000, Justin wrote:
> Adam Back (2003-05-14 05:27Z) wrote:
> > Well there are different things you could hash.  This simplest is just
> > to hash the recipient address and the current time (to a day
> > resolution).
> > 
> > The recipient looks at the token and knows it is addressed to him
> > because it's his address.  He stores it in his double spend database
> > and won't accept the same token twice.
> 
> This is just broken.
> 
> How do you know what address the sender was sending to?  You have no
> reliable access to envelope to: addresses.

Well the address the token was minted for is contined in the hashcash
header, and the recipient knows what email addresses he accepts mail
for.  To take your example:

> Joe bcc's james at nowhere.net, politely generating a hashcash token over
> james at nowhere.net and the mesID.  Nowhere.net expands that alias to
> james.t.doe at treas.gov.  

The sender as he Bcc'd james at nowhere.net thinks this the recipient's
address, so it delivers to envelope address james at nowhere.net and for
that delivery adds header:

X-Hashcash: 0:030514:james at nowhere.net:b384c3cc66319383

Then the .forward file forwards to james.t.doe at treas.gov, who reads
his mail; his MUA sees that the message is to james at nowhere.net an
address he reads mail for, checks the collision:

% echo -n 0:030514:james at nowhere.net:b384c3cc66319383 | sha1
000002e07c7aac5697396f41dbb277aee02f6517

sees there are enough bits of collision, and if he hasn't seen this
token before he accepts the mail.

The message will also contain one hashcash header per to or cc
recipient.  (Bcc recipients must be delivered separately because
otherwise bcc semantics are lost -- other recipients should not learn
from the hashcash headers that the bcc recipient received the mail).

> Worse, even if there were a reliable mechanism, all it takes is one
> loose cannon with an open mass-mail list and as long as it doesn't
> delete whatever header (maybe delivered-to:, maybe something else) that
> indicates the list was an envelope to: address, one hashcash token works
> for one email to the entire list.

I take it this comment is about mailing lists?  Mailing lists have to
be treated separately.  The sender probably can't afford to create a
token for each recipient.  (Also he doesn't know the recipient's
addresses).  Mailing lists deal with spam with filtered versions of
lists.

> > After the validity period of a token has expired he can remove it from
> > his double-psend database to avoid the database growing indefinately.
> > (He can reject out-of-date mail based purely on it's date).
> 
> Isn't it simpler to use message IDs for replay detection?  No need to
> look for replays using another mechanism when there's already one that
> works fine, and that many people use for dup detection today.

You have to cope with multiple hashcash headers when a mail has
multiple recipients, Message-ID only suports one header.

For USENET postings putting the hashcash token in the Message-ID can
work because USENET uses the Message-ID to supress duplicates in it's
flooding algorithm, and you could argue that there is just one
recipient: USENET (or the cross-posted group list).

Adam





More information about the cypherpunks-legacy mailing list