From: email@example.com (Timothy C. May)
Message Hash: e0b643e5bf2bae460b60127df26325f0a2f83662c4c232e237a66c15d837a496
Message ID: <199406110525.WAA00438@netcom.netcom.com>
Reply To: N/A
UTC Datetime: 1994-06-11 05:25:42 UTC
Raw Date: Fri, 10 Jun 94 22:25:42 PDT
From: firstname.lastname@example.org (Timothy C. May) Date: Fri, 10 Jun 94 22:25:42 PDT To: email@example.com Subject: Re: Timed-Release Crypto Message-ID: <199406110525.WAA00438@netcom.netcom.com> MIME-Version: 1.0 Content-Type: text/plain 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: firstname.lastname@example.org >Cc: email@example.com >Subject: Re: Timed-Release Crypto >Date: Wed, 10 Feb 93 15:11:35 -0700 >From: firstname.lastname@example.org >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, email@example.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."