Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Stainless Steel Rat <ratinox@peorth.gweep.net>]

* Simon Josefsson <jas@extundo.com>  on Fri, 28 Jun 2002
| The number of email addresses a person has is usually a constant, so
| the problem is O(1).

And in a list of 500 hashes, which one is yours?  Remember, this is a BCC
list, so there is no association of hashes to addresses.


| I wouldn't reject failed hashcash, I would treat it as mail that don't
| have hashcash.  Hashcash improves the situation in most cases, and in
| the remote cases where it fails, it doesn't make things worse than it
| was before.

This makes no sense to me.  If the purpose of X-Hashcash (not hashcash,
they are NOT the same thing) on a personal level is a spam filtering
mechanism, and you receive a message that has a "spent" coin, you treat
that message as a message that has no coin at all?  If so, then what is the
point of keeping a database of spent coins?


| Not at all, it seems to work fine, if in your example hashcash forces
| spammers to invest in knowledge to get a cluster with 5000 machines to
| work.  Making it expensive to spam is the whole point of hashcash.

You seem to be unaware of what Sub7 is.  Look it up on Symantec's
anti-virus web site.  They describe it better than I can.  It would take me
(as DoS attacker) very little effort to assemble a network of many
thousands of machines, secretly stealing CPU cycles from all over the world
to generate hashes with which to cripple someone's mail server.  The
X-Hashcash spent coin database is a fundamental weakness that can be
exploited.

Real hashcash uses no spent coin database because every attempt to send a
message causes the recipient server to generate a new, random challenge.
Think of it as a one use session key, like an S/Key or SecurID system.
Challenges are never predictably reused so a spammer or DoS attacker can
only generate hashes against challenges in real time.  And the way that
real hashcash scales is that the receiving server can adjust the minimum
collision size based on simple criteria.  For example, a server with a
default of 19 bits could have a rule that says "26 bits for anything in the
korea.services.net block list".  Adaptive servers could automatically
adjust minimum collision size for particular sending servers that appear to
be much faster or slower than the default collision size.

| Also, in practice the collision size people will use will be close to
| 30 bits though, and is increased over time as CPUs gets faster.

30 bits?  You must be joking.  A 30 bit collision is a 1:2^30 probability
At a rate of 200,000 hashes per second (which is pretty fast for a desktop
machine today, actually) it would take on average 5,368 seconds to find
just one collision.  That's 1.5 HOURS.

30 bits?  No way.  Not for another 5 years at least.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.