1995-11-08 - Re: Timed-release crypto and information economics

Header Data

From: tcmay@got.net (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: b305bb52cf5a20eef7a0679e3a211d5dbcfb523765b7d108c9fc9c7536264c10
Message ID: <acc4182012021004674b@[205.199.118.202]>
Reply To: N/A
UTC Datetime: 1995-11-08 21:39:26 UTC
Raw Date: Thu, 9 Nov 1995 05:39:26 +0800

Raw message

From: tcmay@got.net (Timothy C. May)
Date: Thu, 9 Nov 1995 05:39:26 +0800
To: cypherpunks@toad.com
Subject: Re: Timed-release crypto and information economics
Message-ID: <acc4182012021004674b@[205.199.118.202]>
MIME-Version: 1.0
Content-Type: text/plain



First, let me congratulate Michael Shields for working on this problem, and
for (possibly?) coming up with a cleaner scheme.

I confess that I'm not clear on how his scheme differs from mine. Let me
hasten to add that my 1993 proposal was intended to be more conceptual than
practical, to illustrate how distibuted escrow agents (escrow in the real
sense, not in the GAK sense) could be used to "send messages into the
future," a tool that has several intriguing applications, some of which
Michael explores in the second part of his post.

At 12:09 AM 11/7/95, Michael Shields wrote:

>In the May proposal, when you have a message to be encrypted, you
>encrypt it with a session key, optionally split that key with an n-of-m
>scheme, and then send the key into a network of escrow agents, which are
>instructed to hold the message for a given period of time.  You then
>hold onto the encrypted message, though you need not keep it secret.
>Conceptually, you have encrypted a message and then remailed the key to
>yourself in such a way that it will take X length of time to arrive.

Sending either the pieces of the message or the pieces of the key seem
closely related to me (they go together). In principle, it is only the key
that counts, so that is what I would focus upon.

>I have a simpler, public-key plan.  When you want to keep a message
>secret until date X, you ask your favorite crypto house to generate a
>key pair and hold the secret key until date X.  You then encrypt your
>message with the public key, and again hold onto the encrypted message.
>N-of-m trust management can be implemented by secret-sharing your message
>and encrypting each with a key generated by a different crypto house.

This seems to be saying the same thing. In both cases, "Alice" is either
distributing a message to"Bob," "Charles," "Donna," etc., with instructions
not to return the pieces until Date X, or is holding onto a sealed message
but asking that the decryption keys not be returned until Date X. I don't
see the real difference, modulo some minor factors. In neither case can the
original message be reconstructed unless n out of m of the escrow agents
provide the pieces.

I hope we are not miscommunicating because of terminology or because of the
continuing Net problem of not being able to draw pictures showing what is
going on.


>I'll let everyone tear into this for a few days, and then I'll put up a
>server for timed-release key generation, charging maybe c$1.  I'd like
>to then enhance it to be capable of issuing bonds and loans denominated
>in c$.  (I like the cyberbucks trial because it's officially play money,
>so there aren't any regulatory burdens.)  This should be interesting.

In any case, I look forward to seeing reaction to this. This could be an
important service. (In many ways much more interesting than fairly mundane
"Internet commerce" applications.)

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
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."







Thread