Re: [Asrg] E-postage from first principles

> > > Receipient rate limiting might take the form of hashcash, although
> > > that seems too easily circumvented so long as the bad guys have
> > > zombies to do their hashing.
> > This is a quantitative rather than qualitative argument against
> > hashcash, which is easily answered by increasing the bit count 
> > demanded
> > by the recipient, if it seems it's not having enough effect.
> The problem is that if you increase the bit count demanded from the
> bad guys, you also increase the bit count demanded from the good guys.
> Since the bad guys have more computers at their disposal than the good
> guys do, if you demand a big enough hash from the bad guys to deter
> them, you're going to lock out the good guys altogether, e.g., demand
> a hash from Aunt Sadie that will limit her 486 to one e-mail message a
> week.
>
> You might want to demand larger hashes from bad guys from good guys,
> but if you could tell which was which, you could reject the bad guys'
> mail outright and dispense with the hashes.
Note that SHA-1 is noticeably more computationally expensive on x86 
than most RISC platforms (or, probably, AMD64), which automatically 
makes the present incarnation of hashcash biased against the current 
crop of Wintel zombies.  As a point of comparison, it takes about 2500 
cycles per hash on an Athlon-XP, versus only 1000 on a PowerPC G3 or 
G4.  This has positive implications for third-party vendors - see 
below.
I've partially worked out a scheme which offers two solutions to this 
problem:
- Users with low-end machines (including handhelds) may buy hashcash 
tokens from a stand-alone third party vendor.  This doesn't require the 
micropayment infrastructure that full-blown e-postage needs.  Hashcash 
vendors need only recoup their own costs, thus a competitive market is 
easy to achieve without any need for regulation.
- The stamp optionally includes a signature to facilitate whitelisting. 
 This can reduce the hashcash demanded from regular correspondents to 
as low as 8 bits, which is computationally trivial - thus even low-end 
users will not normally need to buy tokens regularly.  Unlike existing 
high-confidence schemes like PGP and S/MIME, it is only for 
reasonable-confidence identification of regular correspondents, and as 
such is considerably more lightweight and doesn't require anything of 
the message body.
Can anyone shed some light on how many cycles a Z80 processor would 
take to handle a typical SHA-1 hash cycle?  Since derivatives of the 
Z80 may still be used in a few of the lowest-end handhelds, I'd like to 
have a handle on how long it would take for it to generate the 
"computationally trivial" 8-bit hashcash token that the signature 
requires.  If nobody happens to have a Z80 and a compiler to hand, I'll 
put in some work and try it for the 6502 instead - I have a handful of 
old BBC Micros lying around.
--------------------------------------------------------------
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