Re: Timed-release crypto and information economics

First, let me congratulate Michael Shields for working on this problem, and
for (possibly?) coming up with a cleaner scheme.

I confess that I'm not clear on how his scheme differs from mine. Let me
hasten to add that my 1993 proposal was intended to be more conceptual than
practical, to illustrate how distibuted escrow agents (escrow in the real
sense, not in the GAK sense) could be used to "send messages into the
future," a tool that has several intriguing applications, some of which
Michael explores in the second part of his post.

At 12:09 AM 11/7/95, Michael Shields wrote:

>In the May proposal, when you have a message to be encrypted, you
>encrypt it with a session key, optionally split that key with an n-of-m
>scheme, and then send the key into a network of escrow agents, which are
>instructed to hold the message for a given period of time.  You then
>hold onto the encrypted message, though you need not keep it secret.
>Conceptually, you have encrypted a message and then remailed the key to
>yourself in such a way that it will take X length of time to arrive.

Sending either the pieces of the message or the pieces of the key seem
closely related to me (they go together). In principle, it is only the key
that counts, so that is what I would focus upon.

>I have a simpler, public-key plan.  When you want to keep a message
>secret until date X, you ask your favorite crypto house to generate a
>key pair and hold the secret key until date X.  You then encrypt your
>message with the public key, and again hold onto the encrypted message.
>N-of-m trust management can be implemented by secret-sharing your message
>and encrypting each with a key generated by a different crypto house.

This seems to be saying the same thing. In both cases, "Alice" is either
distributing a message to"Bob," "Charles," "Donna," etc., with instructions
not to return the pieces until Date X, or is holding onto a sealed message
but asking that the decryption keys not be returned until Date X. I don't
see the real difference, modulo some minor factors. In neither case can the
original message be reconstructed unless n out of m of the escrow agents
provide the pieces.

I hope we are not miscommunicating because of terminology or because of the
continuing Net problem of not being able to draw pictures showing what is
going on.


>I'll let everyone tear into this for a few days, and then I'll put up a
>server for timed-release key generation, charging maybe c$1.  I'd like
>to then enhance it to be capable of issuing bonds and loans denominated
>in c$.  (I like the cyberbucks trial because it's officially play money,
>so there aren't any regulatory burdens.)  This should be interesting.

In any case, I look forward to seeing reaction to this. This could be an
important service. (In many ways much more interesting than fairly mundane
"Internet commerce" applications.)

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

-----BEGIN PGP SIGNED MESSAGE-----

In article <acc4182012021004674b@[205.199.118.202]>,
Timothy C. May <tcmay@got.net> wrote:
> This seems to be saying the same thing. In both cases, "Alice" is either
> distributing a message to"Bob," "Charles," "Donna," etc., with instructions
> not to return the pieces until Date X, or is holding onto a sealed message
> but asking that the decryption keys not be returned until Date X. I don't
> see the real difference, modulo some minor factors. In neither case can the
> original message be reconstructed unless n out of m of the escrow agents
> provide the pieces.

Here are some attacks where my scheme is more resistant.  I'll suppose
that Alice is writing a bond, i.e., time-delayed cash, to Bob.


1. Alice does not really write a bond

In my plan, Alice gives Bob the message along with a certificate saying
that it is a bond.  If the message is actually not a bond, Bob can
demonstrate fraud upon the maturity date without revealing his identity,
by posting the now-readable message along with the contradictory signed
statement from Alice.

In your plan, Alice cannot provide the actual message to Bob, nor
prove that she even sent anything through the blind remailer network.
Bob would have to ask her to sign a certificate saying that she wrote
a bond to Bob for $n to mature on date X; she may not be willing to
admit that in a publicly demonstrable way.  And if she defrauded Bob,
he cannot prove he did not receive a bond.


2. The crypto houses lose keys/messages

In my plan, the crypto house's signature on the public key it issues
guarantees that the secret key will be available upon the maturity date.
If the house loses the secret key, then anyone can prove this, again
anonymously, by publishing the signed public key and asking anyone to
try to purchase the corresponding secret key.  The house cannot say it
is a false claim.  The unreliable house hemorrhages reputation, and Bob
still has his money as long as n houses were reliable.

In fact, even if Bob ca'n't trust n houses, he can still hedge.  He would
just buy a futures coupon saying that the house in question will lose
a key.  This is a classic use of hedging, and it allows him to recover
his money, anonymously.

In your plan, you just have to hope the remailers don't lose more than
m-n parts.  You rely on reputation-raters to judge reliability in a
probabilistic manner.  This works ok currently, with amateur remailers,
but not in a future world held to the 100% standards of financial
reliability.  (And those standards are very high.  Consider the public
reaction if you saw proof that a bank had "lost" someone's checking
account, one among a million.)


3. The crypto houses leak keys/messages

In my plan, this is ok.  You need both the keys *and the message*
to decrypt.  Only Bob holds the message.  (It's axiomatic that you can
keep a secret out of self-interest; your personal private key is such
a secret.)  In fact, at the maturity date, the secret keys will become
available to anyone, and Bob still won't be hurt.

Meanwhile, crackers have incentive to steal keys even without breaking
messages, because they can use them to make a profit on "Megahouse leaks
keys" futures, by posting the secret key matching a signed public key.
This can be anonymous, or they can use it to raise their nym's reputation
among crackers.  Because Megahouse knows it will be caught *every time*
it leaks, it must keep 100% financial-quality security.  This is an
excellent failure mode because all failures will be public.

In your plan, you just have to hope fewer than n pieces are made available
to the cracking ring.  And when you get a bond consisting of double-spent
bills, you ca'n't tell who broke security.  This is intractable for a
reputation-rater to determine to the necessary standards of accuracy.


4. Alice leaks the message

This is "fraud through negligence" and is treated as in case 1.  If Bob
thinks it's likely, he can hedge by buying a "Alice shown untrustworthy"
futures coupon.  (Those will be *so* useful.)


Because of the two-part design of a delayed message, it takes collusion
by those in possession of ciphertext *and* keys to unseal a message.
Before the maturity date, only Alice and Bob have the message, and only
the banks have the keys.  The message is of value only in that it will
be valuable in the future along with the then-available secret keys.
(Or, I suppose, possibly to prove fraud; that's of even more value.)
All collusion can be righted, everything is anonymous unless reputations
are involved, and all fraud is publicly exposed.

These are interesting properties.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMJ81SeyjYMb1RsVfAQG5GQP/RP5IkcQUFo++aBWHUmoTGuIBphykQxp/
HR40yt4GzIJQUIpEbM7iiD6Dk9hDLoF4GY9MQrPnxmhfGu4uITxYeDMfsPHJLv01
xCu9//xYJ9Usb3eWJFSURhBkSQg05T4upZX2KTj5NlTB4dbMJumReDeUix236FaU
W2eRxdiw0Us=
=zCpp
-----END PGP SIGNATURE-----
-- 
Shields.