[hashcash] Re: key management and signatures

Well ok here's the difference.  The hashcash stamp is kind of
authenticated in some weird way.  As you say not encrypted or signed
because there is no sender or recipient key.  However never-the-less
it is perhaps interesting to authenticate headers, extensions etc as
being the ones chosen by the person who expended the x-seconds work to
create the stamp.

For some reason, that wasn't completely registering before regarding the
stamp value field, but another kind soul jump-started my brain.

A sender can't gain from putting arbitrary values in the collision-bits
field in v1. More importantly, the sender can (and will, 50% of the time)
lose stamp value because of that field. As long as there's no metric of
"good" and "bad" keys, what can the sender possibly lose by sending an
arbitrary base64 string rather than a base64-encoded public key?

Because without a genuine public key, they don't get the benefit of being able to send signed mails, without having to generate hashcash first. That's the whole point of tying a signature to hashcash anyway, isn't it?

For a few weeks now, I've had my mind on a hypothetical combined hashcash/signature system, similar in goal to CAMRAM, but probably a bit different in detail. I'm floating this as an example of an alternative approach, not because I'm sure it's better - the details aren't worked out yet, but this might be a good forum to bounce some ideas around.

The signature is done on the hashcash token, which makes it unique per message without having to do PGP-style tricks with the message body. It does mean the signature has to be in it's own header, but it's still only valid if the hashcash is, and the key can still be selected and distributed using the hashcash extension field.

The hashcash doesn't have to be full-strength to have a signature attached to it - even 8 bits (a trivial amount) is probably enough. It does need to be robustly unique to the message, so a good double-spend database design is important.

I don't know much about cryptography, but I can think of several ways of performing the signature that - theoretically at least - make key generation and distribution simple and cheap. One such way is to concatenate the base64 representation of the hashcash token's SHA-1 output with the key itself, and use the SHA-1 of that as the signature.

This is a private-key approach, but if you have a different key for each half of each two-way relationship, it's relatively hard to compromise the key because it isn't distributed widely, and indeed only transmitted in-the-clear once in total, at the beginning of the relationship. The key can be expired after some reasonable time, too.

To prevent maliciously filling the key database up, you could require - say - 25 bits for an unsigned message, but 30 bits for a key introduction (these numbers are pretty arbitrary, and represent a level that might occur after widespread adoption).

After initial introduction, signed messages only need 8 bits of hashcash, and you could make key updates dependent on knowledge of the previous key - for example, making the new key the output of SHA-1 on the old key concatenated with some new random string - obviating the need for another heavy computation unless the key is compromised. (This method also makes it impossible for an attacker to force a recipient to change to a known key, even if he knows the original.)

One interesting property we can make use of, is the ability to transmit relatively complex requests and responses within the hashcash extension field. This means we can piggyback on messages sent explicitly by each user, rather than generating mails purely for protocol purposes. A side benefit is these communications are signed along with the hashcash token itself, so can be relied upon as being relatively authentic.

The latency of such requests and responses is unknown and can be long - and messages can be dropped by accident - but since we're explicitly concerned with an ongoing, full-duplex relationship, we can consider it to be relatively reliable, like TCP. It's rather like talking to a Mars probe.

Thoughts? Concerns?

A potential problem, which may not be limited to my scheme, is what happens for users who access the same e-mail account via different computers and/or MUAs. For example, my mother uses Eudora on a PC at her artist studio, collects mail from the same account using Yahoo on other machines, and I'll have the pleasure of introducing her to MacOS X Mail at home next month. She's also the type of user where additional or needless complexity is completely untenable, so she'll only be able to adopt a scheme that has fully matured and is essentially invisible. She would like her inbox to be free of spam and viruses, though.

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