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:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.