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 Trusted
Third Party, which we know doesn't exist, or launching rocket ships, which
is costly. I was just thinking that if it is OK to trust oneself to later
send the key, then that might work, modulo an accident or personal lapse.
--
pj
re: subject - it is, of course, 'dependent' with e three times, no a.
On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote:
>
>
> 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 secret sharing forward by periodically refreshing the shares. (BTW,
> this is where I have a huge problem with Cryptonomicon!!)
>
> Here are some relevant works:
>
> For reference to most works on proactive security see our `proactive
> security homepage` at http://www.hrl.il.ibm.com/Proactive/index.html. For
> an easy overview see R.Canetti, R.Gennaro, A.Herzberg and D.Naor. Proactive
> Security: Long-term protection against break-ins. CryptoBytes RSA
> Laboratories Newsletter, August 1997.
>
> To see how to keep the clocks synchronized in such mobile adversary
> setting... ask me, it's a new result and we haven't put in the site yet -
> hope to do it soon
>
> to see how to keep the storage requirements reasonable see:
> Krawczyk, H., "Secret Sharing Made Short" Advances in Cryptology -- CRYPTO
> 93 Proceedings, Lecture Notes in Computer Science Vol. 773,
> Springer-Verlag, D. R. Stinson, ed , 1993, pp. 136-146.
> Krawczyk, H., "Distributed Fingerprints and Secure Information Dispersal",
> Proceedings of the Twelfth Annual ACM Symposium on Principles of
> Distributed Computing (PODC'93), 1993, pp. 207-218.
>
> here are two papers addressing exactly the time-release crypto problem:
>
> M. Kudo, "Distributed Time-Key Cryptosystem By Using Three-Party
> Timestamping Protocol," IBM Research Report, RT5141, 1998.
> http://net55.trl.ibm.com/kudo/Publication/ResRep1/crypto.pdf
>
> Note: I hope the above URL is on the Internet and not our Intranet... also
> I believe Kudo-san and collugues have a follow on paper in which they
> actually claim proactive security but I need to dig this up
> (it appeared in some crypto conf in Singapore very late on 1999, not CCS,
> was it AsiaCrypt?) I'm copying Kudo-san so he can send us (or at least me
> the exact reference...
>
> Conditional Oblivious Transfer and Timed-Release Encryption
> Giovanni Di Crescenzo, Rafail Ostrovsky, and S. Rajagopalan Computer
> Science Department, University of California San Diego,
> http://www.argreenhouse.com/papers/rafail/42.ps
>
> Best Regards,
> Amir Herzberg
> Manager, E-Business and Security Technologies
> IBM Research Lab in Haifa (Tel Aviv Office)
> http://www.hrl.il.ibm.com
> New e-mail: [EMAIL PROTECTED]
> New Lotus notes mail: amir herzberg/haifa/ibm@IBMIL
>
>
> Raph Levien <[EMAIL PROTECTED]> on 08/03/2000 00:09:11
>
> Please respond to Raph Levien <[EMAIL PROTECTED]>
>
> To: "Cryptography" <[EMAIL PROTECTED]>
> cc: "Arrianto Mukti Wibowo" <[EMAIL PROTECTED]> (bcc: Amir
> Herzberg/Haifa/IBM)
> Subject: time dependant
>
>
>
>
> mukti wrote:
> > 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.
>
> The way I'd do this is to split up the encryption key with a shared
> secret scheme, then give the shares to a number of trusted third
> parties, who agree to release the shares at the agreed-upon time and
> no sooner. If they all decide to cheat on their agreement, then you
> lose, although if the fraction over your threshold decide to stay
> honest, then you win even if the rest cheat.
>
> It sounds like there might be a business in this. It's relatively
> straightforward to implement, and there don't seem to be any
> excruciatingly difficult issues of trust and policy, just whether or
> not the trusted third party is going to follow the agreement.
>
> Raph
>
>
>
>
>
>
