[ Hmmm, maybe I'd better get this message out quickly, before it expires... :-] At 07:21 AM 11/8/95 -0500, John Curtis <jbell@capecod.net> wrote:
The discussion between Mr. May and Mr. Shields concerning time-release cryptography raised an interesting question in my mind.
Given that trust is often of an ephemeral nature, it would be quite useful to set time limits on secrets. Would it be possible to cryptographically protect a secret such that it could not be decrypted after a certain time?
Decryption is equivalent to knowing a secret plus doing some work. There are two ways to make information available/unavailable - by depending on calculations from known data, or by having people agree to publish/delete it. The former method is trustable, but doesn't have time built in to it - either you know stuff or you don't. The latter method is harder to trust - you can build contractual mechanisms to encourage people to keep their commitments, and use crypto methods like splitting shared secrets to limit the impact of some of them not keeping them - but it's basically not cryptographic. Getting people to keep information secret for a while and then publish is possible; that's within their control. Getting people to keep information public, and then delete all the copies they own is possible, but if the information is _public_, anybody in the world could have a copy - deleting it requires finding them all, and getting them all to agree to delete it. That's _much_ harder. You could build a system where an escrow agent keeps a piece of information private, but available upon request, and deletes it on a certain date. That lets you know that _if_ nobody's asked for the information by then, and the agent has done its job, that nobody else will be able to decrypt it. Again, you can secret-share among multiple agents to decrease the impact of defaults (either failure-to-delete or failure-to-deliver.) A related approach is for the agent to provide a service of decrypting data encrypted with the agent's public key, and agreeing only to decrypt data before or after some date specified in the message. Another technique you can use is to for the agent to keep the data until paid for delivery; the retrieval token includes a digital check with an expiration date. In this case, you're trusting the bank to not honor the check after its expiration date, and the escrow agent not to deliver the data without getting paid. For this service, you want checks rather than cash - if the check goes stale, the money is still in your account. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281