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

Header Data

From: tcmay@netcom.com (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: 0f4431091c3bb3a10a9ee473bf3574d0335ecc99067fdbc52b8b48678ec2c5cc
Message ID: <9302111948.AA22424@netcom.netcom.com>
Reply To: N/A
UTC Datetime: 1993-02-11 19:49:55 UTC
Raw Date: Thu, 11 Feb 93 11:49:55 PST

Raw message

From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 11 Feb 93 11:49:55 PST
To: cypherpunks@toad.com
Subject: Re: Timed-Release Crypto
Message-ID: <9302111948.AA22424@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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.








Thread