From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 10 Jun 94 22:11:45 PDT
To: cypherpunks@toad.com
Subject: Timed-Release Crypto
Message-ID: <199406110511.WAA28899@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Eli Brandt mentioned that the thread on timed-release crypto came up last
year. Here is a post I did on the subject.


>Date: Wed, 10 Feb 93 11:55:45 -0800
>To: cypherpunks@toad.com
>From: tcmay@netcom.com (Timothy C. May)
>Subject: Timed-Release Crypto
>
>
>Cypherpunks,
>
>I want to share with you folks some preliminary ideas on "timed-release
>cryptographic protocols," that is, methods for sending encrypted messages
>into the future.
>
>These ideas need more work, but since I have recently mentioned them to Hal
>Finney, Max More, Mark Miller, and perhaps others, I guess it's time to say
>something here.
>
>Why would anyone want to send encrypted (sealed) messages into the future?
>
>1. Foremost, to send money into the future, while protecting it in the
>meantime from seizure, taxation, etc. This might be of interest to cryonics
>folks who want to arrange for their own revival/reanimation at some time in
>the future. (Existing systems have relied on creating endowments, insurance
>contracts, trust funds, and the like. The trust of the agent is the means
>for sending funds into the future--clearly this agent could be compromised,
>raided, taxed, put out of business, etc. Though I am personally not a
>cryonics client, I began thinking about this problem in 1989 and talked it
>over with Phil Salin, who, ironically, is now himself in cryonic
>suspension.)
>
>2. To fulfill contracts with long payoff dates. One might wish to deliver
>money at some future date, or to supply information at some future date.
>
>3. "In the event of my death"-type messages, with guaranteed delivery of
>some message or text in the event that something happens (or, of course,
>that the message is not "countermanded" by the sender).
>
>4. A software publisher might place source code in a timed-release escrow,
>agreeing to release the code in 10 years, for whatever reason. (Of course,
>he may lie, but that's another issue. Possibly the digital time-stamping
>work of Haber and Stornetta can be used.)
>
>I'm sure you can think of other uses. I argue that this timed-release
>message is a kind of cryptographic primitive...though it may be argued that
>it's just a variant of an ordinary message transmission, albeit one through
>time instead of through space.
>
>Diving right in, some approaches:
>
>A message is encrypted (standard public key means, though private key
>methods work the same way) and "sent out." Perhaps into a network of
>remailers or a Cuperman-style "pool" (BTW, my compliments to Miron C. for
>deploying such a thing..the first of many, I suspect). The encrypted
>message is just a "passive" item in this scheme...it stays encrypted, is
>available to all, etc. (in other words, the security of the message being
>time-released does not in any way depend on hiding the existence or
>location of the encrypted message, though of course it is important that
>the encrypted message be widely distributed and not explicitly advertised
>or tagged as being a timed-release message.
>
>(Detail note: Why not? Because some governments may see timed-release
>messages as automatically being tax-avoiding, cryonics-supporting,
>seditious, etc., messages and may attempt to hunt down and erase any such
>messages...perhaps via "hunter-killer crypto viruses" or somesuch.)
>
>Let us suppose the encrypted message is to be unlocked in 30 years. (It
>could also be when some recognized event occurs, such as a Mars landing or
>the death of the sender, or whatever...you'll see how this works). How can
>the decryption key be prevented from being used in the meantime?
>
>(To make this clear: both the encryted message _and_ the decryption key are
>"in circulation" during all of those 30 years. Any scheme that relies on
>the sender himself keeping the decryption key "secret" for those 30 years
>is of course no fun at all...it's just what we have today and involved no
>new cryptographic primitives, just ordinary human-mediated secrecy.)
>
>But if the encrypted message and the decryption key are both in circulation
>for all of those 30 years, what's to keep someone from decrypting the
>message in _one_ year, for example?
>
>The answer: independent escrow agents who handle large volumes of messages
>and agree to hold them for various amounts of time. Because they have no
>idea of what's insided the encrypted messages they hold--and some may be
>"test" messages deposited deliberately by reputation-rating or
>credentialling agencies, such as "Consumers Crypto Guide"--and because
>their business is holding things in escrow, they will not generally open
>messages before the time specified.
>
>"Aha!," I hear you exclaim, "Tim's scheme depends solely on the trust of
>these escrow agents, and that's no different from depositing a sealed
>envelope with your friendly lawyer and asking him to promise not to peek."
>
>Here's how crypto and reputation-based sytems make my scenario different
>(and stronger, I am arguing):
>
>- an ecology of many escrow services, many pools, many encrypted-message
>senders makes for a more robust system against subversion of any single
>agent.
>
>- no escrow agent knows what is contained in a sealed message, hence the
>tempation to peek is reduced. (A wrinkle: escrow agents, like remailers,
>will probably go to automatic hardware that is tamper-resistant (cf.
>discussion of tamper-resistant or tamper-responding, modules in the Crypto
>Glossary distributed at the first physical Cypherpunks meeting and
>available in the archives). Thus, the hardware will automatically execute
>certain protocols and make peeking a pain.)
>
>- the best escrow agents (someday) may in turn increase security and their
>own reputations by in turn using secondary contracts, i.e., by contracting
>with _other_ escrow agents to seal parts or all of their messages.
>
>- what results is that the original message is scattered around in various
>publicly available locations (perhaps paid-for by dribbles of cryto-money
>from crypto escrow agents, but this is a detail easily worked out in
>various ways). The decryption key to the original message is itself broken
>up into several or many pieces and scattered to a network of
>"remailer"-like agents (they are essentially "remailers into the future,"
>by agreeing as part of their protocol to hold messages for some amount of
>time). As time passes, these various messages (pieces, remember) are
>retrieved, forwarded, and generally bounced around the network.
>
>- some escrow agents may be just "fixed delay" nodes. For example, "Alice's
>Rest Stop" remailer node widely advertises that it will take in messages
>and simply delay them for some fixed time, e.g., for a year. For some fee
>based on message size. (Clearly the fixed time delay is a crufty approach,
>much less flexible than variable delays negotiated by the messages
>themselves, but it makes the idea clearer in some ways: a network of many
>such one-year delays could thus "send" a message into the future in
>one-year jumps.)
>
>(It is important to remember that these messages are "first-class objects,"
>to borrow a phrase, and that all messages essentially look the same and
>have the same "rights" (Dean Tribble is probably barfing at my
>appropriation of object-oriented lingo, but it seems appropriate). That is,
>inspection of the bytes will not reveal to someone whether the message is a
>$2 message, a simple love letter, a business contract, a remailed item, a
>$100K cryonics payment, etc. Thus, the "authorities" cannot simply target
>some class of messages and ban them or launch "hunter-killer crypto
>viruses" against them, at least not without shutting down the whole
>system!)
>
>- the individual pieces may have instructions attached, such as "You will
>be paid 10 crypto credits if you hold me for one year and then decrypt me."
>(Not to belabor the point, but the means by which this "contract" can be
>enforced are that the escrow agents never know when they're being tested,
>when they're being monitored by rating services. This kind of "trust" is
>what allows ordinary deposit banks to work...their business is talking
>deposits and lending money, not repudiating the honest claims of
>customers.)
>
>- thus, I envision a swarm of messages being stored-and-forwarded in space
>and time, with an observor seeing only  bits flowing around. Nobody except
>the original "launcher" (who needs to be fairly careful about the path he
>selects, about robustness against some fraction of the escrow/remailer
>agents going out of business, etc.) knows what's going on.
>
>- and as the end of the 30 years period approaches, to continue with the
>example I started with, the decryption key gets "reconstituted" in various
>ways (depends on what is desired, and how protocols evolve...I don't claim
>to have the details already worked out). For example, after 30 years the
>various messages stored in escrow accounts are forwarded separately to "The
>Immortalist Foundation," which may in fact be a digital pseudonym (as we
>have discussed so many times here). This entity puts the pieces together,
>sort of like combining the missing pieces of a text and reconstituting a
>genie or demon, and finds it can now unlock the original encrypted message.
>It finds, say, a million crypto credits, or the location of some physical
>treasure, or whatever.
>
>(Needless to say, there are some obvious questions about what long-term
>money will be stable, what banks will still exist after 30 years, and so
>on. I expect new forms of time deposits to evolve. Can the original sender
>be expected to know what will evolve before he seals his original message?
>Some obvious issues to work on--I never claimed it would be trivial, or
>static. One approach is to allow some human intervention, where an
>"investment agent" opens a digital money message, redeems it, and reinvests
>it in some new instrument. As usual, he would not know who the original
>investor was and would be "tested" by reputation-rating agencies. It _does_
>get complicated, I know.)
>
>The Key Point: Messages sent into this network of remailers, escrow
>accounts, pools, and investment agents are untraceable to the sender and
>are generally unidentifiable. To break a single message involves breaking
>the entire system (or colluding with enough remailer nodes, as in any
>DC-Net sort of system). As with remailer networks, the expectation is that
>they will become sufficiently pervasive and trans-nationalized that
>breaking the entire system is just too painful and difficult (much the way
>the Net is already too pervasive to easily shut down, even if some uses of
>it are undesirable to various national authorities).
>
>Timed-release messages are objects that can be transmitted, encrypted, and
>can carry further instructions on where to mail them next, on how much
>digital money to pay to this next link, and various other instructions or
>protocols.
>
>(In other words, they are "agents" that can negotiate various contracts,
>for remailing , for storage, etc. Since they are "powerless" in a human
>sense, their security is provided by double-checks--perhaps by other agents
>who are watching and waiting--and by the general "shell-game" system of
>reputations, credentialling, and so on.)
>
>To make this scheme clearer in a simple way, I could publicly post an
>encrypted message to this list, or in one of the "pools," and then scatter
>the decryption key in several pieces with several members of this list,
>paying them $1 each to "hold" their piece for, say, a month. At the end of
>the month, they would fulfill their end of the bargain by forwarding the
>piece they hold to some public place or pool and the decryption key would
>be reconstituted (don't press me for exact details....PGP doesn't support
>this directly, but could). For robustness against loss of some of the
>messages, an n-out-of-m voting scheme could be used (e.g., any 5 of 8
>pieces are sufficient to reconstruct the decryption key).
>
>The result is a message from the past, a timed-release message.
>
>I'm anxious to hear your comments. I think such a cryptographic primitive
>could be useful for a lot of purposes.
>
>-Tim May
>
>--
>
>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: waiting for the dust to settle.
>
>
>
>

..........................................................................
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^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."