22
$\begingroup$

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.

Improve this question
$\endgroup$
5
  • 7
    $\begingroup$ crypto.stackexchange.com/questions/606/… $\endgroup$
    – user991
    Commented Jun 26, 2012 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
    Commented Jun 26, 2012 at 21:14
  • $\begingroup$ at a certain time, eg only on 4th of February or only between 11 and 12 am $\endgroup$
    – bowy tehcTo
    Commented Jun 26, 2012 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
    Commented Jun 26, 2012 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
    Commented Jun 27, 2012 at 15:56

12 Answers 12

Reset to default
13
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\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
    Commented Jun 27, 2012 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
    Commented Jun 27, 2012 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
    Commented Sep 26, 2013 at 15:59
11
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\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.
    Commented Aug 6, 2014 at 12:47
8
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\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
    Commented Mar 15, 2016 at 7:05
  • $\begingroup$ I'm not sure how this can prevent an attacker to fork the public blockchain and then orchestrating in a way to reduce drastically the difficulty. At that point he will still need computational power to mine new blocks but he can for instance reduce time block to 10s or even less reducing the protection of timelock by many orders of magnitude. $\endgroup$
    – Davide C
    Commented Dec 29, 2022 at 14:49
  • $\begingroup$ I believe this analysis is correct. However if you start from the current block, as opposed to the genesis block, then there is no way to escape the current difficulty except in the obvious way, i.e., by expending a sizeable fraction of current mining power to mine blocks with timestamps spoofed so as to engineer a downward difficulty adjustment. This strategy has calculable cost. On the downside, the current block might end up on an orphaned fork if a deep enough reorganization happens, and in that case you would not be able to decrypt the ciphertext cheaply at the timeout. $\endgroup$
    – Alan
    Commented Jan 2, 2023 at 8:59
7
$\begingroup$

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)
Improve this answer
$\endgroup$
4
  • $\begingroup$ How would you embed the time in the multiparty computation without revealing it to the TTP? $\endgroup$
    – dionyziz
    Commented Dec 27, 2013 at 1:30
  • $\begingroup$ @dionyziz Why can't the TPP know the time? $\endgroup$
    – mikeazo
    Commented Dec 27, 2013 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
    Commented Dec 27, 2013 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
    Commented Dec 27, 2013 at 14:23
6
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • 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
    Commented Jun 26, 2012 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
    Commented Jun 26, 2012 at 22:25
5
$\begingroup$

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

Improve this answer
$\endgroup$
0
5
$\begingroup$

Setting aside the issue of nuanced time dependency (if a message can be decrypted at time $t$, how will you forbid anyone from using all the information that was available at time $t$ to decrypt it at time $t+1$?), I'll just mention the idea of a time-lock, which keeps the message secret for a certain amount of time and allows its decryption only after that.

And since this is Cryptography Stack Exchange, I'll also set aside the obvious practical option, which is: m-of-n secret sharing with unambiguous instructions given to highly trusted individuals in (and effectively subject to) highly diverse global jurisdictions.

So, for time-lock encryption specifically, the pseudonymous giant, Gwern, has written a lovely survey that covers the history of the field from 1996 – 2018. It's an excellent starting point if you want to get a broad overview. The only thing it's a bit shy on is trying to find ways to make elegant economic (Ethereum/similar) solutions work — as of 2018 there were no time-lock encryption smart contracts that lacked serious vulnerabilities, though looking at some of the other answers on this question I can see there's been a lot of very recent development there.

If you don't want to read the entire paper, here is a summary/highlights timeline, organized by scheme:

  • 1996: Rivest, Shamir, and Wagner make the first attempt at the problem, proposing a scheme involving repeated squaring (in a finite field) of an encrypted symmetric encryption key to construct a puzzle which provides a quadratic cost advantage for the encryptor over the future decryptors.

    • 1999: Rivest publishes a proof-of-concept time capsule with that repeated-squaring scheme, using an interpretation of Moore's Law to target a decryption window around 2034.

    • 2015: Kuppusamy and Rangasamy publish a refinement of this scheme.

    • 2019: Rivest's time capsule is broken earlier than expected due to advances in algorithmic efficiency, despite Moore's Law failing to meet Rivest's predictions.

  • May 2011: Gwern proposes a scheme using chained hashing, which does not allow the encryptor any advantage in total CPU-time cost, but instead allows the encryptor the advantage of unlimited parallelism while forcing future decryptors to be serialized.

    • 2014: Peter Todd publishes a set of proof-of-concept time capsules based on Gwern's scheme, including small Bitcoin bounties in each.

    • Unfortunately, Todd published them all with the same difficulty factor, which he estimates at a little under a mere 11 days' computation; they are all redeemed by the end of the month, some in as little as 3 days.

  • August 2011: Mahmoody et. al. propose a scheme based on a random oracle (which they admit will probably be "instantiated" with a cryptographic hash function), which, like Gwern's 2011 scheme, offers an advantage only in parallelism. They note their scheme improves on Rivest's by resisting basic attacks from quantum attackers.

    • Amusingly, they claim their scheme is the first attempt at a time-lock encryption scheme since Rivest's.

  • 2013: Gregory Maxwell proposes treating some easily-generated sequence as a sequence of public keys, which are to be jointly "cracked" as part of some distributed project (PoW for a blockchain, for instance); users can then use these public keys as time-lock targets, in the first-of-its-kind scheme to allow the encryptor to hide the message in constant cost relative to the targeted decryption delay.

  • May 19th, 2015: Jager proposes a scheme combining the then- (and still-) experimental "witness encryption" (Garg et. al., 2013) with the existing Bitcoin blockchain as a reference clock, in another scheme with constant cost relative to delay.

    • This paper is later retracted and merged into Liu et. al., 2018, where the use of "SNARKs" is included.

  • May 29th, 2015: Bitansky et. al. propose another constant-cost scheme, this one based on randomized encodings.

    • Amusingly, they also claim that their proposal is really the first attempt at building a time-lock encryption scheme since Rivest's.

  • 2016: Vitalik Buterin reportedly proposed the use of Ethereum or similar blockchain scripting to — in contrast with the witness encryption and distributed cracking schemes — use economic incentives to create trustable 3rd-party encryption key custodians per se.

    • 2018: Gwern publishes refinements, reifications, and criticisms of this idea, ultimately concluding there's no obvious way to make it work due to myriad possible attacks.
Improve this answer
$\endgroup$
0
2
$\begingroup$

You can use drand, which is backed by companies like cloudflare. Here is a demo and web demo

Improve this answer
$\endgroup$
4
1
$\begingroup$

I wonder why SNARKs and computational locks as presented e.g. by Liu, Jager, Kakvi and Warinschi in their paper how to build time-lock encryption haven't been mentioned yet. SNARKs / zk-SNARKs and public blockchains changed alot it seems still much of it's potential is unused when it comes to "hiding things in plain sight".

Improve this answer
$\endgroup$
0
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ You can't know that adversaries haven't kept a cache of the web page. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Mar 23, 2015 at 11:21
0
$\begingroup$

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

http://eprint.iacr.org/2015/478

http://eprint.iacr.org/2015/482

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.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ Thanks, but Please provide a brief synopsis of the content of the links $\endgroup$
    – bowy tehcTo
    Commented May 27, 2015 at 18:59
  • $\begingroup$ The solution described seems to use the Bitcoin network. I fail to understand how it works, and the answer does not help. $\endgroup$
    – fgrieu ♦
    Commented Feb 28 at 17:22
0
$\begingroup$

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

Improve this answer
$\endgroup$

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.