From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45438 Path: main.gmane.org!not-for-mail From: Stainless Steel Rat Newsgroups: gmane.emacs.gnus.general Subject: Re: [ANNOUNCE] contrib/hashcash.el spam fighter Date: Sun, 30 Jun 2002 03:23:38 -0400 Organization: The Happy Fun Ball Brigade Sender: owner-ding@hpc.uh.edu Message-ID: References: <02Jun24.115740edt.119250@gateway.intersystems.com> <02Jun24.151839edt.119751@gateway.intersystems.com> <02Jun25.104630edt.119271@gateway.intersystems.com> <02Jun28.122222edt.119118@gateway.intersystems.com> <02Jun28.172137edt.119392@gateway.intersystems.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025421906 10264 127.0.0.1 (30 Jun 2002 07:25:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 30 Jun 2002 07:25:06 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17OZ50-0002fR-00 for ; Sun, 30 Jun 2002 09:25:06 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17OZ3z-0002ts-00; Sun, 30 Jun 2002 02:24:03 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 30 Jun 2002 02:24:24 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id CAA02372 for ; Sun, 30 Jun 2002 02:24:10 -0500 (CDT) Original-Received: (qmail 5736 invoked by alias); 30 Jun 2002 07:23:41 -0000 Original-Received: (qmail 5731 invoked from network); 30 Jun 2002 07:23:41 -0000 Original-Received: from h0060978d8c91.ne.client2.attbi.com (HELO peorth.gweep.net) (dqjdkd@24.218.202.161) by gnus.org with SMTP; 30 Jun 2002 07:23:41 -0000 Original-Received: (from ratinox@localhost) by peorth.gweep.net (8.11.6/8.11.6) id g5U7NdF10496; Sun, 30 Jun 2002 03:23:39 -0400 Original-To: "(ding)" X-Attribution: Rat In-Reply-To: ("Patrick J. LoPresti"'s message of "29 Jun 2002 20:20:16 -0400") Original-Lines: 63 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.1 (Cuyahoga Valley, i686-pc-linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45438 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45438 * "Patrick J. LoPresti" 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 \ 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.