I'm not sure if what I'm asking is even a valid question but here goes.

Would it be possible to add a mechanism to an encryption algorithm that would mean it had to be a certain time of the day or a certain day of the year for the encryption to be able to be decrypted.

To Clarify, It should only be decryptable at a certain time eg

  • 4th February or
  • 11.23 am
  • or between 1 and 2 pm

working in a similar way to a time clock on a bank safe.

Obviously this would require encrypted access to an internet timeserver to ensure an unspoofed time signal.

  1. Does this make an sense?
  2. Would it be possible?
  3. What would the mechanism be?

I asked this on stackexchange.com but this seems a better place.

  • 7
    $\begingroup$ crypto.stackexchange.com/questions/606/… $\endgroup$ – user991 Jun 26 '12 at 20:53
  • 1
    $\begingroup$ Please clarify: Are you asking for it to be decrypted "at a certain time" or "in a certain amount of time"? Ricky's link addresses the latter. $\endgroup$ – B-Con Jun 26 '12 at 21:14
  • $\begingroup$ at a certain time, eg only on 4th of February or only between 11 and 12 am $\endgroup$ – bowy tehcTo Jun 26 '12 at 21:27
  • 1
    $\begingroup$ @RickyDemer that question is asking something different a bit like a count down, what I'm asking is like a bank Time lock. $\endgroup$ – bowy tehcTo Jun 26 '12 at 21:28
  • 5
    $\begingroup$ The best solution is probably to use a piece of secure, tamper-proof, hardware with a built-in clock. The key to decrypt the data would be encrypted with a key known to the secure device, and the secure device would accept signed instructions specifying that it only decrypt particular things at particular times. (KEYLOK Fortress, for example.) $\endgroup$ – David Schwartz Jun 27 '12 at 15:56

Rabin and Thorpe wrote a technical report on this topic here: "Time-Lapse Cryptography"

There are a number of relevant citations there as well. There's also a poster of a prototype they built: http://www.eecs.harvard.edu/~cat/papers/tlc-poster.pdf.

  • $\begingroup$ +1 for TLC. It is more geared towards decryption after a certain period of time, but could probaby be modified to meet the OPs requirements. You would know best though if that is true. $\endgroup$ – mikeazo Jun 27 '12 at 11:45
  • $\begingroup$ This is interesting its says time lapse but not in the same way as the question quotes in comments above, this is closer to what I was interested in. $\endgroup$ – bowy tehcTo Jun 27 '12 at 11:54
  • $\begingroup$ That is really cool. I take it that elliptic curve cryptography can be used in place of El Gamal throughout. (Though I don't fully grok the VSS mechanism, so I'm not certain that that carries over, but I think it does.) $\endgroup$ – Jeffrey Goldberg Sep 26 '13 at 15:59

Cryptographic algorithms are not time-aware, so you require a time-aware third-party to accomplish this. The third-party also needs access to a secure time source (like an on-site atomic clock or a secure connection to an offshore one)

The precise implementation and protocol depends on your usecase, but as an example you could have a server that does two things:

  • accepts inputs that include a message to timelock and a "release date"
  • allows requests to obtain the message only once the message's release date is passed

For the first case, the server would generate a random symmetric key of sufficient length, encrypt the message with it, hash the encrypted message and add the key + the hash + the release date in some database. The server then returns the hash that serves as an identifier for the message that was just timelocked. It can also return the encrypted message, if needed (presumably, the entity submitting the message destroys his plaintext copy after as he is the one wishing to timelock it).

Then, in the second case, the client sends the identifier to the server. The server looks it up, and checks the release date. If it isn't passed yet, the server denies and bails, however if it is, the server simply returns the correct encryption key (and the plaintext message if desired).

That's just one example of a very basic timelock service (you can elaborate by using public-key crypto to enhance various aspects of the service, for instance).

Your question is quite broad, perhaps you should add more detail.

  • $\begingroup$ This basically boils down to the server keeping the time and only returning the key based on its (hopefully correct) time. You are right that this can be made more elaborate with proxy re-encryption to fix the key escrow problem (assuming the server only stores the encrypted data and never has knowledge of the plaintext). $\endgroup$ – Artjom B. Aug 6 '14 at 12:47

A theoretical solution for cryptographic timelocking which if I am not mistaken was proposed by Andrew Miller, is to combine Witness Encryption (link) with the Bitcoin block chain. Witness encryption allows you to encrypt information such that users will only be able to decrypt it if they have access to information that satisfies certain properties. In the context of timelock encryption, the required information is a block chain of certain length. Since new blocks arrive on average every 10 minutes, you can specify the time after which decryption is allowed roughly up to 10 minutes. The attacker could theoretically produce an alternate block chain of the necessary length before the deadline, but if he is in possession of this computational power he might as well put it to use getting rich mining Bitcoins.

  • $\begingroup$ This is interesting. In a physical world analogy, the key is being placed in a radioactive vault that decays, hence break down by itself. Only after a certain amount of time passed, the vault opens up by itself due to decay. $\endgroup$ – adib Mar 15 '16 at 7:05

I am not aware of any exact solutions to what you are looking for. That said, one design came to mind. Like others have suggested would be necessary, this protocol requires a trusted third party.

The idea is to use multi-party computation. There will be three parties, a sender, a receiver, and a trusted third party. The sender encrypts a message and sends it to the receiver. The sender then uses secret sharing to split the key between the receiver and the trusted third party. The trusted third party also gets a representation of when the message can be decrypted.

For decryption, the receiver contacts the trusted third party and the two of them use multi-party computation to generate the decryption. The multi-party computation can have imbedded into it the current time value and the representation of when the message can be decrypted.

There are a few benefits of this approach are:

  1. The receiver will already have the encrypted message (TTP doesn't have to store it)
  2. The actual decryption key is never released to anyone (so the receiver can't leak it, and if TTP is hacked, it won't be leaked)
  3. The decryption time could be kept private (possibly even from the TTP)
  • $\begingroup$ How would you embed the time in the multiparty computation without revealing it to the TTP? $\endgroup$ – dionyziz Dec 27 '13 at 1:30
  • $\begingroup$ @dionyziz Why can't the TPP know the time? $\endgroup$ – mikeazo Dec 27 '13 at 1:37
  • $\begingroup$ I'm referring to point #3 that you mentioned. I have no problem with TTP knowing the time; but it seems awkward that it's possible that they won't. $\endgroup$ – dionyziz Dec 27 '13 at 5:13
  • $\begingroup$ @dionyziz, the decryption time could be secret shared at the sender with the receiver and the trusted third party. That way neither knows when decryption is allowed. Then the MPC decryption circuit would check decryption time against the current time and decrypt if it is later than the decryption time. If it is not later than that time, the MPC could output garbage. Then the TTP has no idea if decryption was successful or not. As to when this might be useful, that will depend on the application. $\endgroup$ – mikeazo Dec 27 '13 at 14:23

The basic principle of encryption (Kerchoff's principle) is that the only thing necessary to decrypt data is the key. So really your question is, is "How can I make the full key available only during a certain time?" The two obvious answers are to either a) Only reveal the key during that time, or b) make the key depend on data only knowable during that time.

Regardless, there is a caveat: Once the key is known, the game is over. The person using the system can always cheat and they might obtain the key during the alloted time period and then use it to decrypt data later. So there's really no point in putting a final time limit on the time, you would need to start over with a new ciphertext/key pair and impose a new time limit.

Option (a) above is kind of self explanatory: Publish the key when you're ready to allow people to decrypt the data. This is easier said than done, but setting up a client/server model to release information at the timing of the server is relatively straight forward. Option (b) would allow for an automated approach that doesn't require you to manually intervene, and it would allow you to not know the encryption key either. But how are you to know something about the future that someone else couldn't know? In security, we tend to assume that anything publicly available is instantly known to everyone for forever, since it's silly to base security on hoping that public information was never learned by the adversary. So unfortunately, this isn't really an option.

A solution besides (a) would need to step outside the bounds of traditional cryptography. For example, you would need a dedicated platform (software or hardware) that you can assume is unbreakable that will only perform a decryption operation at a certain time.

But you can't just hand someone bits that are undecryptable before some arbitrary time. Time is a human concept, electronic bits don't care about what our clocks say. The closest concept they have to time is how long it takes to compute one set of bits from another set of bits, which touches on the "time capsule" idea that Ricky linked to. Imposing a human sense of time on them will require a system with human intervention.

  • 1
    $\begingroup$ The "point in putting a final time limit on the time" is that the data should be hidden from one who gets $\hspace{0.4 in}$ access to an honestly used system after the final time limit has expired. $\:$ $\endgroup$ – user991 Jun 26 '12 at 22:16
  • $\begingroup$ The realm of trust extends to every party who receives the key. Anyone could distribute it, intentionally or not, after the fact. Since the attacker already knew the ciphertext, you have to rely on the security and integrity of all the clients. So it's possible to exclude new clients who arrive too late from decrypting the data, but only if you trust every client who successfully obtained the key properly. And you withheld the keys from the clients in the beginning for a reason, it sounds like they may have incentive to cheat. $\endgroup$ – B-Con Jun 26 '12 at 22:25

This answer comes a bit late, but…

Yes, it possible to make a time-locked encryption algorithm.

One of many places to dive a bit deeper into time-locked crypto would be the "publications" page of Ronald L. Rivest's website where you will find:

“Time-lock puzzles and timed-release Crypto”
by Ronald L. Rivest, Adi Shamir, and David A. Wagner.
(This has appeared as LCS technical memo MIT/LCS/TR-684 (February 1996).)
Version of 3/10/96.

The paper — which is available for (free) download in postscript and pdf — discusses "time-release crypto" and possible implementation options.

Also, on that same publications page, you can find:

“The LCS35 Time Capsule Crypto-Puzzle (description, java code, and puzzle parameters)”
by Ronald L. Rivest

Where “Description of the LCS35 Time Capsule Crypto-Puzzle” by Ronald L. Rivest (April 4, 1999) is available in text format. As the paper also includes Java sourcecode examples, it'll practically provide you with one of many examples of time-locked crypto.

Also interesting is this 2013 paper (PDF):

“Revocable quantum timed-release encryption”
by Dominique Unruh


The theoretical solution based on witness encryption is described in these papers:



The basic idea was apparently discovered independently in these two works. The first paper is more formal, it contains a formal security model and a rigorous security analysis. The second one is very informal, but also describes a new witness encryption scheme.

  • 2
    $\begingroup$ Thanks, but Please provide a brief synopsis of the content of the links $\endgroup$ – bowy tehcTo May 27 '15 at 18:59

I use an ordinary AES 256 encryption. On top of this I put a layer of words generated by the content of a webpage by your choice. The moment the webpage is updated, it wont be possible to decrypt. Of course you might be able to access a cached copy of the page. But as a practical approach to the problem, this is useful.

  • $\begingroup$ You can't know that adversaries haven't kept a cache of the web page. $\endgroup$ – Gilles 'SO- stop being evil' Mar 23 '15 at 11:21

option number 1: you allow decryption by releasing the key at some point in the future

option number 2: you know about some future event and you tell people to look for that event to occur, get some information associate with it and generate the key based on that. If such event is caused by you then that's option number 1 above, otherwise you are relying on an external trusted "third-party" agent which release the event

option number 3: you release only part of the key, the rest is destroyed. This forces the receiver to perform a brute force attack to decode the cypher text. This method doesn't guarantee decryption at an exact point in the future but it rather enforces an "at least not before" policy over the data


Your Answer

