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

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

* "Patrick J. LoPresti" <patl@curl.com>  on Sat, 29 Jun 2002
| If those 5 million recipients all use X-Hashcash, the spammer has to
| compute a distinct hash for each of them.  Sounds like it works to me.

No, it does not, because the every X-Hashcash recipient needs to keep a
database of used hashes for the system to be effective, and as I already
described -three- times in detail that is a fundamental weakness in the
system that can be exploited by spammers and denial of service attackers.

| X-Hashcash is just hashcash implemented by the end user.  You seem to
| think that this is somehow fundamentally different than having the MTA do
| it, but you have yet to give a very good argument why.

Then you failed to read my posts describing the differences in detail.  In
summary:

X-Hashcash uses a single insecure challenge or a limited number of insecure
challenges that may be used many times by many senders.  X-Hashcash coins
are manually generated by the user "off line" before the message is sent.
X-Hashcash requires the recipient keep a database of spent coins and scan
it for every message received to detect when a coin is respent.  This
database is vulnerable to denial of service attacks in the form of database
flooding, bogus data injected by spammers or attackers (spoofing), false
positives (legitimate mail being tagged as spam due to reused coins from a
spoof or other attack), and false negatives (spam not being tagged because
of coins that appear legitimate).

Hashcash generates a cryptographically secure one-use challenge for every
message sent, much like S/Key and SecurID challenges.  Hashcash coins are
generated automatically in real time by the sending MTA at the time it
attempts delivery; the system is transparent to the end user.  Hashcash
needs no spent coin database -- and thus no overhead to maintain or search
it, and no vulnerabilities due to it -- because coins cannot be reused.

| (Other than failing to work with BCC, but I suspect many people would
| consider that fairly minor.)

Your assumpion is flawed, partially because it is in direct violation of
RFC 2822, partially because "many" is not "all".  See my previously posted
contradictory example.

| Having to keep a database of spent coins is the only extra cost of a
| non-challenge-response implementation, but that database is cheap.  Ever
| use nnmail-treat-duplicates?

Straw man.  .nnmail-cache is a one dimensional table that removes entries
as messages are expired.  X-Hashcash spent coin database is a two
dimensional table -- hashes and time stamps -- that needs to be regularly
pruned based on time stamps and can grow many times larger than stored
messages would indicate, depending on the individual's expiry settings.
They are not comparable either in composition or use.

| If all you want to do is cost the sender 5 or 6 seconds at the MTA
| level, why not just stall the TCP connection for 5 seconds per
| envelope recipient?  It would be much simpler than hashcash :-).

Because it makes the recipient vulnerable to denial of service attacks.

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.