-BEGIN PGP SIGNED MESSAGE-
At 10:43 PM 3/9/00 -0500, Arnold G. Reinhold wrote:
[much deleted]
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
At 12:55 AM -0600 3/10/2000, John Kelsey wrote:
[much deleted]
Actually, the subpoena threat means that we need to put the
entities holding shares of the secret in places where even
we can't find them. In the extreme case, there's some
machine somewhere with e-mail access, which may carry some
-BEGIN PGP SIGNED MESSAGE-
At 05:08 PM 3/10/00 -0500, Arnold G. Reinhold wrote:
At 12:55 AM -0600 3/10/2000, John Kelsey wrote:
[stuff deleted]
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
In message [EMAIL PROTECTED], John Kelsey writes:
Nor do I. But there's a related engineering question: Does
it make sense to build large systems in which there's no way
for humans to overrule the actions of programs once they're
set in motion? *That* is the question I'm raising, not
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
I think the secret sharing direction as Raph has described below is indeed
the most reasonable way to solve this problem. In fact, for a long time,
I've considered such a `secure long term archive` one of the important
applications to the work we've been doing on Proactive security, which
takes
-BEGIN PGP SIGNED MESSAGE-
I want to know whether there is a crypto building block which doesn't allow
someone to open an encrypted message before a certain date.
[Damn hard. Math functions don't grok "date". The only reasonable way
to do this without a trusted third party is to pick an
Would this work? Maybe it's too simple.
1. A sends B an encrypted file.
2. Sometime later, A sends B the decryption key.
I haven't had a chance to read all the links listed here, yet, due to the
press of other matters.
It does sound like an interesting problem, which may depend on a
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
In the future, it may be possible to base something like this on
physical principles. For example (and if I haven't dropped a decimal
point), Jupiter is never closer than about 2079 light-seconds from
Earth. A message encrypted with the public key of a satellite in that
orbit could not be
On Wed, Mar 08, 2000 at 05:05:24AM +0800, Arrianto Mukti Wibowo wrote:
Hi,
I want to know whether there is a crypto building block which doesn't allow
someone to open an encrypted message before a certain date.
[Damn hard. Math functions don't grok "date". The only reasonable way
to do
At 05:05 3/8/2000 +0800, Arrianto Mukti Wibowo wrote:
Hi,
I want to know whether there is a crypto building block which doesn't allow
someone to open an encrypted message before a certain date.
[Damn hard. Math functions don't grok "date". The only reasonable way
to do this without a trusted
One nice number-theoretic approach to the problem of preventing someone
(including the original sender) from decrypting a message before a
certain amount of time elapses can be found in the paper:
Time-lock puzzles and timed-release Crypto
by Ronald L. Rivest, Adi Shamir, and David A.
13 matches
Mail list logo
