[hashcash] Re: hashcash v1 questions

Justin wrote:


Absolutely.  I like key-fingerprint-based whitelisting, but I don't like
having keys in hashcash stamps.  Generating a 25-bit collision on an ~1100
byte hashcash stamp would require nearly 4x the time necessary to generate
the same 25-bit collision on a 64 byte stamp.  Putting keys in hashcash
headers benefits those with insecure keys.

fair enough. I am unfortunately not knowledgeable enough to say whether or not moving the keys out of the stamps is a good thing. I am relying on Adam for direction.

There's no security benefit in putting keys in the hashcash header.  If
camram really needs keys (or other miscellany) sent in message headers,
can it use its own headers rather than bloat hashcash by adding all sorts
of options for key transfers?

it certainly can.

If camram puts keys in headers, I'll probably pull them out and import
them if the message has sufficient postage.  And while I can understand
why camram might put keys in headers, I don't think headers are a
reasonable place to put 700-byte base64-encoded strings.  I'm not at all
happy about the prospect of those 700-byte strings being in _hashcash_
headers.

OK, give me an alternative key propagation method that:

1) operates completely peer-to-peer
2) requires no user involvement

and if you want to change away from public key cryptography,

3) provides a sufficiently high barrier against forgery by spammers
4) low enough computational load so that mailing lists can use this technique

one thought that comes to mind is to try and use elliptical curve techniques because, if memory serves, the keys are smaller for the same strength. I believe unfortunately the techniques are patented and I am reluctant to go ask for permission without an introduction.

--- eric

Other related posts: