[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] Re: 3. About hashcash v1 (was: Proof-of-work analysis)

...which I do. I thought I'd made that clear.

While I don't yet have a document describing exactly how it works, the
essence is that high-value hashcash can be replaced by a low-value
hashcash combined with a whitelisted signature. The signature is also
included with high-value hashcash tokens so that whitelists can be built
easily. The required hashcash value for return mail is indicated by
another header. 

CAMRAM proposes to do something like this.  Their whitelists are based
on signatures.

btw I've been working on an extensible v1 hashcash format, and your
comments about hashing sigs also occurred to me in that context.  See
thread on apr 18-19 on:

http://news.gmane.org/gmane.mail.spam.hashcash

I hadn't seen the v1 format before, it looks like a worthwhile development. I have some comments on it, though.

Instead of separating the random and count fields, I would include the sender's address in the stamp as well as the recipient's. As well as genuinely eliminating the collision problem, having a monolithic "salt" means it is easier to implement an ultra-efficient generator - just add one and redo the block, instead of potentially lengthening a string.

Taking the time to pseudo-implement SHA-1 for the 6502 tends to concentrate the mind on efficiency, and made me realise that the present implementation is far from efficient - especially on x86. I might end up fixing your SHA-1 implementation to be more efficient - if so, I'll send it back-channel.

I would also strongly suggest to keep the hashcash header format simple and monopurpose. Some of your later examples are no longer human-readable, and could even be relatively difficult to machine-parse. The plain v1 format, with optional extensions, is much better than that. I feel that signatures can most cleanly be added in separate headers, especially if they sign the hash (which prevents replaying the signature) rather than the hash covering the signature.

So one could have eg a 12 bit stamp (est 5ms to produce) to defend against people wasting the servers time. ie the server would verify the hashcash before verifying the signature.

The aforementioned 6502 would take about 80 seconds to produce that 12-bit stamp. I was thinking of more like 8 bits, which could allow 8-bit microcontrollers (many of which can usefully run TCP stacks) to use a hashcash/signature system. To be fair, I don't think many people receive mail from 8-bit machines, so this could be a minor issue.

Anyway, I was thinking of signing the hashcash, rather than hashing on the signature. The signature is still only valid if the hashcash is, which actually strengthens the signature because it must be unique and tailored to the recipient.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi at chromatix.demon.co.uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg