Timed-Release Crypto

[Robin Hanson]

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