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
