From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45430 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: Fri, 28 Jun 2002 20:41:24 -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 1025311356 22242 127.0.0.1 (29 Jun 2002 00:42:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 29 Jun 2002 00:42:36 +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 17O6Jw-0005md-00 for ; Sat, 29 Jun 2002 02:42:36 +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 17O6JC-00080R-00; Fri, 28 Jun 2002 19:41:50 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 28 Jun 2002 19:42:10 -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 TAA00261 for ; Fri, 28 Jun 2002 19:41:57 -0500 (CDT) Original-Received: (qmail 7639 invoked by alias); 29 Jun 2002 00:41:27 -0000 Original-Received: (qmail 7634 invoked from network); 29 Jun 2002 00:41:27 -0000 Original-Received: from h0060978d8c91.ne.client2.attbi.com (HELO peorth.gweep.net) (jryavq@24.218.202.161) by gnus.org with SMTP; 29 Jun 2002 00:41:27 -0000 Original-Received: (from ratinox@localhost) by peorth.gweep.net (8.11.6/8.11.6) id g5T0fOO02861; Fri, 28 Jun 2002 20:41:24 -0400 Original-To: "(ding)" X-Attribution: Rat In-Reply-To: (Simon Josefsson's message of "Sat, 29 Jun 2002 01:03:26 +0200") Original-Lines: 59 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:45430 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45430 * Simon Josefsson 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 \ 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.