At 10:56 AM -0500 3/8/2000, Steven M. Bellovin wrote:
>In message <[EMAIL PROTECTED]>, "Matt Crawford" writes:
>>
>> If you're going to trust that CryptoSat, inc. hasn't stashed a local
>> copy of the private key, why not eliminate all that radio gear and trust
> > CryptoTime, inc. not to publish the private key associated with date D
>> before date D?
>
>The minor answer is that I could postulate that CryptoSat sells slots for
>various parties (including senders of time-delayed messages) to install their
>own tamper-resistant boxes.
Indeed, each box could have a share of each secret key and the
satellite would simply broadcast the year's key once enough of the
trusted boxes had released their shares. Each box would have its own
clock and release share information by modulating an LED with a light
pipe through the box's skin. The central computer would have no
communication channel back to any of the trusted boxes. Then there is
no need to mess with time delays. You'd need a couple of satellites
in case one failed.
>
>But the major answer is time scale -- I only have to trust CryptoSat for a
>short period, while I have to trust CryptoTime for the entire delay period.
In particular a satellite is pretty much subpoena proof. The
subpoena threat is very real for CryptoTime, Inc. because courts tend
to lean in favor of granting them, even if the underlying case
presented is weak. E.g. Jones v. Clinton. So someone with a fairly
frivolous case can undermine confidence in the whole system even
assuming CryptoTime has the best of intentions.
All that said, I still think a ground based system using multiple
repositories in many jurisdictions is worth trying. One wrinkle might
be to forget about secret sharing since it requires a central
coordinated act. Instead each repositor (A, B, C, D, ...) generates a
separate set of public and private keys for each year. All the public
keys are posted on a key server. A user that wishes to time escrow
data can do m out of n by encrypting with subsets of the full set of
posted public keys for any given year. For example, to achieve two
out of three security ten years out, the user would super-encrypt his
symmetric key with A2010,B2010 and A2010, C2010 and B2010, C2010.
>
>The real answer, though, is that you're probably right -- there's too much
>temptation in this field to use technical mechanisms, when contract law will
>suffice.
You may be right in practice, but it seems to me that a major goal of
crypto research is to figure out how do do things in a way that does
not rely on contract law and other forms of "trust me."
Arnold Reinhold
