Robin Hanson writes:
[This is a first post by a crypto-naive person - be kind.]
What came to my mind as I read Tim's message was various competing timed-key servers, each publishing its public key associated with various future dates, and promising to release the associated private key on that date (but not before).
Yes, a market or ecology of servers, with various competing capabilities and reputations. "Distributed trust" is quite effective. (Someone sent me private e-mail saying he didn't like my scheme because it wasn't as "mathematically solid" as pure encryption schemes. Let me point out that many crypto schemes involve issues of trust, distributed trust, collusion, and even trust. "Pure" schemes do not in general exist, except as very basic operations. As one example, there are no unforgeable "digital coins." And even the information-theoretically secure "dining cryptographers" protocol is unsecure given enough collusion. The role of reputations--common in business and interpersonal dealings--is generally ignored in the academic crypto community, who end up tearing their hair out over extremely complicated protocols that attempt to avoid issues of reputation and economic incentives. Folks like Dean Tribble and Robin Hanson have a lot to contribute to the actual realization of distributed, agoric crypto systems.)
You then encode your message with an m-of-n scheme using n such server's keys for your chosen date, and assume at least m of them will eventually publish their promised key, and assume no more than m of them will release early. You then leave it with several escrow services and ask them to try to decrypt it once a year with the new year's keys.
To prove to all that a server is untrustworthy, simply reveal its private key ahead of time, and win a bond posted by the service (easy to implement - encode some money with the public key, see if anyone cashes it.) There are economies of scale in shared monitoring of trust, so perhaps only a few dozen such servers would be needed.
I don't follow this. How do you know a node (=server) hasn't just "peeked." (BTW, if you've properly split your message/key up, peeking by any one node will get them nothing--just bits--so they'll be disinclined to ever peek.) I don't see how anyone but the node itself can discover its private key, even if it cheats, peeks, or colludes. (Which is not to say that unreliable or dishonest nodes will not be revealed. I suspect it'll be more by testing agencies rather than by (somehow) having the private key revealed...even a dishonest node will keep its private key private. Possibly there are schemes that would allow proof of "early opening" (cheating) to be revealed, vaguely analogous to Chaum's scheme whereby digital money spent twice points to the spender...but offhand I don't see an approach.)
Hmm.. but how does the server get paid if the public key is public knowledge?
A node or server gets paid by the digital cash attached either at the time of arrival at the node (paying "rent" in advance, as it were), or after decrypting after some amount of time (paying upon "checking out," as it were). (Any message which doesn't include the necessary payments, by whatever terms the node has set, doesn't get stored, sent, etc.--we saw a lot of messages ending up in the bit buckets for failure to follow a remailer's protocols when we played the "Crypto Game" at the physical Cypherpunks meetings several months ago.) The messages or packets sent between nodes can have various sub-parts, including instructions for remailing (as with any remailer network), payments for various services (such as holding the message for 2 years, or splitting the message further, whatever), and so on. In general, each message is sent to a node, with only that node being able to open it (as it's encrypted with the public key of the node). Once opened, the node may find various other messages, payments, instructions, etc. If you meant something else by your question, I don't get it. Please ask it again. -Tim -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: MailSafe and PGP available.
Timothy C. May asks (regarding my naive proposal):
I don't follow this. How do you know a node (=server) hasn't just "peeked." ... If you meant something else by your question, I don't get it. Please ask it again.
Yeah I think my terseness led to some communication failure. I was imagining the key server publishing a key which thousands of folks might then use to close their time capsules. The key server doesn't know which messages where are closed with their key, and even if they did the messages are simultaneously closed with many different keys, so they'd need wide collusion to peek (including collusion with one of your escrow message holders). And as Dorn suggests the escrow holder of the message can't peek if "message itself could be encrypted using the intended eventual recipients public key". Dorn suggests:
The servers would generate a key pair on request, for a fee. Send you the public key to encrypt the "message" for storage somewhere.
I guess this might work, but now you have to be more specific in telling your escrow service where to look for public keys to decode you message. With just a few standard time-key servers, this isn't needed, and perhaps we could all share the costs of monitoring their trustworthyness. Needing just a few, the need might easily be met by charity. Robin
Robin sez
Dorn suggests:
The servers would generate a key pair on request, for a fee. Send you the public key to encrypt the "message" for storage somewhere.
I guess this might work, but now you have to be more specific in telling your escrow service where to look for public keys to decode you message. With just a few standard time-key servers, this isn't needed, and perhaps we could all share the costs of monitoring their trustworthyness. Needing just a few, the need might easily be met by charity.
The escrow services could run the time-key servers (since without the time-key servers, there would be less business for the escrow services). Getting keys would then be free and the cost of running the server could be subsidised from the cost of storing the message. corwin
I guess this might work, but now you have to be more specific in telling your escrow service where to look for public keys to decode you message. With just a few standard time-key servers, this isn't needed, and perhaps we could all share the costs of monitoring their trustworthyness. Needing just a few, the need might easily be met by charity.
Robin
Considering what we've currently had to rely on, charity seems like as good a place to start as any. Perhaps when escrow clients operate like wais in conducting a search of the available sources, and utilizing feedback to reduce noise and identify likelihoods of correct decryption, or perhaps this would never work at all. Monitoring would still be necessary. John Coryell.
participants (4)
-
corwin＠Cayman.COM -
John Coryell. -
Robin Hanson -
tcmay＠netcom.com