Re: Timed-Release Crypto

[tcmay@netcom.com (Timothy C. May)]

The timed-release crypto message I just forwarded (in a kind of
timed-release fashion) generated some interesting comments from Karl
Barrus, Marc Ringuette, Robin Hanson, Eric Hughes, and even Larry
Detweiler--back when he was not so antipathetic (he's pathetic _and_
antipathetic, paradoxically) to our group.

For historical reasons, and because he makes some good points, here's his post:


>To: cypherpunks@toad.com
>Cc: ld231782@longs.lance.colostate.edu
>Subject: Re: Timed-Release Crypto
>Date: Wed, 10 Feb 93 15:11:35 -0700
>From: ld231782@longs.lance.colostate.edu
>X-Mts: smtp
>
>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...
>
>

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