From: Bill Stewart <stewarts@ix.netcom.com>
Date: Thu, 9 Nov 1995 08:42:49 +0800
To: John Curtis <jbell@capecod.net>
Subject: Re: expiration dates on cryptography
Message-ID: <199511082002.MAA25560@ix4.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


[ 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