[hashcash] Re: stamp creation std. deviation
- From: Jean-Luc Cooke <jlcooke@xxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Fri, 13 Aug 2004 09:23:59 -0400
This policy I'd personally like to see it as "hashcash recomands X bits, but
it is up to the mail-server/procmail user to decide how to filter mail".
Reasons:
1) Mailing lists like linux-kernel may find ti too expensive to compute
hashcash values for 3,000 emails 400 times a day.
2) lots of others
Also, 25bits is very high IMHO.
# openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 2205301 sha1's in 2.57s
Doing sha1 for 3s on 64 size blocks: 1468194 sha1's in 2.54s
Doing sha1 for 3s on 256 size blocks: 970620 sha1's in 2.57s
Doing sha1 for 3s on 1024 size blocks: 415087 sha1's in 2.47s
Doing sha1 for 3s on 8192 size blocks: 68726 sha1's in 2.56s
OpenSSL 0.9.7d 17 Mar 2004
built on: Mon May 24 15:43:33 UTC 2004
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial)
blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -SSL_NO_MDC2 -DOPENSSL_NO_RC5
-DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer ASM
-DRMD160_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 13729.50k 36993.86k 96684.33k 172084.65k 219923.20k
floor(2^25 SHA1-per-hashcash / 2205301 SHA1-per-sec) = 15 sec-per-hashcash
A 1 second hashcash shoujld be fine. Maybe even less.
JLC
On Fri, Aug 13, 2004 at 08:24:10AM -0500, John Honan wrote:
> > Justin wrote:
> > so the question I have is should we raise the spam value in the face of
> > the new more efficient code. Maybe an opening bid at 25 bits?
> >
>
> Is the intention to maintain a 'global' recommended minimum postage value
> that all recipient servers should stick to (e.g. 25 bits) and then
> increase it every year for CPU speed inflation.
>
> Or, is the intention to have the postage value maintained independently at
> each recipient server, and set at their end as they see fit (allowing them
> to increase the value whenever they want)?
>
> The problem with different postage values across servers is the sender
> will have to know the bit value required by the most expensive server
> before sending.
>
Other related posts:
