[hashcash] Re: key management and signatures
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 2 Jun 2004 01:52:15 +0100
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
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
lose stamp value because of that field. As long as there's no metric
"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,
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
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
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
from: Jonathan "Chromatix" Morton
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts: