From: ld231782@longs.lance.colostate.edu
Date: Wed, 10 Feb 93 14:12:43 PST
To: cypherpunks@toad.com
Subject: Re: Timed-Release Crypto
In-Reply-To: <9302101955.AA09009@netcom.netcom.com>
Message-ID: <9302102211.AA22756@longs.lance.colostate.edu>
MIME-Version: 1.0
Content-Type: text/plain


This is neat idea, T.C. May. Here are some things that popped into my
head thinking of it.

I think the idea of multiple encryption of the time-delay message would
be extremely useful here. Imagine this. You encrypt a message with as
many layers as there are intermediate escrows.  In other words, a
message is encrypted with layer1 pw, then reencrypted with layer2 pw,
then layer3, etc.  In the decryption message (separate) there is a long
sequence of keys.  The lower-level keys closer to the actual message
are also encrypted by the higher-level keys.  Now, suppose that the way
the message is held is this: after 1 level of protection has elapsed,
the password message and the encryption message are recombined to a
single escrow agent. That agent uses the top-level information (one key
is plaintext (maybe not), or encrypted with that agent's public key, or
whatever) to decode the top-level of encryption.  Then, he again
redistributes the next-lower-level of encryption password message and
actual message to unique escrow agents.

The beauty of this is that a given escrow agent, even once he gets a
password, can only strip off "his" topmost level of encryption (at
least, that's the intent). He is powerless to decrypt all the lower
levels and hence the message itself. Therefore to actually decrypt a
message ahead of time would require the collusion of many operators. 
The message should have some kind of indications at each level when it
is to be "reconstituted" (just add water), and escrow agents of course
should hold or reject messages that are sent to them for premature
decryption.  There is also the distinction of "joiners" and "storers"
although the two could be combined in some way (both are "forwarders").

The final destination should be the destination the original owner
intended, so that there is no final escrow agent that can decrypt the
message.  He only has an encoded message he can pass along, and another
agent only has a meaningless key and the final address as well.  When
the final destination is reached, the last layer of decryption can be
removed by the intended recipient (the money is in -X- account,
password -Y- or whatever).  I.e., the recipient is the final "joiner".

The idea of separating keys and the encoded messages is really
ingenious, and I'd guess this "disassociation" has other uses as well. 
An encrypted message with a password *existing* but *inaccessable* is
just as secure as a message using conventional encryption. In fact,
there is probably an added dimension of security---in most systems
*somebody* knows the key, but here, if it is generated automatically,
even the *key* is unknown for awhile!

Another possibility is to have some kind of standard protocol for time
encrypted messages (this is interesting and seems feasible). Let's say
I want a message [x] to be unencrypted on date [y].  I call a "time
encryption server" and ask for the secret key associated with my
message and date [y].  I encrypt the message and publicize that
version.  The time server is constantly spewing out the daily code for
messages that expire on that date. Anybody just listens to the
broadcast and decrypts the messages in their possession using the key. 
Note however that it is crucial that somehow the key depend on the
message itself (via the hashing approaches), otherwise everybody knows
everybody else's keys ahead of time just by submitting messages to the
server for the particular date.  I suppose public-key encryption could
be used here but I'm hazy on the details.

P.S. this is a really tricky situation compared to above, but it might
be possible to make messages with "insecure" passwords that can be
broken in a few lifetimes from searches. Of course, this depends very
crucially on the pace of technology and the resources devoted to the
cracking, two highly variable factors.

Also, keep in mind that every message in existence relying on
complexity of algorithms is encrypted based on the time-delayed release
of revolutionary and unforeseen computer techniques in cracking... or,
more specifically, the gamble that they will not occur...