Timed-Release Crypto

[Robin Hanson]

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

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

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

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.

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

Robin Hanson