Re: Timed-release crypto and information economics
First, let me congratulate Michael Shields for working on this problem, and for (possibly?) coming up with a cleaner scheme. I confess that I'm not clear on how his scheme differs from mine. Let me hasten to add that my 1993 proposal was intended to be more conceptual than practical, to illustrate how distibuted escrow agents (escrow in the real sense, not in the GAK sense) could be used to "send messages into the future," a tool that has several intriguing applications, some of which Michael explores in the second part of his post. At 12:09 AM 11/7/95, Michael Shields wrote:
In the May proposal, when you have a message to be encrypted, you encrypt it with a session key, optionally split that key with an n-of-m scheme, and then send the key into a network of escrow agents, which are instructed to hold the message for a given period of time. You then hold onto the encrypted message, though you need not keep it secret. Conceptually, you have encrypted a message and then remailed the key to yourself in such a way that it will take X length of time to arrive.
Sending either the pieces of the message or the pieces of the key seem closely related to me (they go together). In principle, it is only the key that counts, so that is what I would focus upon.
I have a simpler, public-key plan. When you want to keep a message secret until date X, you ask your favorite crypto house to generate a key pair and hold the secret key until date X. You then encrypt your message with the public key, and again hold onto the encrypted message. N-of-m trust management can be implemented by secret-sharing your message and encrypting each with a key generated by a different crypto house.
This seems to be saying the same thing. In both cases, "Alice" is either distributing a message to"Bob," "Charles," "Donna," etc., with instructions not to return the pieces until Date X, or is holding onto a sealed message but asking that the decryption keys not be returned until Date X. I don't see the real difference, modulo some minor factors. In neither case can the original message be reconstructed unless n out of m of the escrow agents provide the pieces. I hope we are not miscommunicating because of terminology or because of the continuing Net problem of not being able to draw pictures showing what is going on.
I'll let everyone tear into this for a few days, and then I'll put up a server for timed-release key generation, charging maybe c$1. I'd like to then enhance it to be capable of issuing bonds and loans denominated in c$. (I like the cyberbucks trial because it's officially play money, so there aren't any regulatory burdens.) This should be interesting.
In any case, I look forward to seeing reaction to this. This could be an important service. (In many ways much more interesting than fairly mundane "Internet commerce" applications.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."
-----BEGIN PGP SIGNED MESSAGE----- In article <acc4182012021004674b@[205.199.118.202]>, Timothy C. May <tcmay@got.net> wrote:
This seems to be saying the same thing. In both cases, "Alice" is either distributing a message to"Bob," "Charles," "Donna," etc., with instructions not to return the pieces until Date X, or is holding onto a sealed message but asking that the decryption keys not be returned until Date X. I don't see the real difference, modulo some minor factors. In neither case can the original message be reconstructed unless n out of m of the escrow agents provide the pieces.
Here are some attacks where my scheme is more resistant. I'll suppose that Alice is writing a bond, i.e., time-delayed cash, to Bob. 1. Alice does not really write a bond In my plan, Alice gives Bob the message along with a certificate saying that it is a bond. If the message is actually not a bond, Bob can demonstrate fraud upon the maturity date without revealing his identity, by posting the now-readable message along with the contradictory signed statement from Alice. In your plan, Alice cannot provide the actual message to Bob, nor prove that she even sent anything through the blind remailer network. Bob would have to ask her to sign a certificate saying that she wrote a bond to Bob for $n to mature on date X; she may not be willing to admit that in a publicly demonstrable way. And if she defrauded Bob, he cannot prove he did not receive a bond. 2. The crypto houses lose keys/messages In my plan, the crypto house's signature on the public key it issues guarantees that the secret key will be available upon the maturity date. If the house loses the secret key, then anyone can prove this, again anonymously, by publishing the signed public key and asking anyone to try to purchase the corresponding secret key. The house cannot say it is a false claim. The unreliable house hemorrhages reputation, and Bob still has his money as long as n houses were reliable. In fact, even if Bob ca'n't trust n houses, he can still hedge. He would just buy a futures coupon saying that the house in question will lose a key. This is a classic use of hedging, and it allows him to recover his money, anonymously. In your plan, you just have to hope the remailers don't lose more than m-n parts. You rely on reputation-raters to judge reliability in a probabilistic manner. This works ok currently, with amateur remailers, but not in a future world held to the 100% standards of financial reliability. (And those standards are very high. Consider the public reaction if you saw proof that a bank had "lost" someone's checking account, one among a million.) 3. The crypto houses leak keys/messages In my plan, this is ok. You need both the keys *and the message* to decrypt. Only Bob holds the message. (It's axiomatic that you can keep a secret out of self-interest; your personal private key is such a secret.) In fact, at the maturity date, the secret keys will become available to anyone, and Bob still won't be hurt. Meanwhile, crackers have incentive to steal keys even without breaking messages, because they can use them to make a profit on "Megahouse leaks keys" futures, by posting the secret key matching a signed public key. This can be anonymous, or they can use it to raise their nym's reputation among crackers. Because Megahouse knows it will be caught *every time* it leaks, it must keep 100% financial-quality security. This is an excellent failure mode because all failures will be public. In your plan, you just have to hope fewer than n pieces are made available to the cracking ring. And when you get a bond consisting of double-spent bills, you ca'n't tell who broke security. This is intractable for a reputation-rater to determine to the necessary standards of accuracy. 4. Alice leaks the message This is "fraud through negligence" and is treated as in case 1. If Bob thinks it's likely, he can hedge by buying a "Alice shown untrustworthy" futures coupon. (Those will be *so* useful.) Because of the two-part design of a delayed message, it takes collusion by those in possession of ciphertext *and* keys to unseal a message. Before the maturity date, only Alice and Bob have the message, and only the banks have the keys. The message is of value only in that it will be valuable in the future along with the then-available secret keys. (Or, I suppose, possibly to prove fraud; that's of even more value.) All collusion can be righted, everything is anonymous unless reputations are involved, and all fraud is publicly exposed. These are interesting properties. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJ81SeyjYMb1RsVfAQG5GQP/RP5IkcQUFo++aBWHUmoTGuIBphykQxp/ HR40yt4GzIJQUIpEbM7iiD6Dk9hDLoF4GY9MQrPnxmhfGu4uITxYeDMfsPHJLv01 xCu9//xYJ9Usb3eWJFSURhBkSQg05T4upZX2KTj5NlTB4dbMJumReDeUix236FaU W2eRxdiw0Us= =zCpp -----END PGP SIGNATURE----- -- Shields.
participants (2)
-
shields@tembel.org -
tcmay@got.net