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. "

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

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?

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: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.

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.

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.

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: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: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: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.

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.

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: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.