Re: Time Locks-- Re: Delayed self-encrypting messages
(Timelock algorithm deleted) --- That is a good way for locking it up for a while, but if it is really time sensitive, the use of parallel key guessing machines would stick a sock in this method. Here are some (non crypto) alternatives that you can use if you want to delay giving out the key after posting the cyphertext of the message: 1: Give the key to a trusted party, like your attorney to give out. 2: Find some way of getting the key lost via transport via SMTP daemons. If a host gets mail regularly via a UUCP connection, bounce it X times off that host. 3: Get the key "lost" in snail mail by this route. Mail it to a friend or a neutral party (Many copies if you may be snuffed in the process, to many people, and make "smokescreen" mails too). This would only work for messages with a short delay (24-48 hours). 4: (Very farfetched, but I am running out of ideas) Use a laser to bounce the key off a far planet or some body and the light travelling to there and back may give a decent delay. I do not know how you would get a coherent message back though. BTW: The time-lock idea sounds good, the mail list driver echoed it twice :) PS: Anyone have any better ideas for a secure crypto way of doing this? ;)
Date: Fri, 10 Jun 94 16:13:03 CDT From: dfloyd@runner.jpl.utsa.edu (Douglas R. Floyd) Anyone have any better ideas for a secure crypto way of doing this? ;) Create your message. Using PGP, generate a new key pair. Use the public key to encrypt the message, then throw it away. Send the secret key along with the message. Have the signature for the secret key be the NYT headline for the day on which you want the data to be available :-) Stepping back from the details of various crypto approaches, I think that the problem is that you want a locking mechanism to be based on data. Since you want a time lock, the data has to be directly associated with time. For this to work, you need to create data that is unknowable until a certain time. If the data is known to you, you've come full circle: you're new goal is your original goal. If the data is not known to you, it needs to be something which the other party cannot deduce prior to the expiration of your time lock. To be confident that no one could deduce this information, a prerequisite would have to be that you couldn't deduce it, that is, it wouldn't be something that you could use as part of an encryption. I think that this problem ultimately requires a trust based mechanism. Rick
From: Rick Busdiecker <rfb@lehman.com> Date: Fri, 10 Jun 1994 20:14:58 -0400 . . . Have the signature for the secret key . . . . ^^^^^^^^^ Er, I meant passphrase of course. Sigh. Rick
participants (2)
-
dfloyd@runner.utsa.edu -
Rick Busdiecker