RPOW - Reusable Proofs of Work
--- begin forwarded text
To: cypherpunks at al-qaeda.net
Subject: RPOW - Reusable Proofs of Work
Date: Sun, 15 Aug 2004 10:43:09 -0700 (PDT)
From: hal at finney.org ("Hal Finney")
Sender: owner-cypherpunks at al-qaeda.net
I’d like to invite members of this list to try out my new hashcash-based server, rpow.net.
This system receives hashcash as a Proof of Work (POW) token, and in exchange creates RSA-signed tokens which I call Reusable Proof of Work (RPOW) tokens. RPOWs can then be transferred from person to person and exchanged for new RPOWs at each step. Each RPOW or POW token can only be used once but since it gives birth to a new one, it is as though the same token can be handed from person to person.
Because RPOWs are only created from equal-value POWs or RPOWs, they are as rare and “valuable” as the hashcash that was used to create them. But they are reusable, unlike hashcash.
The new concept in the server is the security model. The RPOW server is running on a high-security processor card, the IBM 4758 Secure Cryptographic Coprocessor, validated to FIPS-140 level 4. This card has the capability to deliver a signed attestation of the software configuration on the board, which any (sufficiently motivated) user can verify against the published source code of the system. This lets everyone see that the system has no back doors and will only create RPOW tokens when supplied with POW/RPOW tokens of equal value.
This is what creates trust in RPOWs as actually embodying their claimed values, the knowledge that they were in fact created based on an equal value POW (hashcash) token.
I have a lot more information about the system at rpow.net, along with downloadable source code. There is also a crude web interface which lets you exchange POWs for RPOWs without downloading the client.
This system is in early beta right now so I’d appreciate any feedback if anyone has a chance to try it out. 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 don’t go too crazy hoarding up RPOWs quite yet.
Thanks very much -
Hal Finney
--- end forwarded text
--
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The new concept in the server is the security model. The RPOW server is running on a high-security processor card, the IBM 4758 Secure Cryptographic Coprocessor, validated to FIPS-140 level 4. This card has the capability to deliver a signed attestation of the software configuration on the board, which any (sufficiently motivated) user can verify against the published source code of the system. This lets everyone see that the system has no back doors and will only create RPOW tokens when supplied with POW/RPOW tokens of equal value.
Just a quick sanity check for me… what stops you simply faking this “attestation” and running a compromised system?
--
Taral <taral at taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Some people cause happiness wherever they go; others, whenever they go."
-- Oscar Wilde A couple of quick responses to the questions on RPOW, as I am at Crypto this week.
Taral asked about the attestation. It is based on a root key
published in Appendix C of IBM’s “IBM 4758 PCI Cryptographic
Coprocessor Custom Software Interface Reference”, available from
http://www.ibm.com/security/cryptocards/html/library.shtml.
It is also published on IBM’s web page at
http://www.ibm.com/security/cryptocards/html/faqcopvalidity.shtml
This tells you that the attestation refers to a valid IBM 4758.
Further, the attestation contains within it both a hash of the RPOW program, and a set of keys generated by that program. Using the methods described on the rpow.net web site, it is possible to take the RPOW source code and generate a hash which matches that reported in the attestation. This tells you that you have access to the actual source code running on the RPOW server. By studying the source you can confirm that the program never exposes its private keys or allows them to leave the board. This tells you that if you send a message encrypted to the RPOW communications key and get a meaningful response (messages are protected with HMAC), you are talking to the program described in the attestation.
Lynn Wheeler mentions the IBM 4758 break by Mike Bond and Richard Clayton
described at http://www.cl.cam.ac.uk/~rnc1/descrack/. This was not
actually a break of the 4758 but an exploit of a cryptographic weakness
in the application running on the board, which was IBM’s CCA support
software. RPOW does not use CCA and is not vulnerable to that attack,
and IBM has since fixed the CCA.
Of course it is possible that RPOW may have vulnerabilities and errors of its own, being my own work and far from perfect. I welcome review and comment on the RPOW source code which is open source and available from rpow.net.
Hal Finney
A couple of quick responses to the questions on RPOW, as I am at Crypto this week.
I’m wondering how applicable RPOW is. Generally speaking, all the practical applications I can think of for a proof-of-work are defeated if proofs-of-work are storable, transferable, or reusable. Once they’re storable, tranferable, and reusable, aren’t we restricted to applications already nailed down by digital cash schemes?
So, even if it works flawlessly, this seems like an exercise of cleverness that makes a cryptographic entity less generally useful than the primitive from which it’s derived. It probably has a few specialized applications that normal POWs won’t serve; I just haven’t been able to distinguish them from the applications served by digital cash.
Why doesn’t this scheme give rise to a “POW server” that just sits there, generating proofs-of-work in advance of need and dispensing them at request? Or even to a company that sells POW’s to people who can’t be bothered to run their own server? And doesn’t such a device or service defeat the use of POWs for real-time load balancing, traffic control, etc?
Bear
I’m wondering how applicable RPOW is. Generally speaking, all the practical applications I can think of for a proof-of-work are defeated if proofs-of-work are storable, transferable, or reusable. Once they’re storable, tranferable, and reusable, aren’t we restricted to applications already nailed down by digital cash schemes?
Well, there are no digital cash implementations that I am aware of. I think of RPOWs as a sort of “play money” that might be usable in some applications that would otherwise use digital cash. I have some code to play online games with cryptographic protection, cards and dice, and I am planning to modify it to let people make bets with RPOWs as the betting chips.
Another way to think of RPOWs is as an implementation of Nick Szabo’s concept of “bit gold”. These are made of bits but have the rarity and verifiable costliness of a commodity like gold. Of course they lack gold’s appeal and attractiveness. Perhaps they could be better thought of as “bit copper”.
BbearWhy doesn’t this scheme give rise to a “POW server” that just sits there, generating proofs-of-work in advance of need and dispensing them at request? Or even to a company that sells POW’s to people who can’t be bothered to run their own server? And doesn’t such a device or service defeat the use of POWs for real-time load balancing, traffic control, etc?
It’s possible that these things could happen, but that’s not necessarily bad. After all, if people ever got to where they would buy and sell RPOWs for money, they could serve in place of ecash. The main question is whether there will be any use for them so compelling that people would buy them.
Hal Finney
At 04:34 PM 8/20/04 -0500, Matt Crawford wrote:
I’m wondering how applicable RPOW is.
If you think of POW as a possible SPAM mitigation
As spam mitigation, it might work better than hashcash. As cash, it lacks the anonymity of “bearer-documents (tm)” since there is one clearing house. This might be improved via support for a system of mostly independent clearing houses which also interchange at interchange places. However, those would likely be regulated by the Powers That Be, ergo not alleviating my concerns about anonymity.
My 2 dinars.
It’s like an online ecash system. Each recipient sends the RPOW back to the mint that issued it to ask if it has been double spent before accepting it as valid. If it’s valid (not double spent) the RPOW server sends back a new RPOW for the receiving server to reuse.
Very like Chaum’s online ecash protocol, but with no blinding (for patent reasons) and using hashcash as way to “buy” coins. The other wrinkle is he can prove the mint can not issue coins without exchanging them for hashcash or previous issued coins (up to the limits of the effectiveness of the IBM tamper resistant processor card, and of course up to the limits of your trust in IBM not to sign “hardware code signing keys” that are not generated on board one of these cards). This is the same as the “remote attestation” feature used in “Trustworthy” Computing for opposite effect — restricting what users can do with their computers; Hal is instead using this to have a verifiable server where the user can effectively audit and check what code it is running.
Adam
On Fri, Aug 20, 2004 at 04:34:00PM -0500, Matt Crawford wrote:
I’m wondering how applicable RPOW is. Generally speaking, all the practical applications I can think of for a proof-of-work are defeated if proofs-of-work are storable, transferable, or reusable.
I have some code to play online games with cryptographic protection, cards and dice, and I am planning to modify it to let people make bets with RPOWs as the betting chips.
If you think of POW as a possible SPAM mitigation, how does the first receiving MTA assure the next MTA in line that a message was “paid for?” Certainly the mail relay doesn’t want to do new work, but the second MTA doesn’t know that the first isn’t a spambot.