14
$\begingroup$

I want to create a digital time capsule which will remain unreadable for some period of time and then become readable. I do not want to rely on any outside service to, for instance, keep the key secret and then reveal it at the required time. Is this possible? If not, is some kind of proof possible that it is not?

One strategy would be based on projections of future computing capabilities, but that is unreliable and makes assumptions about how many resources would be applied to the task.

$\endgroup$
1
  • 1
    $\begingroup$ If you can ensure the device is not tampered with, you could use (lightly) radioactive components with a known half-life time, so you can grant access only if radioactivity has dropped sufficiently. $\endgroup$
    – Raphael
    Commented Apr 27, 2012 at 7:15

4 Answers 4

5
$\begingroup$

The problem is known as timed-release cryptography. For some references/introduction look at:

Our motivation is the notion of "timed-release crypto", where the goal is to encrypt a message so it cannot be decrypted by anyone, not even the sender, until a pre-determined amount of time has passed. The goal is to "send information into the future" ...

$\endgroup$
2
  • 7
    $\begingroup$ Could you at least summarize the papers? $\endgroup$
    – svick
    Commented Apr 26, 2012 at 22:36
  • 5
    $\begingroup$ The papers make an in-depth study of the two "natural" approaches: either use a trusted third party, or require the receiver to perform a computation which does not parallelize well and takes approximately the right amount of time. $\endgroup$
    – a3nm
    Commented Apr 27, 2012 at 9:02
1
$\begingroup$

I came up with a partial answer, but not strictly speaking an answer to the question as stated. I suspect this may be as close as it's possible to get, but I'm not sure.

First, we encode the capsule with the key required for decryption.

I don't know how to get around having some kind of an authority to hold the key, but it is possible to distribute that function. If we break the key into n pieces, then we can ask n authorities to hold the pieces. Then at the appropriate time would can all publish their pieces to enable reconstruction of the key.

This solution is vulnerable to any one of the n authorities being unavailable, but using m-out-of-n encoding, we can distribute the pieces to n authorities, but only require m to publish their pieces.

Even in this case, some number of authorities with an accurate clock must provide a correct key management service. Is it possible to weaken this assumption beyond the m-out-of-n suggested above?

$\endgroup$
1
$\begingroup$

I think this is a viable approach:

Generate a set of keys using your preferred encryption scheme using a random generated passphrase. The trick here is with the passphrase. The key is known, but we will create a time capsule using the passphrase.

Choose a passphrase such that, if we create a salted hash from it, it will take approx "n" years to calculate the passphrase given known salt and hash using today's computing power. If we want to create a 20 year capsule, estimate our computing power 20 years from now, and create a hash that will be one-month computable by either a user or a supercomputer in 20 years, depending on target for the capsule. Figure, for a 20 year time capsule,that it will be decryptable by a megacorp in 15 years, or a user in 20.

Encrypt data using keys with random passphrase, store the key and the hashed passphrase, and don't store the actual passphrase. Now preserve the data and, at some point in the future, you will hopefully have the computing power to recover your data!

$\endgroup$
0
$\begingroup$

I'm no cryptographer, just an engineer, so my solution is more physical than computational, but let me have a try anyway. I propose the following procedure:

  1. Generate the asymmetric key pair
  2. Encrypt the plaintext message using the public key
  3. Store the private key inside the volatile memory of a microcontroller, and make it output the key only after certain time elapses.
  4. Destroy all other copies of the private key
  5. Bundle the cyphertext and the microcontroller together, and wait.

The obvious question then arises: Why bother with encryption when you could just store the plaintext message in the chip? The answer to this is that this way, the plaintext can be arbitrarily long, without hitting the storage capacity of the chip, because only the fixed-length key is stored there. Also, you can keep a copy of the public key, generating more messages with it later, which are then unlocked at the same time. But that's about it.

To make this even more secure, you could attach a light sensor to the chip and enclose the assembly in a light-proof case (or have a switch attached to the door, or some other tamper detection mechanism), where exposing the sensor to light will trigger key erasure. This is to prevent obtaining the key using invasive methods such as etching. Some chips also have their silicon layers structured in a way to make invasive reading nearly impossible, by putting other essential circuitry above the memory, to obscure the individual bits.

$\endgroup$
3
  • $\begingroup$ If there is an internal clock, someone might speed it up or remove it. By any means it is not good. $\endgroup$
    – Evil
    Commented Nov 25, 2017 at 8:15
  • $\begingroup$ @Evil I thought of this, and it is not an issue really because the chip can be overclocked only so much before becoming unstable, so doing that would risk losing the key. For example, most 8bit AVRs will run up to 20 MHz, can be overclocked to about 25 MHz, but above that the chance of a crash increases significantly. $\endgroup$ Commented Nov 25, 2017 at 11:02
  • 1
    $\begingroup$ You are reinventing tamper-resistant hardware... something that is tricky to do well, especially over long time scales. $\endgroup$
    – D.W.
    Commented Nov 25, 2017 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.