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(_dot_)demon(_dot_)co(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg