Re: Time release crypto

[tcmay@got.net (Timothy C. May)]

At 10:16 PM 9/18/95, Stephen D. Williams wrote:
>What minimal requirements would be needed to support encrypted packets/files
>that a holder could only decrypt after a certain date/time?
>(Time Escrow?)


An interesting topic, of which there have been several discussions of in
the past few years. A check of the archives will reveal dozens of articles.
(My own archives contain more than 30 articles on this topic.)

I'm not trying to squelch any debate. I would ordinarily respond to this
thread, and write an article, but with all the archived articles, why
bother?

This last came up in a major way in June of 1994, with several articles
posted by me, Eric Hughes, Eli Brandt, Peter Wayner, Russ Busdiecker, Karl
Barrus, Blanc Weber, and all the Usual Suspects (but not Kiser Sose).


I'll forward an article (below) I did in in 1993 on timed-release crypto.

--Tim May


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