Re: Timed-Release Crypto

Robin Hanson writes:

>[This is a first post by a crypto-naive person - be kind.]

>What came to my mind as I read Tim's message was various competing
>timed-key servers, each publishing its public key associated with
>various future dates, and promising to release the associated private
>key on that date (but not before).  

Yes, a market or ecology of servers, with various competing capabilities
and reputations. "Distributed trust" is quite effective. 

(Someone sent me private e-mail saying he didn't like my scheme because it
wasn't as "mathematically solid" as pure encryption schemes. Let me point
out that many crypto schemes involve issues of trust, distributed trust,
collusion, and even trust. "Pure" schemes do not in general exist, except
as very basic operations. As one example, there are no unforgeable "digital
coins." And even the information-theoretically secure "dining
cryptographers" protocol is unsecure given enough collusion. The role of
reputations--common in business and interpersonal dealings--is generally
ignored in the academic crypto community, who end up tearing their hair out
over extremely complicated protocols that attempt to avoid issues of
reputation and economic incentives. Folks like Dean Tribble and Robin
Hanson have a lot to contribute to the actual realization of distributed,
agoric crypto systems.)

>You then encode your message with an m-of-n scheme using n such
>server's keys for your chosen date, and assume at least m of them will
>eventually publish their promised key, and assume no more than m of
>them will release early.  You then leave it with several escrow
>services and ask them to try to decrypt it once a year with the new
>year's keys.
>
>To prove to all that a server is untrustworthy, simply reveal its
>private key ahead of time, and win a bond posted by the service (easy
>to implement - encode some money with the public key, see if anyone
>cashes it.)  There are economies of scale in shared monitoring of
>trust, so perhaps only a few dozen such servers would be needed.

I don't follow this. How do you know a node (=server) hasn't just "peeked."
(BTW, if you've properly split your message/key up, peeking by any one node
will get them nothing--just bits--so they'll be disinclined to ever peek.)
I don't see how anyone but the node itself can discover its private key,
even if it cheats, peeks, or colludes.

(Which is not to say that unreliable or dishonest nodes will not be
revealed. I suspect it'll be more by testing agencies rather than by
(somehow) having the private key revealed...even a dishonest node will keep
its private key private. Possibly there are schemes that would allow proof
of "early opening" (cheating) to be revealed, vaguely analogous to Chaum's
scheme whereby digital money spent twice points to the spender...but
offhand I don't see an approach.)

>Hmm.. but how does the server get paid if the public key is public
>knowledge?   

A node or server gets paid by the digital cash attached either at the time
of arrival at the node (paying "rent" in advance, as it were), or after
decrypting after some amount of time (paying upon "checking out," as it
were). (Any message which doesn't include the necessary payments, by
whatever terms the node has set, doesn't get stored, sent, etc.--we saw a
lot of messages ending up in the bit buckets for failure to follow a
remailer's protocols when we played the "Crypto Game" at the physical
Cypherpunks meetings several months ago.)

The messages or packets sent between nodes can have various sub-parts,
including instructions for remailing (as with any remailer network),
payments for various services (such as holding the message for 2 years, or
splitting the message further, whatever), and so on. In general, each
message is sent to a node, with only that node being able to open it (as
it's encrypted with the public key of the node). Once opened, the node may
find various other messages, payments, instructions, etc.

If you meant something else by your question, I don't get it. Please ask it
again.

-Tim

--

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^756839 | Public Key: MailSafe and PGP available.

Timothy C. May asks (regarding my naive proposal):

>I don't follow this. How do you know a node (=server) hasn't just
>"peeked."  ... If you meant something else by your question, I don't 
>get it. Please ask it again.

Yeah I think my terseness led to some communication failure.

I was imagining the key server publishing a key which thousands of
folks might then use to close their time capsules.  The key server
doesn't know which messages where are closed with their key, and even
if they did the messages are simultaneously closed with many different
keys, so they'd need wide collusion to peek (including collusion with
one of your escrow message holders).  And as Dorn suggests the escrow
holder of the message can't peek if "message itself could be encrypted
using the intended eventual recipients public key".

Dorn suggests: 
>The servers would generate a key pair on request, for a fee.  Send you
>the public key to encrypt the "message" for storage somewhere.  

I guess this might work, but now you have to be more specific in
telling your escrow service where to look for public keys to decode
you message.  With just a few standard time-key servers, this isn't
needed, and perhaps we could all share the costs of monitoring their
trustworthyness.  Needing just a few, the need might easily be met by
charity.

Robin

>I guess this might work, but now you have to be more specific in
>telling your escrow service where to look for public keys to decode
>you message.  With just a few standard time-key servers, this isn't
>needed, and perhaps we could all share the costs of monitoring their
>trustworthyness.  Needing just a few, the need might easily be met by
>charity.
>
>Robin

Considering what we've currently had to rely on, charity seems like
as good a place to start as any.  Perhaps when escrow clients operate
like wais in conducting a search of the available sources, and utilizing
feedback to reduce noise and identify likelihoods of correct decryption,
or perhaps this would never work at all.  Monitoring would still be
necessary.

John Coryell.

Robin  sez

>Dorn suggests: 
>>The servers would generate a key pair on request, for a fee.  Send you
>>the public key to encrypt the "message" for storage somewhere.  
>
> I guess this might work, but now you have to be more specific in
> telling your escrow service where to look for public keys to decode
> you message.  With just a few standard time-key servers, this isn't
> needed, and perhaps we could all share the costs of monitoring their
> trustworthyness.  Needing just a few, the need might easily be met by
> charity.

The escrow services could run the time-key servers (since without the time-key servers, there would be less business for the escrow services).  Getting keys
would then be free and the cost of running the server could be subsidised 
from the cost of storing the message.

corwin