Re: Opportunistic signatures - a proposed design

Jonathan Morton writes:
> This proposed design builds a signature from a (possibly low value) 
> hashcash token, to provide protection against replay attacks, and a 
> random key which is unique to a particular pair of correspondents.  The 
> signature itself is presented in a message header separate from the 
> hashcash token.  The following is a concise description of the 
> signature format and operation, summarised and corrected from earlier 
> posts.

The issue of using a shared-secret type of signature versus a public-key
signature is being discussed by others.  I will focus on the details of
the shared-secret signature.

> The signature is made by concatenating the SHA1 representation of the 
> hashcash token for the message with the key, and then computing the 
> SHA1 hash of that.  An encoded representation of this hash is then 
> placed in a message header.  (Precise format details for this header, 
> and for the hashcash extension field are not yet finalised.)  The 
> signature is associated with a single sender, who is identified using a 
> hashcash extension.

The cryptographic structure you are describing here is known as a MAC, a
Message Authentication Code.  It takes a shared secret key, and a message,
and produces an authentication code for that message that could only
be created by someone knowing the secret key.  The best known MAC is an
HMAC, which builds a MAC out of a hash function like SHA-1.  The actual
construction of HMAC is slightly more complex than just concatenating
the secret key with the message, but it is still very easy to do.
It is described in RFC 2104, and I would recommend using it for this
purpose.

I'm not sure the purpose of the use of low-denomination hashcash.
If it is there for its costliness, to prevent your buddy from spamming
you in case his computer gets a virus or something, OK, you can keep it.
But it's not clear that it does much good for that purpose.

It may be just that hashcash already supports an anti-reuse database and
you want to exploit that.  If so, you might skip the use of hashcash and
create your own database of signature tokens that you have seen recently.
Then you could use HMAC to sign a string based on the sender of the
message and some random bits (for uniqueness).

Hal Finney