[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] 6. Email Path Verification

Scott Nelson explained:


At 12:38 AM 9/13/03 +0100, Jonathan Morton wrote:
I like the idea of hashcash as an increase-spammer-costs strategy, but there's one big fly in the ointment. The computational requirements effectively make a hashcash-based system impractical for small, ultra-portable or autonomous devices.


No problem - compute power is cheap. I can, today, buy an 800 Megahertz PC for $200.
Assuming I buy a new one every year, that's still over 1200 seconds of
compute time for a penny. Adding two minutes of compute time
to a delivery means adding one 1/10 of a cent to the cost.
A 20 bit hashcash stamp would take less than 5 seconds, about 0.005 cents.
I'd be happy to generate 20 bit hashcash stamps for your low power
device for 1/10 of a cent,
provided you bought them in batches of at least 5000.
I really must find the time for a camram FAQ:

You assuming that the costs camram puts on a spammer are financial. They are but only indirectly. Camram imposes a time penalty on sending messages. Given a three second stamp, T1 data path yields a 140X slowdown for a spammer. Add a couple of bits to the stamp and the slowdown is now 560X. In the spam world, revenue is a function of volume. Slow them down and you reduce their revenue. Slowly it down enough and you end up with reducing or eliminating profitability.

Now, one might think you would be easy to put together a room and run 150 or more machines generating stamps. The problem is generating stamps creates heat and lots of it. It is working that CPU to death. That means the systems must be extremely well cooled and the server room must have very two to three times the normal cooling level. If you don't, you end up with rapidly failing machines.

Take this observation to absurd directions and you get the impression that one could target spammers with heat seeking missiles... ;-)

what I am really trying to point out is that the large-scale generation of stamps is not a trivial proposition and puts costs in terms of time, infrastructure and personnel on a spammer.

always work the math on problems like these from many angles because the desired effect may not always be obvious. I learned that lesson when trying to analyze why we have monopolies at last mile and the construction of duplicate facilities just isn't going to work.

And therein lies the real problem - Spammers won't have any trouble generating 20 bit hashcash stamps.
adding 1/200 of a cent to the cost of a spam isn't going to be much
of a deterrent, and that assumes that spammers are using off the self hardware, and actually paying for the equipment.
They could build custom hardware to generate stamps for less, but given that most spam is being sent via trojaned machines,
I think they'd just use the boxes they already "own3d" to send spam
to generate the stamps. Clearly 100,000 trojaned machines can send 100,000 pieces of spam in the same time it takes a normal user to send 1. Open proxies / trojaned boxes used to send spam
is currently estimated in the millions.
remember what I said about not obvious effects and he generation above. If there are Trojaned machines out there and they start generating stamps, they won't get a very high generation rate if they want to remain invisible. If you are generating stamps at any level, performance goes to hell, the machine overheats, becomes unreliable, stamp generation stops. If it is a personal machine then someone is bound to notice a) the performance degradation or b) that something smells bad just before it stopped working. Unless you slow down the stamp generation process, it is clearly visible.

I'm not try to minimize the Trojan problem. It is a serious issue in many ways. However, it does have its limits and is not invisible like the current Trojans. On the plus side, it may make compromised machines easier to find and repair.

---eric



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg