From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: a2cef238288affbb664c6f3e842db28a371d402bda8591741abf1cfcd149fc63
Message ID: <9406110012.AA21394@ah.com>
Reply To: <199406102004.AA12160@crl.crl.com>
UTC Datetime: 1994-06-11 00:01:50 UTC
Raw Date: Fri, 10 Jun 94 17:01:50 PDT
From: hughes@ah.com (Eric Hughes)
Date: Fri, 10 Jun 94 17:01:50 PDT
To: cypherpunks@toad.com
Subject: Delayed self-encrypting messages
In-Reply-To: <199406102004.AA12160@crl.crl.com>
Message-ID: <9406110012.AA21394@ah.com>
MIME-Version: 1.0
Content-Type: text/plain
I have a need to distribute some information fairly widely, but it's
critical that it not be openly revealed before a certain date.
The problem is underspecified. What is the threat model? That is,
what are to trying to prevent from happening, and what are you trying
to ensure will happen?
If you're just worried that the information will get suppressed if it
sits in one place, encrypting with symmetric cipher and a random key
and publishing the ciphertext does quite well. You can then give
trusted parties the key. This has been suggested.
If you want to make sure the message can be decrypted without further
intervention on your part, you need to farm that job out to someone
else. Use another person, or a public key beacon, but some
other party will be involved. If you can make that party a public
service (like a beacon), then you've depersonalized the problem.
The simplest public key beacon works as follows. The operators of the
beacon publish a list of public keys, one per time period--let's say
days here. The beacon is programmed to give out any particulare
private key at the beginning of its day. To use this, simply encrypt
with the public key of the date you want the message to be revealed.
The message will be decryptable on that date, when the beacon's key is
revealed.
An interesting research project would be to construct one of these to
sit in orbit.
Eric
Return to June 1994
Return to “Paul Schauble <pls@crl.com>”