Reputation) User-Agent: Mutt/1.4.1i Ben and Richard CLayton's paper makes several assumptions and we'll see how those pan out in the field as time goes on. We don't really know what the true cost of maintaining ownership of many machines. No doubt much lower than it should be because of poor security on microsoft OSes. But even so there must be some turn over as the user instals AV, firewalls, gets cut off by ISP, gets IP blacklisted etc. The general argument is in the FAQ quoted below. Essentially whatever resources spammers do have, hashcash is going to slow them down because the balance of CPU power vs bandwidth is such that 20-bit hashcahs with current hardware is likely to slow down the output of a typical consumer destkop+DSL line down by afact or 10-100x less spam. (Depnds on CPU power, DSL uplink, and number of Bcc recipients per message). Hashcash costs equal cpu per Bcc recipient. Without hashcash Bcc recipients to the same domain or to a hub cost a tiny bit of bandwidth -- the size of the email address (+"RCPT TO \r\n"). Will it be enough -- we don't know yet, but if widely deployed it would make spammers adapt. We just don't yet know how they will adapt. The other question Ben & Richards paper doesn't explore is the CAMRAM way of using hashcash. In this model you only pay hashcash for _introductions_. After parties have replied to a mail, the mail is whitelisted (short term by address only (risky no auth, joe-job hazard) medium term with CAMRAM email header signatures). If simple hashcash per mail turns out not to be enough, CAMRAM can increase the work factor, as people do not reply to spammers; and many emails are to-and-fro vs first introduction emails. (So the sender can afford to pay more on average). Eric sent a spreadsheet with some of this type of calculation. There may also be some mileage in Hal Finney's RPOW http://www.rpow.net where the legitimate user can re-use stamps he receives. (The scaling issues of the RPOW servers would need to be engineered carefully, there are servers, they can be per eg domain , but still compared to hashash this is more infrastructure as hashcash is pure end-to-end). Adam http://www.hashcash.org/faq/ 2c and 2d | 2c But won't spammers steal CPU time? | | Spammers already compromise security on many users machines to make | so-called "Zombie" armies to send spam from. However currently the | rate at which spammers can send mail on a zombie machine is limited | purely by the speed of those machine's internet links. A typical DSL | user might be able to send 25 unique messages per second each of size | 1KB (assumes 256kbit uplink). Or many more messages per second if the | messages are delivered to multiple users at once (using multiple Cc or | Bcc recipients). Even a 20-bit stamp takes 1/2 second per recipient on | the highest end pc hardware at time of writing. This would slow | spammers down by a factor of 10-100 or more per compromised machine | (depending on whether the messages sent are sent individually or to | many users at once). | | 2d But won't spammers deliver to many recipients at once? | | Spammers commonly optimize the amount of spam they can send over a | given link speed by delivering messages to 100s or 1000s of Bcc | recipients at once directly to an end-site, or to an ISP mail-hub. In | this way they can consume just 3.5KB of bandwidth in sending messages | to 100 recipients compared to the 100KB which would be used to send | each message separately. This would allow a spammer to send 700 | messages per second (assumes DSL with 256kbit uplink). | | Delivering in batches reduces the degree of customization the spammer | can make because all of the message bodies in a batch have to be the | same, but never-the-less is a trick spammers commonly use to increase | the number of mails per second they can send. | | However with hashcash a separate stamp is required for each individual | recipient, which stops this spammer trick. If the spammer has to put a | hashcash stamp for each recipient, even a 3Ghz Pentium 4 can only | generate 2 stamps per second, compared to 700 per second with no | hashcash, so using hashcash in this scenario slows the number of mails | the spammer can send by 350x. Adam On Mon, Sep 13, 2004 at 10:37:47AM -0400, Adam Shostack wrote:

On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote: | Adam Shostack wrote: | | >On Tue, Sep 07, 2004 at 04:13:13PM -0400, Adam Back wrote: | > | >| Well we'll see. If they have lots of CPU from zombies and can get and | >| maintain more with limited effort maybe even they can, and CAMRAM's | >| higher cost stamp on introductions only will prevail as the preferred | >| method. | > | >Adam, | > | > You've thought about this more than me. What do you see as | >equilibrium postal rates if the spammers have 10k, 100k, or a million | >nodes to send? | > | > Will spammers run under nice? Use your graphics card as a | >co-processor? Is the rate of new vulns high enough to keep their CPU | >pools filled? | | We have some figures for that kind of stuff in | http://www.apache-ssl.org/proofwork.pdf.

Thanks! That was exactly what I was hoping wouldn't get said, because I no longer believe that hashcash is substantially useful.

Adam S

--- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'