[hashcash] Re: Opportunistic signatures - a proposed design

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.

Good catch - I'll try to remember to look that up. No need to reinvent the wheel.

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

Well, there are actually several bits of code from hashcash that could stand to be reused. First is the double-spend database on the receiving side. Second is the random number generator interface on the sending side. Some platforms (Linux and the BSDs, including MacOS X) have easy access to a decent random number generator - others (*ahem* Windoze) require a bodge job. Getting this right is great fun that should be repeated as seldom as possible.

Another thing is that I want to be able to send messages related to key management between the endpoints. First there is the key itself, then there is the acknowledgement that it has been received, and finally there is the command to rotate a key. It's also necessary to identify the sender, not just the recipient.

The hashcash extension field seems like a natural place to put this information, especially as identifying the sender eliminates the possibility of accidental collisions (resulting in a hashcash token being needlessly invalidated) in hashcash itself. Since the hashcash token is what is signed, this also neatly takes care of authenticating the key-management messages.

--------------------------------------------------------------
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: