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

[Simon Josefsson <jas@extundo.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> | 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 try them all, which doesn't take more than a few ns.  OTOH I rarely
see mail with 500 direct recipients, so this isn't a typical scenario.

> | 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?

To put mail with valid hashcash in a separate, supposedly spam-free,
mailbox.

> | 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.

I don't understand this argument, the whole point of hashcash is that
you need to spend CPU to overcome it.  How you aquire that CPU is
irrelevant.  If all spammers were required to acquire it using sub7,
people would start to fix the sub7 problem, not stop using hashcash,
and things would be fine.

By the same argument, all cryptography has a weakness because you can
brute force it using sub7.  It is not a weakness to me, but a design
goal.

> | 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.

30 bits would allow a desktop PC to send 16 mails per day, that's
probably more that I need.  If you use too few bits (like anything
under 23-24), spammers will have it to easy to acquire that amount of
CPU.  29 bits have been suggested as a value to use in practice.