RPOW - Reusable Proofs of Work

mitd writes "Hal Finney is inviting folks to test drive his new hashcash-based server rpow.net. " The RPOW system provides for proof of work (POW) tokens to be reused. A POW token is something that takes a relatively long time to compute but which can be checked quickly." Hal's security model paper is well worth the read and his proof of concept code is available for download. "

Comments

Umm

[Anonymous Coward]

Can someone explain the concept behind this in a little uhh easier terms. I read parts on the website, but I think I need a bit of background before I can really understand what is going on. Thanks

Re:Umm

[Anonymous Coward]

Spammers send millions of email a second, imagine if for every email they had to do some sums that took 2 seconds, before the server would accept the email...suddenly the rate of emails per second falls.....

Re:Umm

[baywulf]

It is essentially a computer algorithm that is time consuming to calculate but fast to verify. It can be used to mitigate denial of service attacks for example. When a connection is made, the server will make a challenge which the client must compute. The server can quickly verify the response and reject the client if it is wrong. The extra computation means the client cannot succeed in an attempt to connect without doing the challenge thus slowing them down.

Re:Umm

[Anonymous Coward]

Sounds like Amercian Gladiator

Re:Umm

[nova20]

Can someone explain the concept behind this in a little uhh easier terms.

Here's how I understand it:

Imagine you have to do a research paper. Though it takes a long time to write this research paper, what you turn in to your professor is (relatively) quickly checked. The paper itself is like a POW token -- It proves that you did the work without you having to redo the work while the teacher is watching.

-nova20

Re:Umm

[MenTaLguY]

I don't really see how that helps much with distributed DOS attacks, which are the most common variety these days. The number of zombie machines involved is quite mind-boggling.

Re:Umm

[LoudMusic]

It proves that you did the work without you having to redo the work while the teacher is watching.

So in other words we'll have a site in a couple years that has a bunch of POW tokens we can download, change the name, and turn it in as our own? (:

Re:Umm

[stratjakt]

Except that spammers have legions of pwned windows machines that can do the sums for 'em, or under this system, collect RPOW tokens for the spammers use.

Frankly, few companies would be willing to piss away the cash on the extra hardware for this system, and the idea of wasting all that power on all these computations, just for the sake of doing the computations, makes me cringe a bit.

Re:Umm

[Quixote]

Why not just tell the client to sleep for (int(rand(10)) seconds? In any case: keep in mind that HTTP is stateless (since you mentioned DoS, I'll bring up HTTP, a common DoS target). Each web page you load initiates 10s of connections. Imagine having to wait a couple of seconds for each connection to go through. Suddenly, the 1.2sec it takes to load a page like /. now will take 30sec; probably worse than dialup. Now this doesn't seem to hot anymore, does it? If this (RPOW/HashCash) is a form of electronic currency, then I can see a potential; using it to thwart DoS or SPAM is pointless, since we all know that technological solutions to these problems don't exist.

Re:Umm

[nkh]

Does that mean that legitimate mailing-lists servers will have to wait 2 seconds for each e-mails they send? I read a few of these lists and I'm sure there are other solutions to solve spam problems, like killing SMTP once and for all.

If RPOW is trying to slow down spammers, it won't work as it has been already told thousands of times: Windows 0wned machines computing hashes like a cluster...

Re:Umm

[Anonymous Coward]

"amercian"

Hmmmm... that word has possibilities. I just know there's a joke in there that's just "dieing" to get out.

Re:Umm

[masoncooper]

I know you meant to be funny but in a sense, you're right. These reusable tokens can be, well, reused. So if someone were to send you an email with a token, you could use that token(or token based on the previous token) to send an email out without having to create a new token. Since spammers are primarily outbound senders they wouldn't accumulate the tokens that a normal corporation would with frequent two-way communication. In effect, this is a lot like currency.

Re:Umm

[speaker4thedead]

How would this effect valid email lists, like the gentoo newsletter, which people actually want to receive?

Re:Umm

[aardvarkjoe]

Does that mean that legitimate mailing-lists servers will have to wait 2 seconds for each e-mails they send?

This comes up every single time that someone talks about technical means of stopping spam. And every time, we have to remind you that whitelists can solve the problem trivially. (In this case, you have a system where the receiver [you] accept mail without proof of work from mailing lists.)

Windows 0wned machines computing hashes like a cluster...

Right now, cracked boxes are used for sending spam. If you slow down the rate that it's possible to send spam by 1000, then you get a thousandfold decrease in spam.

Re:Umm

[knodi]

So this is a cache of term papers? Or a site where you can watch people type term papers? Just kidding, of course. But okay, so I understand it's hard to make tokens, but easy to verify them. What good is that?

Re:Umm

[Anonymous Coward]

You aren't very bright, are you? Please move on to the next videogame article.

Re:Umm

[Anonymous Coward]

Right, so that when your bank tries to send electronic statements to all of it's 2 million clients, it takes forever. Thus making the system essentialy useless.

A quick calculation with a verification time of 2 secs. shows that abovementioned send will take at the very least 46.29 days to do. And that's if your email generation and sending takes absolutely no time, which it doesn't. Note that by this time you should have sent the second batch of statements, because a month has passed already.

Or when your favourite high-traffic mailing-list becomes retarded by couple of hours every day, and smoke comes out of the server.

Not all mass-emailing is bad. Yes, this does make it difficult to spam. But it makes it equally difficult to do legitimate mass-mailing.

Re:Umm

[bo0ork]

Too bad there isn't more detail about a possible email implementation. Anyhow, I fail to see how this would stop spammers. They have hordes of luser machines to do the (R)POW work for them.

Re:Umm

[SillyNickName4me]

> Right now, cracked boxes are used for sending spam. If you slow down the rate that it's possible to send spam by 1000, then you get a thousandfold decrease in spam.

If only that were true. Currently, despite thousands of Windows machines being used for sendign spam at any given time, in fact only a small part of the compromised machines is actually being used.

A thousandfold slowdown of the rate of sending just means a larger part of all those zombies will be used to get the job done. The factor you talk about is very easy to manage considering the total number of compromised machines out there.

An interesting sidenote, this just makes it more interesting for spammers to pay people to hack into larger computer systems for them to use them to compute hashes (yeah... imagine a beowolf cluster of whatever to compute them ;)

Re:Umm

[slashdotjunker]

4. RPOW uses hashcash for its proof of work (POW) tokens. Hashcash tokens are evidence that a certain substantial amount of computer effort was expended to create them. RPOW allows hashcash tokens to be exchanged for RPOW tokens of an equivalent value, which can then be further exchanged for new RPOW tokens. The effect is similar to being able to pass hashcash tokens from hand to hand while they retained their value, as if they were real physical objects that had an inherent rarity.

Some people have proposed an anti-spam system where spammers need to generate RPOW tokens, but ordinary users can exchange them. Is there anything in the system to prevent copying an RPOW token? If a spammer receives a single good token, couldn't he just make a million copies of that token and send one of each token to each spam recipient? Without collaboration each individual receiver cannot know that it is receiving a duplicated token.

Firstly, I think it is unreasonable to expect mail servers to collaborate to look for duplicated tokens. And secondly, I think that any digital token can be duplicated regardless of any hardware or software copy protection.

Re:Umm

[nova20]

This is probably redundant, but anyway... I'll use an email as an example:

This process forces the sender to spend *more* time to get it's message through than it would for the recipient to have it verified and recieved -- It's basically a counter-spam algorithm. If the spammer has to create tokens left and right, it's going to slow him down a bit, thus the recipient gets less email from one specific person. On the other end, after the token is produced, it doesn't take much time for the recipient server to verify and allow the email through, thus the recipient machine does less work.

Hmmm... I guess it's harder to wrap your head around (and write out what you mean) than I thought.

-nova20

Re:Umm

[FLEB]

If that's the case, you just put a disclaimer on the list, and drop any attempts that take too long. If they don't whitelist, they don't get the mail.

Re:Umm

[Anonymous Coward]

It helps with DDoS by raising the bar. It limits the DoS capability of each individual client and hence forces the attacker to control more clients in order to have a successful attack.

Re:Umm

[ultranova]

A thousandfold slowdown of the rate of sending just means a larger part of all those zombies will be used to get the job done. The factor you talk about is very easy to manage considering the total number of compromised machines out there.

Then you just have to increase the cost. In a way, it's a very free-market system: people keep on getting spam, and thus upping the cost of sending it to them. Eventually, a balance is found between the amount of spam you have to put up with and the amount of legitimate contacts that give up contacting you.

Of course, a really smart system lets you cryptographically sign your messages, and lets the recipient to add the public key to his whitelist, so you typically only need to pay the hashing cost once, unless of course you are a spammer (in which case people will not mark you as trusted).

Re:Umm

[Anonymous Coward]

think about it, do you want those hordes sending spam, or doing sums?

Re:Umm

[bentcd]

Right now, cracked boxes are used for sending spam. If you slow down the rate that it's possible to send spam by 1000, then you get a thousandfold decrease in spam.

Only if generating spam is currently a CPU-bound process. I suspect it is more of a bandwidth-bound process and that it will remain so until significantly more people obtain broadband access.

Re:Umm

[ultranova]

In any case: keep in mind that HTTP is stateless (since you mentioned DoS, I'll bring up HTTP, a common DoS target). Each web page you load initiates 10s of connections. Imagine having to wait a couple of seconds for each connection to go through. Suddenly, the 1.2sec it takes to load a page like /. now will take 30sec; probably worse than dialup.

That's why you'll use HTTP 1.1. It lets you request more than one item without closing connection inbetween (the so-called "keepalive" option in the HTTP request). AFAIK supported by every modern (and most not-so-modern) browser.

This is, after all, what the keepalive feature was designed for; to reduce the overhead of dozens of connections per page request in a graphics-heavy page, allowing you to "pipe" request after request over the same connection - and since connections are statefull, you can just verify the first request of each connection and bypass the verification on rest.

using it to thwart DoS or SPAM is pointless, since we all know that technological solutions to these problems don't exist.

The technological solution to SPAM is to require that all messages sent to you be crypted with your public key, and automatically blocking those that aren't, expect for whitelisted addresses. Having to crypt every e-mail sent once per recipient makes even the SPAM Grendel clusters choke; and, of course, nothing stops you from giving everyone a different public key and revoking (removing from your keyring) those that start returning spam - the good old multiple email address trick, but with less hassle, and no headaches over what to do when spammers happen to find your main address. Just have a program running in your System Tray / Gnome Panel / Whatever which lets you generate new keypairs with a single click (and adds them to your keyring automatically, and remembers where you gave the public key to).

This has the added benefit of giving you better privacy, and the government / mafia / telecomm packet sniffers something to choke on :).

As a side note, it might make sense to verify mailing list posts with cryptographic signatures than whitelists; after all, adress can always be forged.

It is true that there is no technical solution to the general brute force DDoS attack. If the attacker can generate enough requests for a webpage, the server gets slashdotted and becomes unreachable. However, even in this case better technology can keep the server from crashing, allowing it to come back online immediately when the attack stops.

Re:Umm

[Anonymous Coward]

You could do it like this... Find a RSA key with a hash value that begins with 123456. You'll have to generate a lot of keys to find one that matches that fingerprint, but once you do, then you can prove you know the private key by signing messages with it.

Re:Umm

[JamieF]

>you typically only need to pay the hashing cost once, unless of course you are a spammer (in which case people will not mark you as trusted).

They don't need to. If you're a spammer you just use spyware or worms to look for email + private key combinations, and then sell them by the millions on CD.

(All it takes to get around a passphrase protecting the private key is a keylogger.)

Re:Umm

[MenTaLguY]

While that is true, I suspect most DoS offenders already overcommit zombies, and there still seem to be large pools of idle zombies at present which could be drawn on.

Don't get me wrong, I think something like this might put the squeeze on those with smaller zombie nets, but in general I think the blackhat community would be able to cope.

Re:Umm

[Antique Geekmeister]

And every time, we have to remind you that whitelists are easily occupied by zombied machines, especially for the big email providers like Hotmail, AOL, Earthlink, big universities, etc. Expect a temporary halt at best, and lots of your friends and relatives and business partners telling you to go blow yourself for insisting on a challenge-response system. That's what the "hashcash" system is under the hood.

Re:Umm

[siriuskase]

It's ust another line item fee on the bank statement, probably double the actual cost to them, banks always figure out a way to get paid back with interest.

Re:Umm

[aardvarkjoe]

And every time, we have to remind you that whitelists are easily occupied by zombied machines, especially for the big email providers like Hotmail, AOL, Earthlink, big universities, etc.

Uh ... do you even know what a whitelist is? Having a zombie machine doesn't do a spammer any good at all; one person isn't likely to be in the whitelist of more than a few dozen people.

Re:Umm

[Torne]

The RPOW server keeps a db of used tokens. To validate the token, instead of doing it locally as with the original hashcash system, you send it off to the RPOW server and if it's valid and has not been used before, it will send you back a new token of equivalent worth (which both tells you that the token you were given was valid, and allows you to use that token yourself to, say, send outgoing mail). This has the convenient side effect that people who receive at least as much email as they send (i.e. non-spammer, non-mailing-list-server machines) won't have to generate any tokens themselves, thus avoiding any delays to sending mail.

Re:Umm

[ultranova]

They don't need to. If you're a spammer you just use spyware or worms to look for email + private key combinations, and then sell them by the millions on CD.

Then you simply kick their status back to untrusted until they change their key, forcing them to pay the hash. This could even be done automagically by a Bayesian filter - if a given key is associated with enough non-spam messages, make it trusted, if it starts spamming you, make it untrusted.

Such a CD would become worthless very quickly.

(All it takes to get around a passphrase protecting the private key is a keylogger.)

After being downgraded to a spammer by enough people, even the worst Windows users should start getting pretty interested in keeping their machine deinfected.

Re:Umm

[Antique Geekmeister]

Yes, I'm extremely familiar with whitelists and blacklists. You seem to think that the spammer in these zombied cases will use the zombied machine to send the email directly to the target. While this has often been true, the spread of techniques such as SPF (at http://spf.pobox.com) that create some level of domain authentication for the sender will cause the viruses and spam zombied machines to use the local SMTP servers for their domain. Next, the aol.com and hotmail.com zombied machines will find and go through their local SMTP servers and carry the spew with domain names that almost everyone must whitelist due to the commonness of such email addresses. Such techniques were pioneered years ago by Cyberpromo.com, deliberately spewing their spam from domains with good reputations to make sure they were on the whitelists.

Re:Umm

[aardvarkjoe]

"Doctor! It hurts when I do this!"

"Then don't do that."

What kind of idiot would design a whitelist that only works on a per-domain level? Nobody's going to whitelist "*@hotmail.com", that's just stupid. In fact, you wouldn't even want to whitelist your contacts; it's far better to only whitelist mailing lists.

Huh?

[stratjakt]

A hashcach POW token?

What does this server "serve" exactly?

I'm not sure submitters know quite what "article summary" means.

Re:Huh?

[Anonymous Coward]

Hows about RTFA?

"[his] security model paper is well worth the read"

Re:Huh?

[stratjakt]

What FA?

The link to the email? Ok, he has a box with some fancy IBM crypto co-proc in it. That clears things up.

Or his actual server, the one that's completely inaccessable?

20 bucks says the article submitter doesn't even know what this is. He just came across it and figured "bet thats tech sounding enough to get me some slashdot karma".

What problem does this solve? Spam? Hacking? Windows vulnerabilities? Will this put Linux on the desktop? Does this even have anything to do with linux? /. editors don't even know what this is. That's why the story has regular /. colors and wasn't crammed into one of the "sections". Is it a game? Something to do with IT? Anything about how much MSFT sucks and how awesome Apple is in the article? This the new dual screen gameboy from Nintendo? Will I get faster Doom 3 frame rates?

Re:Huh?

[teemu.s]

my guess: cause its unfair if they would not be reuseable. you spent time/money/cputime for getting such a token - so if you spend them - you loose this. but if they are reuseable - and because its about pow tokens, where it can be proven, that you did that work - you just exchange your once made pow token against another and use it for e.g. outgoing email:

form the website:
"Using RPOW tokens for email would have advantages, as people could then reuse tokens from incoming email in outgoing email. Spammers will have no such advantages since almost all of their email is outgoing. Reuse allows the cost of the POW token to be much higher since most people won't have to generate them, making the system more effective as an anti spam measure."

Re:Huh?

[stratjakt]

So spammers spam each other (or themselves from a different host) and have an endless supply of RPOW tokens. No problems solved.

Noone's going to install dedicated IBM crypto hardware in their mailservers. No company is going to invest big bucks in a mailserver just so it can run 100% CPU utilization all the time for no good reason. That costs actual real world money, and continues to cost in power usage.

Besides, I thought we didn't want that kind of "secure" hardware in our machines. We don't want it when it's called Palladium or TCPA, at least.

The only use the article gives that makes sense to me is that of "play money for internet games". That'd work. An imaginary solution to an imaginary problem.

Re:Huh?

[It'sYerMam]

If those who programmed mailservers would build in a delay between a person's outgoing emails, then we could do away with this.
The spammer could send as many as he wished, but they'd get caught up in the server, giving the same effect as a POW system but without the possibility of cracking.
Of course the spammers could set up their own little server, but that'd be DoSable/Legally Take Down-able.

Re:Huh?

[armando_wall]

I don't get it...

ObviousGuy?

Re:Huh?

[teemu.s]

this "spammer spam each other/themselves" scenario would need the fact, that a normal spammer has the ressources (MTAs) doing so - do you think, they run their own MTAs in .tw?

Re:Huh?

[stratjakt]

Build in a delay? You mean in all the open source mail software thats used?

Surely noone would be smart enough to open the sendmail sourcecode and comment out the wait() lines.

All these schemes that rely on your computer "wasting time" to stop spam are silly.

I know, we can stop the spread of warez by making all file serving protocols automagically cap themselves at 2kbit or so. HTTP, FTP, P2P apps.. It's an awesome plan!

Wait I got a better one! We all go back to 300 baud dial-up modems. The ones you hand-dial on an old-timey rotary phone and then stick the handset onto the acoustic coupler. That's the ticket! What an awesome anti-spam plan. If you make the internet utterly fucking useless, all the spammers and bad guys will stop using it!

All ethernet technologies will be banned, computers will be networked with multiplexed RS-232 cards, with a hardware limit of 19,200 baud. Think about it, if a machine got infected on your "network", it wouldnt be a big deal, since your network couldn't possible contain more than a dozen nodes anyways. And it would take 20 minutes to "spread" to the next machine.

Actually all my sarcastic schmes are more pallatable to me than letting IBM jam their "trusted" hardware into my case. I dont want TCPA, not from Microsoft, and not from "our benevolent friends" at Apple or IBM.

Re:Huh?

[ifdef]

As I read through the comments on this article, there are a few that seem to indicate that the poster was completely clueless. And then, when I look more closely, I see that all of them were posted by the same person.

Yes, I know that I shouldn't post replies like this, but this is getting annoying. Quite a few people have posted explanations about what this technology could be useful for. Make an effort to understand it, instead of continuing to post "I don't understand" comments.

You said: "Noone's going to install dedicated IBM crypto hardware in their mailservers. No company is going to invest big bucks in a mailserver just so it can run 100% CPU utilization all the time for no good reason. That costs actual real world money, and continues to cost in power usage."

That's absolutely right, and that's the whole POINT of POW tokens. If you are going to send one or two emails, it won't bother you all that much that your computer has to perform a few seconds of computation before your email gets accepted. If you are a spammer and you want to send a MILLION emails, then your computer would have to perform a few million seconds of computation, which would either slow you down tremendously OR force you to pay real money to buy lots of fast computers and power them.

The problem with the CURRENT model of email is that the sender does not have to pay anything to send spam, so they can send millions of them, and it's still worthwhile if they get one reply in ten thousand attempts. But if they had to pay something to send each spam, they would send less.

Junk snail mail senders have to pay for postage, and so, even though they may be annoying, they are not the same kind of problem as spammers are. They tend to send out flyers only for things that they expect to get SOME response for.

You also said "So spammers spam each other (or themselves from a different host) and have an endless supply of RPOW tokens." Again, you've missed the point. If they spam each other, then yes, the recipient now has the ability to send out the same amount of spam, but the sender has used up his tokens by transferring them to the sender. No new POW tokens are created by this process. If I give you $10 and you give me $10, we're NOT both $10 dollars richer -- what I gave you, I no longer have. And if we pass the $10 bill back and forth 100 times, we haven't somehow created $1000 for each of us to spend; we still have the same amount of money that we started with.

And your point about us not wanting secure hardware on our machines is irrelevant. Nothing in this idea implies that you should have secure hardware on your machine. It can all be done in software, open source software (or any other kind).

Re:Huh?

[sk8king]

That's funny. No mod points though.

Re:Huh?

[aardvarkjoe]

So spammers spam each other (or themselves from a different host) and have an endless supply of RPOW tokens. No problems solved.

Unless spammers are selling to each other, this wouldn't help them any. Think of it like conservation of energy. Calculating a POW is like generating energy. Spamming someone requires energy. Spamming yourself just moves energy from one place to another. In the end, you still need to calculate the same number of POWs to spam a set of people.

That costs actual real world money, and continues to cost in power usage.

So does spam. If this was cheaper than the cost of dealing with spam, companies would do it in a heartbeat.

Re:Huh?

[Lehk228]

spammers do not use the 0wned machines to access the users mail server, the 0wned machine becomes a mail server which is part of the virus/trojan used to take over the machine in the first place

Re:Huh?

[imbaczek]

Hashcash POW is basically cash which is computed (instead of earned) and is used to pay for, for instance, acceptance of an email on a SMTP server.

Re:Huh?

[CrackHappy]

Another idea along those lines would be a system for MMORPGs or similar type games where you can purchase items in the store for tokens. You can get the tokens by running SETI@home or folding@home. For each set you complete, you get X tokens to spend in your game. Hell, you could use it that way for almost anything that is applicable to distributed computing. What an incentive to contribute!

Re:Huh?

[vanman2004]

Surely noone would be smart enough to open the sendmail sourcecode and comment out the wait() lines.

Surely noone would be smart enough to read the site first.

This wouldn't be done with wait(), it involves actually calculating a token that needs to be verified before sending email.

taking bets on it's slashdoting

[thexdane]

story just went up and the site is slow, so it won't take long before it's not there anymore :|

More info on Hal can be found....

[zegebbers]

There is some excellent info on Hal here , here and here.

Re: RPOW - Reusable Proofs of Work

[Anonymous Coward]

Hal's security model paper is well worth the read and his proof of concept code is available for download.

"I'm sorry Dave, but I can't let you download that..."

Cracked in 5..4..3...

[Anonymous Coward]

I hope he doesn't use MD5 Hashes.

Verify

[Davak]

Whoa...

I need some ubergeek translation on this one. Is this a complicated, better method for verifying against known published source code?

Davak

Re:Verify

[3-State Bit]

No, I don't think so. The idea of proving you've done some work is that you have made an investment and so are not doing 100,000 such investments per second.

However this probably doesn't work (PDF) [or as html].

Background (from that paper):

It is often suggested that unsolicited bulk email ("spam") is such a problem on the Internet because the current economic framework for email handling does little to discourage it. If only, it is suggested, the senders of email could be made to pay for their messages. Spammers would then cease their indiscriminate distribution of messages and email volumes would reduce as the senders targeted more carefully or just gave up altogether. Nevertheless, almost no one (other than those hoping for a handling fee) thinks that using actual money is a good way to achieve this economic utopia and even the holders of patents for "e-money" systems have failed to generate any significant enthusiasm for their wares.
However, there is an alternative to real-world money, which was first proposed by Dwork and Naor in 1992 [8]. Their idea was to have the sender of an email perform a complex computation as evidence that they believe that an email is worth receiving. The sender then proves to the recipient that this processing work has been completed and the email will then be accepted. The processing time is "free", so there is a minimal burden upon legitimate senders, but it is a finite resource, so that the spammers will not have unlimited amounts of processing time at their disposal and so cannot continue to send in bulk.

Re:Verify

[aardvarkjoe]

However this probably doesn't work

That paper makes a couple glaring errors that significantly reduce my confidence in their results. The first is that it ignores whitelist systems that allow mailing lists to continue to function without needing to pay the price that spammers do: instead, they analyze only the trivial case where every email that is sent has a fixed cost to send. The second is that they assume that such a system has to be guaranteed to eliminate spam, while simply reducing it would be acceptable.

The last sentence of their conclusion is "We leave analysis of such schemes to futurework - fully expecting to be able to debunk some further proposals by the simpleapplication of real-world measurements and values." It's obvious that the authors have something of an axe to grind on this issue -- and so it's not surprising that their reasoning is somewhat flawed.

Re:Verify

[BCoates]

There's nothing wrong with making back-of-the-envelope computations with numbers you pretty much pulled from your ass. However, this paper violates the custom of using numbers and assumptions that err against the point you're trying to make, rather than for it.

Assuming that a hash-cash or other POW system is only useful if, working alone, it reduces the spam in your inbox from ~50% to ~0.1%, that the average machine sends 75 legitimate unsolicited mails (that is, non-spam mails to people outside your organization that you've never gotten a message from before) per day, that the top 1% mail senders on a random ISP are legitmate users who should not be inconvienenced rather than the spammers that this entire system is designed to inconvienience, that currently underutilized zombies will be aggressively used by spammers if POW is established, but will continue to go unused (contrary to current trends) if POW is not established...

Yeah, given that highly realistic model, it "probably doesn't work".

Re:Verify

[pla]

Unfortunately, real-world data from a large ISP shows that these difficulty levels would mean that significant numbers of senders of legitimate email would be unable to continue their current levels of activity.

Translation - Ignoring actual content, mailing lists look very much like spam, and approaches to spam that make sending email "expensive" would also impact mailing lists.

Others have mentioned whitelisting, but I'll take the (IMO) bolder step of saying "Too Damn Bad". If it means I won't get a few thousand spams per week, I'll accept the concept of an email list becoming nonviable.

Greedy, you might say? Hey, I do subscribe to a number of mailing lists. Every single one of them, however, I can read via the web, and only get them emailed to me as a convenience. A convenience, I would point out, that spam completely obliterates, since it takes me far, far longer to wade through the crap and find the legit email than it would to just visit a web page.

So, for those who point out that POW or HashCash or the like would make most larger mailing lists impossible, I have little sympathy. This does not count as a "throwing out the baby with the bathwater" situation... More like a "draining the tub and a tiny speck of still-good soap goes down, but we have another fresh bar in the closet" situation.


Of course, I would still prefer the spam solution of placing bounties on spammers, paying double if the hunter brings them in dead (hey, putting someone in prison costs a lot, y'know). And anyone who considers that idea a joke, well, not even a little.

/.ed

[Dibblah]

Okaaay... So it's a server that's *meant* to serve computationally expensive 'tokens'. And you post it on ./ . Niiice.

Re:/.ed

[FooAtWFU]

Yes, to *serve* the tokens. Not to compute the tokens- other people do that. It'll just give you work and check the incoming result, which is *not* computationally expensive.

Re:/.ed

[jovlinger]

sounds like the job for any problem in NP.

Re:/.ed

[Anonymous Coward]

Not quite. You mean "for some problem outside P". After all, P is a subset of NP... Even some problems outside P are practically solvable: consider for example problems with complexity on the order of (1+epsilon)^(n^epsilon) where epsilon is small.

Re:/.ed

[jovlinger]

well, not all problems outside P are polynomial-time verifiable.

But x in NP and x not in P works...

well.

that was pedantic.

Proofs Of Work are few and far between

[Anonymous Coward]

How about Proofs Of Not Working? Got plenty of those.

Re:Proofs Of Work are few and far between

[Anonymous Coward]

You mean like your post on Slashdot during business hours? :)

Huh?

[julesh]

I don't get it. I understand the concept of what you would use one of these 'POW' tokens for (although the name is clearly ridiculous... acronym clash should be avoided whenever possible) -- e.g. to bypass a junk e-mail filter. But why would you want to be able to reuse them?

Cache

[Klar]

Google Cache after slashdotting... http://www.google.ca/search?q=cache:YHGDB5MH4e0J:r pow.net/+&hl=en

Obligatory Pun

[grunt107]

Given the inaccessibility of the site:
RPOW/rMIA (break out the black flags w/web server silhouette)...

Re:Obligatory Pun

[trb]

I was thinking, hashcrash-based server.

Re:Obligatory Pun

[shadowcabbit]

Yeah, funny how appropriate the onomatopoeia/acronym "POW" is in this case...

Anon posting, ARTICLE TEXT

[Anonymous Coward]

Reusable Proofs of Work
by Hal Finney
(hal at finney dot org)
What Is This? Theory Security Try It Out! FAQs Download

The RPOW system provides for proof of work (POW) tokens to be reused. A POW token is something that takes a relatively long time to compute but which can be checked quickly. RPOW uses hashcash, which are values whose SHA-1 hashes have many high bits of zeros.

Normally POW tokens can't be reused because that would allow them to be double-spent. But RPOW allows for a limited form of reuse: sequential reuse. This lets a POW token be used once, then exchanged for a new one, which can again be used once, then once more exchanged, etc. This approach makes POW tokens more practical for many purposes and allows the effective cost of a POW token to be raised while still allowing systems to use them effectively.
Security

This is useful functionality, but the unique feature of the RPOW system is its approach to security. RPOW is the first public implementation of a server designed to allow users throughout the world to verify its correctness and integrity in real time.

Based on principles similar to those proposed for so-called "Trusted Computing", RPOW allows third parties to dynamically and remotely verify what program is running on the RPOW server. The RPOW server is implemented on a high-quality secure processor, the IBM 4758 PCI Cryptographic Coprocessor, which has been validated to the highest level of security publicly available, FIPS-140 level 4. The 4758 is a self-contained single-board computer which has its own device key, generated on-board, which never leaves the card. That key can issue cryptographically signed attestations which describe the software configuration running on the card, including the SHA-1 hash of the application program.

The source code to the RPOW server is available from the download page. Using publicly available tools, anyone can build from this source code a memory image identical to that running on the RPOW server. If the SHA-1 hash of this file matches that being reported by the 4758 device key, the user can conclude that the supplied source code is what is actually running on the 4758. By inspecting the source code he can then make sure there are no "back doors" or loopholes that would allow the owner/operator or designer of the system to defeat its security, for example by creating RPOW tokens without doing the required work.

Allowing clients to dynamically validate the security of a server turns the concept of Trusted Computing on its head. Rather than a threat to individual privacy, the technology becomes a boon to privacy and an empowering force for end users on the net.
Applications

Security researcher Nick Szabo has coined the term bit gold for information objects which are provably costly to create. He suggests that these could even serve as the foundation for a sort of payment system, playing the role in the informational world of gold in the physical world. RPOW would facilitate the use of POW tokens as a form of bit gold by allowing the tokens to be passed and exchanged from person to person.

POW tokens have been proposed as a form of pseudo-payment in several applications. One example is email. An email message containing a POW token would be relatively costly to send in terms of computing power. A POW token could then be a sign that the message was not spam.

Using RPOW tokens for email would have advantages, as people could then reuse tokens from incoming email in outgoing email. Spammers will have no such advantages since almost all of their email is outgoing. Reuse allows the cost of the POW token to be much higher since most people won't have to generate them, making the system more effective as an anti spam measure.
Transparent Servers
The RPOW system is just the first of what are planned as a series of systems which use this approach, which I call Transparent Servers. Such systems publish their source code for review and inspection, and use Trus

Fragile Mirror

[Viral Fly-by]

RPOW.net Home

FAQ and "What is this?" links also included...

Isn't it obvious?

[BubbaThePirate]

A POW token is something that takes a relatively long time to compute but which can be slashdotted quickly.

But seriously, the server went down after two replies, but not before I managed to get this:

[Read this instead adding a load to a battered server]

"Overview

The RPOW server is designed to provide security and reliability through an unprecedented degree of visibility and transparency in its operations. For the first time it will be possible for any user of the system, anywhere in the world, to know what code is running on the server and to inspect that code for loopholes or back doors. I have done my best to make this system secure even against my efforts as the owner, operator and designer of the system to compromise its operations. I welcome public scrutiny of the code and of the design.

The RPOW system represents a new kind of security model, and is therefore unusually challenging to present and to review. RPOW combines an exceptional degree of physical security with an unprecedented level of transparency and visibility into the workings of the RPOW server. This combination implements the design goal of RPOW as a "Transparent Server", a system whose security properties can be analyzed and evaluated from any system on the internet.

In operation, the RPOW system consists of three parts: the server, the host process, and the client library with its associated demo driver. We will consider each part in turn. "

and this

"RPOW FAQs

Questions

1. What is the RPOW system?
2. How is RPOW pronounced?
3. How do I know the RPOW system is secure?
4. What is the difference between RPOW and Hashcash?
5. What is the difference between RPOW and Ecash?
6. What are some possible applications of the RPOW system?
7. How fast is the server?
8. If RPOW becomes popular, how could one server handle all the users?
9. Won't Moore's Law mean that tokens lose their value over time?
10. Why can't users pass RPOW tokens to each other without using a server?
11. Won't the RPOW server run out of disk space if it keeps track of all tokens it has ever seen?
12. Are you going to make changes to the RPOW system?
13. Why did you choose the IBM4758 Secure Cryptographic Coprocessor as the platform for the RPOW server?
14. Wasn't the IBM 4758 security broken a few years ago?

Answers

1. The RPOW system has three parts: client, host, and server. The client is a software library (plus a simple command-line driver for demonstration purposes) to allow generation and exchange of RPOW tokens. The host software runs on the PC which has the IBM 4758 cryptographic coprocessor card plugged into it. It acts as an intermediary, listening for connections from the net and passing data between client and server. It also assists the server with certain operations. The server runs on the IBM 4758 card and performs the secure cryptographic operations which implement the RPOW system.

2. RPOW is pronounced are-pow.

3. The security of the RPOW system ultimately depends on its design and its implementation. For the design, see the theory and security pages. For the implementation, see the source code available from the download page. The unique properties of the RPOW system design allow you to remotely verify that the program generated from the source code you download here is what is actually running on the RPOW server. If the design and implementation are sound, and that program is what is running on the server, you have a foundation for trust in the security of the system.

4. RPOW uses hashcash for its proof of work (POW) tokens. Hashcash tokens are evidence that a certain substantial amount of computer effort was expended to create them. RPOW allows hashcash tokens to be exchanged for RPOW tokens of an equivalent value, which can then be further exchanged for new RPOW tokens. The effect is similar to being able to pass

Re:Isn't it obvious?

[stratjakt]

So basically, this serves up encrypted blobs of crap that have no meaning other than you can assume the server spent a little time encrypting up the blobs of crap..

And a few mentions of what it "could" be used for, but of course it wont be.

So basically we have another neat solution out in search of a problem. That explains the lack of any "what the fuck is it?" verbage in the article summary. It really isn't anything.

RPOW

[rhs98]

This is the most useless website for a simple explaination of what this is for, or even what it is! Even the faq page doesn't make much sense.

Looks like his server has been tested slashdot style though!

Mirror of article/download

[chrisopherpace]

HERE.


NOTE: Only the source code is mirrored, site is way too slow to mirror the rest!

Re:Mirror of article/download

[chrisopherpace]

Shoot, forgot the download link: HERE .

The file is downloading as I type this, hopefully it will finish so I can mirror it.

Defeating the purpose?

[Anonymous Coward]

Doesn't this really defeat the purpose of computationally expensive tokens? Couldn't a hacker break into the cache and steal a large number of pre-calculated POW tokens which would otherwise be impossible?

Mod parent UP

[Anonymous Coward]

informative.

Re: RPOW - Reusable Proofs of Work

[Anonymous Coward]

Hal's security model was excellent. Dave had to resort to direct hardware access to defeat it.

Easier Explanation of RPOW & RPOW Uses

[diagnosis]

From the web sites:

The RPOW system provides for proof of work (POW) tokens to be reused. A POW token is something that takes a relatively long time to compute but which can be checked quickly. RPOW uses hashcash, which are values whose SHA-1 hashes have many high bits of zeros.

Possible uses for RPOW include anti-spam tokens, "play money" for use in online games and fun bets, an aid to load balancing in P2P and file-exchange systems, and more. Any system which would benefit from a form of token which can be cheaply passed from user to user, but which is expensive to create, might want to look into RPOW.

It's not clear to me that there is an obvious and immediate equivalent for RPOWs in existence. I'd be interested in hearing what people think this would be good for. It generally seems useful for making sure people do x amount of work before they are allowed to perform a task, but what can that be used for?

---------------------
Freedom or Evil: Freevil.net
G. W. Bush says, "You decide!"

Re:Easier Explanation of RPOW & RPOW Uses

[pkhuong]

Virtual money. If we agree that time*computing power=value, then we can assign a value to each token so that there is no gain to be made by creating a new token. While it may seem wasteful - GroupA use x h*flops to get y h*flops back, and x can't be too much smaller than y -, one must keep in mind that the token may be reused, so that GroupA only has to waste x*[number of tokens in circulation] h*flops to receive n h*flops. IE, for the system to work, there must be an incentive to not stockpile tokens. Fortunately, Moore provides us with built in inflation!

Re:Easier Explanation of RPOW & RPOW Uses

[pkhuong]

yes, h*flops is n flaoting point ops. But who'd understand me if i said flo? (**** anal friend, yes i should have said floationg point ops :)

Re:Easier Explanation of RPOW & RPOW Uses

[Pendersempai]

The dollar. Currency, at its simplest form, is proof of value to society: work.

Proof-of-work tokens as an anti-spam measure?

[JaredOfEuropa]

For those asking what on earth (R)POW tokens are, here's one possible application (from rpow.com):

POW tokens have been proposed as a form of pseudo-payment in several applications. One example is email. An email message containing a POW token would be relatively costly to send in terms of computing power. A POW token could then be a sign that the message was not spam.

Using RPOW tokens for email would have advantages, as people could then reuse tokens from incoming email in outgoing email. Spammers will have no such advantages since almost all of their email is outgoing. Reuse allows the cost of the POW token to be much higher since most people won't have to generate them, making the system more effective as an anti spam measure.

An interesting scheme...

One potential problem I see with such an anti-spam measure is that I keep hearing about spam runs being done from many regular users' computers by means of a spamming worm infrection. Such a worm could also be adapted to generate the POW tokens... or even steal them from the users' incoming email and re-use them under this scheme! That'll be just great, having your computer not only hijacked to send out spam, but loaded down with the heavy burden of generating POW tokens.

Re:Proof-of-work tokens as an anti-spam measure?

[4of11]

Although if spammers did use zombied computers, maybe the owners of the infected PCs would know something was wrong when their computer was runnning so slow they couldn't do anything. Right now, these computers can send out tons of emails without significantly hitting its performance. This is key, because if the computer becomes unusable, it will soon not be available for spamming when the user takes it to the shop. Maybe the central server could even put a limit to new keys per hour per IP to limit RPOW factories like this. In any event, spam would certainly be reduced by this, as each zombie could not send out nearly as many emails.

Re:Proof-of-work tokens as an anti-spam measure?

[Quixote]

as people could then reuse tokens from incoming email in outgoing email.

What's to prevent me from sending the same token to 1 million people? Aha, you say: there'll be a central database of tokens to make sure that they are not being rused en masse. And that, then, becomes your bottleneck, making this useless.

Re:Proof-of-work tokens as an anti-spam measure?

[dpilot]

It's worth linking through to the hashcash site, too. It's fast to validate tokens, and you only store valid ones. That keeps the size within reason. Don't know how RPOW handles it, but the date is part of the hashcash token, and you can set the expiry as part of the validation, also trimming your database.

Re:Proof-of-work tokens as an anti-spam measure?

[DM9290]

But at least if your computer is loaded down with the heavy burden of generating POW tokens, the rate at which it can send spam and harm others is reduced. And thus RPOW would have accomplished something beneficial.

Re:Proof-of-work tokens as an anti-spam measure?

[Anonymous Coward]

What's to prevent me from sending the same token to 1 million people?

You can't re-use tokens if the mail server you are connecting to issues a different challenge each time, and you must compute a POW based on the challenge issued by the server.

Re:Proof-of-work tokens as an anti-spam measure?

[Rasta Prefect]

What's to prevent me from sending the same token to 1 million people? Aha, you say: there'll be a central database of tokens to make sure that they are not being rused en masse. And that, then, becomes your bottleneck, making this useless.

No, not really. Generally these schemes involve the token being in some way tied to the specific message. A hash containing the to and from addresses for instance.

Re:Proof-of-work tokens as an anti-spam measure?

[Rich0]

Yes, but how do you reuse them?

Suppose I'm a spammer, I generate one token and use it to send out 1 million emails to hundreds of thousands of different servers. How do the recipient servers figure out that they're being duped?

With non-reusable POW it is simple. The recipient generates a challenge, and the sender calculates the response, which the recipient verifies. A given challenge is only used once, and the recipient can guarantee that by simply using a random number generator - no storage or communication necessary.

On the other hand, if you reuse the POWs there has to be some mechanism for recipients to find out if the sender has used the POW more than once. The only way I can think of is by using a central DB. Now the central DB becomes a bottleneck, since it has to handle a request for every email sent between any two parties on the internet. Sure, you could distribute the load (put a server ID in the RPOW), but now you have thousands of these servers - who pays for them?

Re:Proof-of-work tokens as an anti-spam measure?

[dpilot]

The RPOW website is really easier to understand if you first read the hashcash website it point to. So let's talk first about hashcash, since RPOW is mostly an extension.

With hashcash, I take a datestamp, the recipient's address, and some garbage characters, and put them in an X-hashcash header as part of the email. The garbage characters have been precalculated to give some number of '0's at the front of an SHA1 hash of the header. It's computationally expensive to force those '0's, the more '0's, the higher the expense. (The hashcash site mentioned 4 hours to produce 32 '0's on his system.) But it's cheap to verify that those '0's are there in the hash of the header. That's what makes the system work.

There is no challenge-response in hashcash. You publish a 'price', some number of hashcash '0's, to receive email. If the email is in you whitelist (and presumably has a good SPF) call it good. Call other mail without an X-hashcash header spam. You can then validate the X-hashcash headers on your system. Valid headers are stored, and since they contain a datestamp in cleartext, you can purge them after some interval. Note that you only store valid headers, and only for a limited time, so the database doesn't grow forever.

Hashcash requires no central server or database.

RPOW works off of hashcash. You make a hashcash 'stamp' and trade it in for a RPOW token. Since the RPOW lets that original computational effort be reused, it lets you up the 'price'. ie - require more '0's in the hash.

I haven't read the documentation thoroughly, but I suspect that RPOW is validated at the server, not by challenge/response. But remember that each RPOW ticket is used only once, and once shown secure, there wouldn't be a lot of attempts at spoofing. So the traffic volume (and server requirements) should remain reasonable. In other words, the server traffic would be related to the level of legitimate email, not the level of spam. Oh, when you check the RPOW with the server, it hands back a new RPOW that you can use to send email. As far as I can tell, there is no theoretical (only practical) lifetime limit to the tokens.

I'm less enthusiastic about RPOW than hashcash, simply because of the central server requirement. I also wonder/fear about the feasibility of building an SHA1 engine out of FPGAs that could precalculate stamps faster than any regular PC, and then distribute them to spambots for mailing.

Re:Proof-of-work tokens as an anti-spam measure?

[ArsonSmith]

yea this actually seems rather easy to acomplish. just do something similar to an md5sum but much more intensive on the message + outgoing emails and attache it to the email. a PGP signiature would be a good idea for something to use as well.

Why isn't PGP/GPG setup and configured on installation of all OSS mail readers?

Re:Proof-of-work tokens as an anti-spam measure?

[Wesley Felter]

Generally these schemes involve the token being in some way tied to the specific message. A hash containing the to and from addresses for instance.

Yep, but that doesn't work if you want to make the POWs reusable.

Re:Proof-of-work tokens as an anti-spam measure?

[Wesley Felter]

If RPOWs are really worth something, you could set up a currecy exchange to convert them to real money, and RPOW servers could fund themselves with a transaction fee (which would be paid in RPOWs themselves, naturally). It wouldn't work for many reasons, but it's an interesting idea.

Re:Proof-of-work tokens as an anti-spam measure?

[siriuskase]

This reminds me of Seti@Home workunits, each one takes several hours to generate and and then you send the results back to Berkeley where they have some magic to make sure you don't get credit for the same work twice.

Someone even wrote a virus that would install Seti@Home on zombie computers that would run the CLI version in the background and upload workunits to be credited to whoever the hijacker designated. If the zombie owner never checked his background tasks, he probably just thought his ISP was slow, especially since seti runs with a low nice priority.

The first hacker to release a virus to run the POW generator in the background is going to get rich, but then the zombies will start dying in droves as the imitators join the fun.

Re:Proof-of-work tokens as an anti-spam measure?

[siriuskase]

A smart spammer would set the nice priority low, then the user would never notice unless he checked his background tasks. I always run Seti@Home http://setiathome.ssl.berkeley.edu/index.html (CLI version, not the famous screensaver) in the background and it doesn't slow me down a bit.

Uhhhhhh...

[sirGullible]

"Hal Finney is inviting folks to test drive his new hashcash-based server rpow.net. "
Sure, if by "test drive" you mean /.

Re:Uhhhhhh...

[Anonymous Coward]

Aha, after so long I have finally GOT IT. Slash - the wave of websurfers decenting on... the Dot - which is the victim site. Er, site of interest. Dot is also the last flash of power on the server screen that the happless host experiences. :)

Trusted computing? I think not.

[42forty-two42]

Based on principles similar to those proposed for so-called "Trusted Computing", RPOW allows third parties to dynamically and remotely verify what program is running on the RPOW server. The RPOW server is implemented on a high-quality secure processor, the IBM 4758 PCI Cryptographic Coprocessor, which has been validated to the highest level of security publicly available, FIPS-140 level 4. The 4758 is a self-contained single-board computer which has its own device key, generated on-board, which never leaves the card. That key can issue cryptographically signed attestations which describe the software configuration running on the card, including the SHA-1 hash of the application program.

How do we know it's actually signing the running image? For all we know it's just an ordinary computer programmed to claim it's a 4758.

Re:Trusted computing? I think not.

[Anonymous Coward]

Well, yes... I suppose that you could always fly over and visit Hal to convince yourself. Alternatively, I guess you could form/find a web of trust amongst people who have done so.

I really don't see how this isn't trusted computing - I only see that you are paranoid and lazy. (It's a dangerous combo.)

Re:Trusted computing? I think not.

[SpootFinallyRegister]

Easy.

IBM releases the public key that corresponds to a private key stored on the card, the so called device key. The usual encode message with pub key, give to device, get decoded message back. Nothing will be able to perform this validation without the private key.

The only snag in this is if the hardware can be fooled with to extract the key, and though I really dont know anything about hacking hardare, I can't imagine that a high level security validation is given to a piece of hardware that easily gives up its secure information.

In other words, your xbox is not validated to FIPS-140 l4.

Too bad...

[HawkingMattress]

I thought it was about providing my boss reusable proofs that i'm working while I'm in fact reading slashdot ;) That would be waaaaay more usefull than this stupid error 500 thing...

Genaric

[Morphix84]

One of the reasons it's very ambiguous, is that it has multiple applications. The major ones are authentication of things like emails, where you would have to calculate the token for each user, or in the distant future, a form of digital currency that would actually reside on a hard drive as opposed to a server on a bank somewhere.

Site down? Don't think so...

[Anonymous Coward]

I'm not having any trouble connecting, but I still can't figure out WTF a POW is. The site only explains how it is turned into an RPOW.

dude, that's so excellent...who's hungry?

[eufreka]

Until now, I always thought that "hashcash" was only related to Repeated Puffs of Weed (RPOWs).

And although the process of exchanging "toke'ns" was highly "cryptographic", ultimately not a lot of work got done...

Anyway, I got confused there for a minute, but I am better now. This might help others:

From http://www.hashcash.org/

Hashcash is a denial-of-service counter measure tool. Its main current use is to help hashcash users avoid losing email due to content based and blacklist based anti-spam systems. A hashcash stamp constitutes a proof-of-work which takes a parameterizable amount of work to compute for the sender. The recipient can verify received hashcash stamps efficiently.

Rock on!

Zombie farms

[Bronster]

What a crock of a system. Let's see:

a) to be useful for anything involving third parties where you don't already have a trust relationship, this would need to be common/easy enough to get that other people already have software to support these things. That's not going to happen any time soon - it's a big enough change you may as well come up with an already secure email infrastructure [insert boilerplate "why your solution to spam is stupid" here].

b) 8 tokens per second? Puhleaze. I get that many emails through just one small server with 5 domains on it.

c) as the subject says. Zombies. In a world where thousands of low TC0 machines are sitting around running malware, it's piss-easy for the blackhat spammers to collect their 8 tokens/second by running POWer@home on their zombie farm.

BZZZZt. Strike three and you're out. Nice idea, but not practical.

Re:Zombie farms

[mzwaterski]

As a general user I would only accept emails that have "paid" there time using a system such as this. It would be a quick and easy way for the system to become univerally used as people would migrate to using the system if they wanted their emails read.

Re:Zombie farms

[stratjakt]

So you want industry controlled crypto hardware in your machine that you have no conrol over? That is TCPA/Palladium?

Because thats exactly what that IBM board in the box is.

Guess that's how you sell Palladium to the slashdot crowd. Tell them it will "stop spam" by having your computer to a whole lot of calculatin'.

This doesn't even solve the real spam problem, all that wasted bandwidth. This is just another method of filtering, one that wastes a lot of electricity computing the hell out of things that dont need to be computed. The spam still clogs up my pipe.

Re:Zombie farms

[mzwaterski]

I agree that wasting computing power doesn't seem to be the most logical thing to do, but the cost to send email is too low. The amount of junk snail mail that one gets is limited by the cost of paper and postage. I fully believe that the cost to send email needs to be increased. In that regard, I'd prefer a system that wastes my CPU time to send an email to a system that requires me to pay a postage to send an email. Part of that reasoning is that I don't believe anyone should be able to profit from my sending of an email, I prefer the monthly fee to access the internet. Those who use the internet less might disagree with me, but for now that is my opinion.

Re:Zombie farms

[nkh]

I know you're joking with POWer@home but does anyone know if BOINC has already been used by spammers or crackers to write tools?

Re:Zombie farms

[night tilda]

So you want industry controlled crypto hardware in your machine that you have no conrol over? That is TCPA/Palladium?
Because thats exactly what that IBM board in the box is. Guess that's how you sell Palladium to the slashdot crowd. Tell them it will "stop spam" by having your computer to a whole lot of calculatin'.

My impression for this scheme is that the IBM 4758 goes in a server somewhere, quite different from TCG etc. Usually the point is that it looks out for your interests on the server. At $2000-3000 a piece back when they were still being produced, they probably won't find their way into too many PCs.

Calibration issues

[markh1967]

I'm not sure how well this technique would work in the real world when you have a huge range of systems trying to connect to you. If you set the number of bits in the token so a fast Pentium 4 based system will take two seconds to compute it how many hours would it take a 386, palm-pilot, or Internet enabled phone? Conversely, if you set the number of bits low so that slow systems can compute them in reasonable time then someone with a much faster computer will not be slowed by any noticeable rate and the system becomes useless. If this system is taken up surely it will do more to discriminate against people without state-of-the-art hardware. Surfing is annoying enough on a very slow machine without having to wait for 30 minutes to compute the RPOW before the site will let you connct.

Re:Calibration issues

[Alsee]

That's exactlty what the reusable proof of work tokens are supposed to solve. Who cares if it takes you an hour make a token if is was generated three months ago while your (or someone else's) computer was pretty much idle while you sat there reading something on the screen? You can generate them in advance once, then pass them around. If it's used for email then every time you receive such an email you'd receive a token you can use on the next email you send.

-

Re:Calibration issues

[Anonymous Coward]

As for a phone, you could have a utility to transfer tokens from your computer to your phone, thereby giving you tokens to use freely.

SHA-1

[Anonymous Coward]

It uses SHA-1, which has just been broken for 36 out of 80 cycles by a new technique, which is drawing into question how long it will be cryptographically viable.

What i dont understand about hashcash?

[VC]

Why have the server send a challenge to sign at all? Surely the MUA (mail client) could just add an x-header-expensive-hash-of-this-mail

to *every* mail that goes out, which would be wildly different for each mail beacuse the email address would change.

Same concept, but would work with current mail clients/servers and could tell the server/mail client at the other end that the server really wants you to get this..

Anyone know why this wouldn't work?

Re:What i dont understand about hashcash?

[Some guy named Chris]

Because it would be computationally expensive to check the validity of the hash on the receiving end.

It's a one way proof of work, not bi-directional make-work. What do you think this is, a government job? :D

Re:What i dont understand about hashcash?

[zaphod.nu]

Because then the email server has to compute the hash as well to verify it, which means that server would quickly get swamped.
The point of this is to force the client to compute an expensive hash, not a problem for sending an email to mom, but a much larger problem for people sending out 10000 viagra mails.

Re:What i dont understand about hashcash?

[BCoates]

There's an issue with including the hash of the document in the hash itself, but if you fix that it's only hard on the sending end. There's no need to use the entire message as the challenge, just concatenate today's date to the destination address:

target: "18102004-foo@bar.com"
sha1(target string): "a766a602b65cffe773bcf25826b322b3d01b1a97"
(clien t works trying to break the hash)
solution: "2684ef53"
sha1(solution): "a766a60e3e3b4b7f53fe376224c08e47e959b2bc"

so the client has a 28-bit hash collision (a fair amount of work on a modern machine iirc), and puts target and solution in the header. All the recipient has to do is confirm that target is legitimate (actually the recpient's address, date within a reasonable range of reciept time), that hash(target) and hash(solution) collide on a reasonable number of bits, and that it hasn't seen solution used recently.

The only thing you lose from not having a server-challenge is that there's nothing to prevent the sender from spending a long time precomputing solutions that will work on a single address on a single day--patient DoSers can still make trouble, but I don't think it helps spammers.

oh I thought this was for creditors!

[Anonymous Coward]

Like he would print me out a fake check stub that I can use to get a low interest rate loan or something...heh.

"official" mirror, one application

[Anonymous Coward]

An official cryptome mirror carries the story cryptome doesn`t have ads to pay the bandwith bill. Few want their ads there apparantly and it would mess with the "cryptome keeps no logs" policy. Dont take this policy to seriously though, Neil young mentioned the increase in NYPD and fbi visits in the run up to the republican convention and how hard it is to find a host that allows for wiping of logs.

please be gentle with this valuable site...

The first proof of work application I learned about was in anonymous remailers. To avoid spammers using sending their messages though remailers some remailers require a proof of work token. So to send an e-mail you have to run a program that slurps some CPU power. It then genarates a token you include in your mail. The remailer can quickly verify you spend some CPU power (thus time) on your message and relay the mail. That way spamming would require insane amounts of CPU (or time).

Keeping honest folks honest

[vile8]

Great, I was just complaining the other day that my computer is a lazy, good for nothing document editor. Here I sit with 3ghz and a gig of ram and nothing to actually process other than ps streams.

Since its based on working your computers resources perhaps other names could possibly be "RPOW by Jake"? Or "RPOW's of steel"?

Seriously, what happens next year when its not computationally expensive to compute the tokens? Ew, or what if you are a clever spammer with a degree in electrical engineering and the time to make your own token generating card to sell to all the other spammers on ebay for a small fortune (or you could prove it works by spamming them with advertisements...)?

Well, its always good to have another device to keep honest folks honest I guess.

Simple summary and questions

[CommieLib]

Apparently, RPOWs are a way of throttling down incoming requests by forcing them to solve a time-consuming puzzle. You would want to do this to mitigate DOS attacks.

Here's the question for those who know more, i.e., anyone who knows anything about this. Won't this necessarily and dramatically increase request time? It should impose no (significant) additional load on the server, but won't this mean that requests take x*response time to begin?

Re:Simple summary and questions

[julesh]

Yes. In fact, that's the entire idea. Increased response times -> reduced throughput. But as most people don't actually sit & wait for their e-mail to go out, it is acceptable for use in this kind of situation. You wouldn't be able to use it, though, on a web server...

Re:Simple summary and questions

[CommieLib]

Ah...that makes a lot more sense. I WAS thinking in terms of a web server. Cool.

equivalent for RPOWs in existence

[2nd Post!]

Money. Difficult to make, easy to verify.
Goods. Like a car.
Trust. Extremely difficult to make, easy to verify.

Russian Black Market

[Sv-Manowar]

so when will a black market pop up for cracked ones ;)

Re:Russian Black Market

[Wesley Felter]

RPOWs are worth so little that it's a waste of time to "crack" them. It's like making counterfeit pennies.

Article Troll!

[Anonymous Coward]

using a private crapto key

craptographic hash or fingerprint

and will protect their privacy, even without cryptographic blinding

What exactly is craptology there buddy.

Let's make it do something useful

[kanweg]

Now, if this concept of having the sender do something is changed into having the sender do useful (Folding at home or another distributed computing project), it would be a nice twist.

Bert

Re:Let's make it do something useful

[Anonymous Coward]

Ok, Lets think about this...

How about a "signed" dataset with provable verification servers located at the distributed computation project sites. Only to be fair to the distributed project the tokens should *not* be reusable, or at least provide a lesser degree of "postage" with each reuse (e.g. $.50,$.20,$.10,$.05,..).

Then the problem would be that the spammers would just invest in HUGE computer farms and ultimately find a cure for "medical cancer" (that doesn't soud too bad so far..), but then we'd still be left with the scourage of "spam cancer"!

On the bright side, think of all the "postage" you'd collect for free via spam! You would never have to lick another foul tasting e-stamp again. ;-)~ [$]

Spammers don't send their spam

[Albanach]

Spammers don't send spam, unpatched windows boxes do. Loads of folk here must be getting calls form folk saying "my net connection's slow" you take a look and the machine is infested.

All this means is that, as well as the net connection being slow, the processor will be running overtime calculating the checksums. The spammers will send as many emails as ever.

SPF has to be one of the easiest measures we can take to reduce spam. Spamassassin is about to hit 3.0 RC1 and many more of us will be able to easily associate scores with SPF records. As soon as mail has to originate from the correct domain we get better spam checking and a paper trail for the authorities to follow. If you don't have SPF records for your domain, head on over here or here and set them up.

Re:Spammers don't send their spam

[kindbud]

SPF has to be one of the easiest measures we can take to reduce spam.

Yeah, except that it was never intended for that purpose, and doesn't have any features to do anything to prevent spam. But other than those two minor points, it's perfect.

Re:Spammers don't send their spam

[Alsee]

All this means is that, as well as the net connection being slow, the processor will be running overtime calculating the checksums. The spammers will send as many emails as ever.

Wrong. The processor will certainlty be bogged down generating tokens, but the net connection will be wide open if it can only generate one token and send one spam every 4 or 5 minutes.

And no, even 10 minutes wouldn't be a problem for normal email users. The very first time you launch your mail program it can start generating a token, even before you've configured the mail host and you entered your name. It can work on tokens while you download your mail, while you sit there reading your mail, and while you address and type any mail you want to send.

And the tokens are reusable. If someone sends you mail through this system then they are giving you a token you can use yourself on the next mail you send out. Hell, so long as there are spammers generating tokens and mailing them out normal people will never need to generate their own tokens. Just save the tokens you get on spam and use them to send your own mail, So even 1-hour to generate a mail token wouldn't be any sort of problem.

-

Re:Spammers don't send their spam

[ajs]

Let's follow this logic for a mailing list... let's call it LKML, just to pick a random name.

Now, I send mail to LKML. The protocol can work one of two ways: 1) use my token in the 50,000 messages taht are sent out 2) generate its own token for all 50,000 messages 3) generate a unique token for each of 50,000 messages.

Plan 1 is abusable thusly: a) spammer has "token machine" which generates the spam b) spammer has "mailing list" machine which disperses the mail to thousands of hapless end-users.

Plan 2 is abusable thusly: a) spammer generates one token and sends 50,000 messages (all the same) based on it.

Plan 3 imposes a burden on mailing lists that is unworkable. LKML (whatever that might stand for in my hypothetical) may not be able to afford enough hardware to send out so much mail, so they go away, and only large, commercial mailing lists and very small, and thus ineffective in the large, mailing lists remain in operation.

The problem is that bulk email has many forms, some good and some bad. The solution is multi-layered, fuzzy spam filtering. As someone pointed out SA 3.0 will meet part of that criteria (actually, it already does at 2.63, but there are some killer features in 3.0), but other tools, layered with SA are still needed.

Spamhaus has done a huge service in the creation of a non-premtive blacklist (sbl-xbl) that combines known spam sources with known exploited systems. By non-premtive, I mean that it finally gives sites like mine (hosted on a "residential network") a list that does not exclude ourselves, AND is highly effective. Any blacklist I use must have one central feature: it must have a way for mail servers, without changing their IP or what servers they deliver through, to get OFF of the list (unless they've provably been so abusive that they no longer merit such an opportunity).

Currently my filtering looks like this:

Step 1: SBL-XBL check (5xx error code from SMTP if that matches, and that cuts out HUGE amounts of bandwidth wastage).

Step 2: SPF check (also 5xx error code from SMTP if that fails)

Step 3: SpamAssassin check (mail is receieved fully and then scored and filtered or marked appropriately). I have SA assign a small positive ("more spammy") score for mail that has no SPF authorization, and that's about as close as I get to premptive spam filtering.

I still get spam sneaking through, but I went from my users ("user", really) complaining that they could never read mail through all the spam to, "is mail working, I haven't gotten anything today."

Re:Spammers don't send their spam

[professorfalcon]

SPF has to be one of the easiest measures we can take to reduce spam.

If a source domain does not have SPF entries, then SPF does not help the site who is checking the incoming email. Thus, SPF doesn't reduce spam unless the vast majority uses it. That's unlikely to happen anytime soon.

The power of SPF, today, is in increasing the chances that your mail gets delivered. If you have SPF entries, your mail gets delivered to anyone who uses SPF checking, and anybody who tries to pretend to be you gets rejected. People trust your domain more.

SPF is powerful for the sender. POW/RPOW is powerful for the receiver.

Re:Spammers don't send their spam

[Alsee]

mailing list

Any non-moderated list like that is going to be tough to secure.

The protocol can work one of two ways: 1) 2) 3)

Two ways, 123? Chuckle.

Actually 4) anyone who signs up for a mailing list should be white-filtering it. No need for 50,000 tokens. And when someone signs up for such a list you request a really expensive token. Maybe someone even needs to leave their computer running overnight to sign up.

Someone can still attack the list with a number of machines, but you always has that risk. At least this makes it a little tougher on them to do so. And you can continue to use whatever other methods are available.

-

cure for spam?

[cyclobotomy]

would spam be feasible on an email-like system that uses RPOW tokens? Making the spammer give up computation time for each email sent seems like the perfect solution.

Re:cure for spam?

[BarryNorton]

Everybody look - I've just invented the wheel!

I have a better idea

[drinkypoo]

Instead, require that someone complete a seti@home, folding@home, distributed encryption cracking, or similar work unit before they can send you an email. That way at least the CPU power is going somewhere worthy instead of just being a waste of electricity.

Re:I have a better idea

[outsideobserver]

The only catch is that the machine distributing these little CPU-eating nuggests has to check for result validity. Otherwise spammers could just generate fake results and produce worthless data. That would make it less practical except for certain calculation types. On the other hand, imagine the market value of all that farmed out processing power. I can see getting paid for each email you receive, or receiving better free email service sponsored by the processing power gained by email company.

But if they are reusable, ...

[James Turpin]

... can't the spammer just keep copies of old RPOW tokens and reuse them himself later? How is this prevented?

Re:But if they are reusable, ...

[Anonymous Coward]

RTFP -- any transfer of tokens, or generation of new tokens from old ones (re-use), must happen through the central server.

mailing lists

[Anonymous Coward]

If this was implemented how would it affect mailing lists? I personally subscribe to a couple, one of which generates 100-200+ emails a day sometimes.

/. back at you

[btwIANAL]

So you are saying that even though we may /. this site, it has the potential to /. back? Think about it!

Out of Curiousity ...

[rrhal]

... how much does a IBM 4758 cost?

IE is this something that small orginizations can do or do you have to be able to print your own money?

Re:Out of Curiousity ...

[night tilda]

> ... how much does a IBM 4758 cost?

In the region of $2000-3000 when they were still being produced. I've seen them for sale for $800 or so more recently. So not that much for any kind of org.

Uh oh...

[fastgood]

If a spammer 1 time gave a real email address to thousands of marketing sites,
and published that same address in order to get UCE from other spammers...
couldn't the spammer build up 1000s of tokens with no computational effort?

Why punish the victim?

[Yenin]

The computer is just an innocent tool being used by the spammer. It would be more fair to make the user do the computations. This would also solve the problem caused by computers of different speeds.

Re:Why punish the victim?

[Crzysdrs]

I suggest we make them calculus equations, then we can keep all the idiots off the internet. Sounds like a plan to me, although, some people might miss AOL.

Reusable Proof of (Busy) Work

[dpilot]

That's one thing about RPOW and hashcash that strikes me just a little off. All of this 'work' that we're paying with is just useless busy-work. It's worthless calculation, they're just measuring our willingness to waste our computer's time in order to send them an email.

How about if:

They team up with SETI@home, folding@home, and the like. When you turn in a work unit, they have a secure arrangement with some sort of postage stamp server, and you get sent the stamp. This only makes sense with a central stamp server, because I'm trying to make the stamps 'cheap' to make, and use the compute effort for something useful.

My suggestion is flawed, probably fatally, especially compared to basic server-less hashcash. I'm just motivated by a wish for that compute time to do something useful.

Re:Reusable Proof of (Busy) Work

[outsideobserver]

The only catch is that the machine distributing these little CPU-eating nuggests has to check for result validity. Otherwise spammers could just generate fake results and produce worthless data. That would make it less practical except for certain calculation types (cracking cryptography, finding large prime numbers, calculating places of pi). On the other hand, imagine the market value of all that farmed out processing power. I can see getting paid for each email you receive, or receiving better free email service sponsored by the processing power gained by email company.

Re:Reusable Proof of (Busy) Work

[dpilot]

I know and understand, though I didn't mention sending fake work back to SETI, etc. As I said, my idea is probably impractical.

I'd rather contribute to solving global warming by participating in distributed weather modeling than contribute to global warming by burning electrons calculating hashcash postage. Maybe if we could just eradicate spam, then the expense of hashcash would be more than offset by saving energy now spent on wasted bandwidth.

Spoof the proof?

[Julia Cameron]

Right. And just how long do we think it will take before some hacker spoofs the proof?

Just wondering.

Advantage of RPOW over POW?

[Heewa]

So, as I understand it, a POW is a computationally expensive thing to create, but quick to verify. One application of this is in email. Lets say someone wanted to send me a message, I'll send them some data, and they'll create a POW right then based on that data (so they can't have a bunch of POWs stored up that they keep reusing). When I get it, I quickly verify that it's real and based on the data I gave. If it is, the email gets accepted.

This helps with spam because a spammer needs to send out a lot of mail very quickly. Even a POW that takes 2 seconds to create, which isn't so bad if you're sending a lone email, would slow down a spammer to a trickle.

Alright. Now, an RPOW is one that's reusable sequentially, or once at a time. They say it'll help with the spam thing because while it won't help spammers, it'll make it easier for regular email users. I don't get this.

In the previous example, someone would want to send me an email, I'd ask for an RPOW, they'd spend some time and produce one, I'd get the email, but now, if I wanted to reply, I could just use that RPOW, and then he could use it again, but not to send multiple copies to a whole bunch of people.

So, once a chain gets started, it's easy to keep up, but starting multiple chains is tough? Why does this matter? Is it really a big deal to wait 2 seconds, or even 10 to send an email if you're sending even 1 every 10 minutes?

Do I have this right? Maybe I'm missunderstand, or missapplying this.

Reusable Tokens

[cbr2702]

If I recieve a token from someone else, can I copy it and attach it to multiple messages? If so, what's to stop spammers from calculating one token and attaching it to a large number of messages?

Re:Reusable Tokens

[BizidyDizidy]

umm, no you can't. this should be pretty obvious.

Re:Reusable Tokens

[FLEB]

You've got it backwards. The recipient gives the challenge to the sender, then the sender (spammer) has to solve the problem. It's a unique problem every time.

Like this:

First, the recipient either takes some time to generate new tokens (problem+solution sets), or simply reuses tokens it has recieved and solved.

The sender sends them an email, and the recipient replies with the "problem" part of the token. The sender chugs away for a while trying to solve the problem. Once they solve it, they have a problem and solution, a complete pair which they can cache and use as their own challenge to people sending them mail, without having to recalculate it every time.

Re:Reusable Tokens

[cbr2702]

I can't attach it to multiple messages? Whyever not? Imagine I get a token in a message from someone, I attach it to a new message, and send it on to someone else. That is the way reusable tokens are supposed to work, right? But let's say instead that I attach that reusable token to two outgoing messages. Without some central DB of token usage, the recipients can only determine that the tokens I have provided are valid, not that they have not been used for other messages. So this does not prevent spam.

Re:Reusable Tokens

[cbr2702]

But the inconsistency with the way you've discribed the system is that it is supposed to be computationally cheap to verify a problem/solution pair. So there would be no benifit to holding onto pairs to use as challenges in the future because it would be both more secure and eficient to generate a new problem every time (to which the anwser is not known, but a solution can be easily verified).

Re:Reusable Tokens

[BizidyDizidy]

Insightful? This is painful to read, and factually wrong. There's a central DB. That's the whole freaking point.

What's really galling is that you were sitting at your computer thinking you had foiled this system that a bunch of very smart people invested a ton of time and money in; I bet you call into talk radio too.

Re:Reusable Tokens

[cbr2702]

I'm sorry I didn't RTFA (excuse, excuse: their server was overloaded) but now I have and I see that you're right. Point 10 addresses my question exactly.

As an aside, it's not that I was "sitting at [my] computer thinking [I] had foiled this system that a bunch of very smart people invested a ton of time and money in" but that I was confused (obviously) about the way the system worked, and wanted clarification.

What about server problems/attacks

[PetiePooo]

From the article:
The RPOW server is running on a high-security processor card, the IBM 4758 Secure Cryptographic Coprocessor, validated to FIPS-140 level 4. ... Please keep in mind that if there are problems I may need to reload the server code, which will invalidate any RPOW tokens which people have previously created.

So, in other words, it passes out little tokens that are worth something ... but just until the server is taken out.

Ok, so its running FIPS-certified code on FIPS-certified hardware. Still, how sure can you be that it will keep running 24/365 for years on end? If that private key is needed for proof of authenticity, and that key never leaves the board, that makes it, among other things, one heckuva terrorist target.

Re:What about server problems/attacks

[Paul Crowley]

The tokens it hands out aren't *that* valuable, so if the machine goes down you don't lose all that much.

Call me paranoid, but this disturbs me...

[Zancarius]

From the article:

The RPOW system is just the first of what are planned as a series of systems which use this approach, which I call Transparent Servers. Such systems publish their source code for review and inspection, and use Trusted Computing-like features to prove that they are running the program generated by that code. This will provide an unprecedented level of transparency and visibility into the workings of network servers.

My reasoning is this: Assume an exploit is discovered in the "Trusted Computing-like features," whereby anyone could query the version of the software that system is running. Next, assume an exploit is discovered in the source (the same source version the system happens to be running a compiled version of). It would be heaven for the computing misfits! No longer would there be the need to run countless probes looking for exploitable software--just ask the software what version it is.

Even security through obscurity is better than this and that says a lot.

Are these things cheap?

[KontinMonet]

What's stopping spammers setting up a whole bunch of their own RPOW servers? They use these and zombied machines get their tokens from RPOW servers in Vanuatu or wherever. What's been solved?

Re:Are these things cheap?

[Wesley Felter]

RPOW servers are so slow and expensive that any spammer who buys one will go out of business.

Re:Cache?

[sapped]

Google Cache after slashdotting... http://www.google.ca/search?q=cache:YHGDB5MH4e0J:r pow.net/+&hl=en

Shouldn't that be Google Cache after POWing?. Hey, couldn't resist after seing the acronym POW (Piece of Work) on the website once too often.

Come to think of it, this could turn into a new saying. "You're a real POW aren't you?"

This could work..

[drphuck]

It would be nice if there was a limit to the amount of emails someone could send every minute. Hopefully this would greatly reduce mass spamming. Most people take longer then 1 minute to write an e-mail, and they probably don't write emails once every minute either, so legitimate users shouldn't be affected. I don't think 2 seconds is long enough for a "complex" calculation of the "hashcash token". They should find a way to make it take atleast 1 minute.. No real user sends mail every 2 seconds.

Re: how it works, and a problem?

[tomjennings]

I believe it's like this: a system of "tokens" that are computationally hard to create, so if your machine can re-use a token it's received from someone else, it saves a lot of time.

The server system restricts "reuse" of tokens in a way that prevents simple copy/duplication. That's all the underlying crypto stuff. An analogy is, you receive token "N" from some email, and save it for later. TO send email, you need a token -- grab one saved from before. Crypto code at a central server (ERRT!) performs (verifyable) magic to make that used token "N" into new, unused token "N+1".

You *can* print credible paper money, but it's really hard. Most people find better ways. That's the idea behind it.

ERRT: but doesn't this mean that the "issuing" server needs to be involved in every re-use transaction, foiling one of the beauties of SMTP mail: utter decentralization?

But this doesn't stop spam, unless...

[Farq Fenderson]

As I see it, what's to stop you from taking a POW, cashing it in for an RPOW, then repeating the process over and over for a bit... over the length of your entire spam-to list, then using them?

Sure, they're in the "seen" database, but the point of the (R)POW is to be intrinsically verifiable, without having to consult a database.

Unless the server is going to take its time in getting you a replacement RPOW, I don't see how this is actually useful vs. spam. I mean, if it's relatively quick to issue a new RPOW, then wouldn't the time involved in accumulating the spam list be greater overall?

Finally, how many bits should an authorized email cost?

It's useless idiocy

[World_Leader]

"trivially solved by whitelists?" What utter nonsense. Hashcash/RPOW is snake-oil. Why not just put a 2 second sleep in your server SMTP loop? Doh! It's really that stupid. There are many other objections. Don't waste your time.

Re:It's useless idiocy

[Farq Fenderson]

Um. A 2 second sleep would put you out of business, and have zero effect on spam. Spammers tend to use their own servers, or zombies to send spam. I catch spammers spammers regularly, and they're always running their own mailer software, which establishes its own connections with recipient servers. That's not exactly the kind of thing you can throttle.

If you're an ISP and 98% of the incoming mail is delayed for 4 hours, and 98% of that is being delayed for another 4 hours and so on, then most of your mail will get dropped after 5 days. I'm not going to bother showing the math; the point is you'll lose most of your customers and won't be in business long enough because the only email people will be getting, for the most part, will be their spam.

Re:It's useless idiocy

[World_Leader]

It's the "Star Trek" or "War Games" approach to spam: We're gonna ask the spammers' computer a question which is so difficult that steam comes out its ears and it dies!

What exactly is the difference is between, e.g., a two-second sleep and demanding a two-second computation via hashcash escapes me (and you also apparently.)

The point is spammers right now control on the order of one to ten million zombies PCs.

They can throw as many PCs at those hashcash problems as they like, more or less.

And, besides, no one (over the age of 17) is going to go along with a scheme that says compute this hairy formula for a few seconds and then I'll take your mail. No one.

It's like challenge/response, it just comes down to who has the leverage.

But go ahead, get those prospective employers who found you on that job board (how ya gonna whitelist them?) to just tie up their machines with these computations so you can get an interview with them etc.

Re:It's useless idiocy

[Anonymous Coward]

The differences with a 2 second delay are: 1) in hashcash it's not the recipient but the speed of the sending CPU that determines the delay, 2) a spammer can defeat any delay by pipelining the sending process -- if an unpipelined spam zombie server sends 10 messages per second one after another, a pipelined version would run 20 parallel sender threads and thus the spammer reaches the exact same throughput.

The conclusion is that hashcash can be used to throttle spammer throughput but a delay cannot.

Did I hear P2P?

[Anonymous Coward]

serve as the foundation for a sort of payment system

Please receive this piece of "bit gold" for the last chunk you shared with me.
Feel free to use it to "buy" some other chunks you might be interested in...

Just two words:

[Anonymous Coward]

Mailing List

Traffic != Capacity, and computing speed increases

[Anonymous Coward]

If you slow down the rate that it's possible to send spam by 1000, then you get a thousandfold decrease in spam.

This assumes that spammers send the absolute maximum capacity they're capable of, and that they're incapable of adapting, by owning more machines, or pushing those machines harder.

Besides, designing an anti-spam system around the time taken to compute stuff is daft. Computer hardware will be more than twice as fast before it's even implemented widely. It's like those old DOS games that run too fast on a modern machine: nothing more than poor design.

Processing is Relative

[korthof]

The problem is processors and memory is clustering and becoming faster, so the relevance of a POW is relative. 2 seconds on a P4 3.0 with hyperthreading is like 30 seconds on a p4 1.7.

And clustered linux or multiprocessor servers with tons of 600Mhz DDR will 2 seconds be 2 seconds?

Probably not, it will probably be a 1/4 of a second, so we start coding more complex algorithms, and we outdate our old server software instantly because it now takes our Win2k or Cobalt mail or print server a half hour to send 1 email.

Hello.. is thing on? Not a bright idea.

GPF from algorythmic function here I come.

"Mommy my email wont send. Oh your algorithm is failing Timmy.. but dont worry.. you can try again tommorow."

Economic forced boost? Or system wide nightmare?

It's not me; it's my ISP.

[Farq Fenderson]

This could be enforced by the ISP. In fact, it could be standardized throughout, built into SMTPvX or whatever. IF there is an RFC on it, for example, and people start making servers for it, clients will be written, eventally SMTP as we know it could be phased out entirely. Of course, this means that it couldn't be fixed over night.

A two second sleep would kill an ISP. It would do a lot of harm to a spammer, but it would have virtually no effect on legitimate clients. As such, it's best to enforce it on the client end so that it harms only people sending large volumes of mail. Spammers get virtually nothing per message which means they have to have massive lists to make it worth the effort.

If spammers can compute fast enough to make a given level ineffective, then up the requirement by 4 or 5 digits, making the processing take 16-32 times as long.

How to slow down spammers deluging your systems...

[iamcf13]

Re:Umm (Score:4, Informative)
by Anonymous Coward on Wednesday August 18, @11:16AM (#10001854)
Spammers send millions of email a second, imagine if for every email they had to do some sums that took 2 seconds, before the server would accept the email...suddenly the rate of emails per second falls.....

Without changing/breaking the SMTP email standard, my mailserver program scores incoming messages for 'spamminess' and delays processing of the message appropriately. If the spammer disconnects before the delay expires, their message(s) are *NOT* processed!

This applies to all messages process by my mailserver. All 'non-spammy' messages will have little or no delay and will be process immediately.

The 'delay factor' is user settable and the default suggested value will result in an approximately one minute delay for an incomming email message with 'maximum spammage' (any longer and Outlook will 'complain').

Bryan Taylor
iamcf13@hotpop.com
SpamByte code: 7
(see http://www.cf13.com/game-over-spammers.htm )
http://www.cf13.com/press-release.htm
All email containing unwanted content will be summarily deleted or reported as spam.