1993-02-11 - Re: Timed-Release Crypto

Header Data

From: Robin Hanson <hanson@ptolemy.arc.nasa.gov>
To: cypherpunks@toad.com
Message Hash: 42c54753e9ed0d0c04b3e62bb1a2f367abcd04df033f61b48aea13dbd986f744
Message ID: <9302112058.AA03778@ptolemy.arc.nasa.gov>
Reply To: <9302111948.AA22424@netcom.netcom.com>
UTC Datetime: 1993-02-11 20:58:09 UTC
Raw Date: Thu, 11 Feb 93 12:58:09 PST

Raw message

From: Robin Hanson <hanson@ptolemy.arc.nasa.gov>
Date: Thu, 11 Feb 93 12:58:09 PST
To: cypherpunks@toad.com
Subject: Re: Timed-Release Crypto
In-Reply-To: <9302111948.AA22424@netcom.netcom.com>
Message-ID: <9302112058.AA03778@ptolemy.arc.nasa.gov>
MIME-Version: 1.0
Content-Type: text/plain

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