189

Does there exist any cryptographic algorithm which encrypts data in such a way that it can only be decrypted after a certain period of time?

The only idea that I can think of, is something like this: Seed a PRNG with a public value. Run the PRNG for a week and use the final value it produces to encrypt the message. Now anyone who runs that PRNG for a week starting from the seed value you made public can decrypt the message. Obviously this breaks down since they could use more computational power than you; if the time span was years then Moore's Law would apply, etc.

Is there anything like this other than physically burying a private key on a USB stick in a literal time capsule?

Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 17
    Use the headline from the front page of the New York Times, dated Sept-1-2015 as your encryption key. Your data will remain safe until then.</> For the rest of us - Nick's answer is a good one. =) –  Jun 23 '11 at 05:47
  • 2
    Butterflies aside, that would be a good way to prove your time travel machine works. :P –  Jun 24 '11 at 16:58
  • 1
    If you had to enter the key into a black box and it was programmed to function as a time lock, then it could wait to decrypt until the time is reached, but no algorithm will do this on its own. –  Oct 22 '11 at 00:46
  • 2
    And any "black box" could be reverse engineered. –  Oct 22 '11 at 00:51
  • 15
    If I've learned anything from a multitude of Sci-Fi and fantasy books and movies, it's that if you want to hide something for a long period of time, all you need is an extremely accurate model of the movement of astronomical bodies. Work out when the planets will align just so, and have your message only appear when the light of the moon enters a secret chamber at exactly the right angle, through a gem on a stick of the right height placed in a groove in the floor. – Jeffrey Kemp Jun 09 '14 at 05:46
  • 1
    Yes! You can use a service like futureme.org to send the key to a desired address sometime in the future. No one needs to know where they are getting the key from. – pablosaraiva May 12 '15 at 19:46
  • Compared to the answer above, a more practical way would be to use the Disclaimer-based cryptosystem of Rawat and Saxena. This is more secure too. ;-) – Jus12 Sep 18 '15 at 07:00
  • Set up a relay on alpha centauri and transmit the key to it. Absolutely guaranteed 8 year delay until the key is available. – ddyer Oct 22 '11 at 21:51
  • But couldn't there side-channel attacks (like someone intercepting the data on the way)? – Paŭlo Ebermann Oct 22 '11 at 22:08
  • use public key encryption to communicate with your relay site :) – ddyer Dec 23 '11 at 21:29
  • And minor issues in generating the required parameters (eg: the mirror "on" alpha centauri) – Cryptographeur Feb 04 '14 at 09:16
  • You made the assumption that information cannot be transmitter faster than light, right? – Helium Apr 27 '14 at 12:55
  • More practical: set up a relay on the moon, encrypt the message with 2^27 keys, each time it hits the relay, it decrypts one more. It will take 11 years for the message to decrypt. – archaephyrryx Jan 16 '15 at 22:50
  • @archaephyrryx Somebody could pick up one of the relays and move it closer to the other relay in order to speed up the process. – kasperd May 12 '15 at 21:45
  • @Jeffrey Kemp Alternatively: use Moon-Runes. Birds are optional, but recommended. – archaephyrryx Sep 07 '16 at 16:28
  • 1
    You may be interested in the section "Bitcoin as a Clock" here – user2460798 Jun 08 '17 at 21:34
  • Assuming you could somehow jigger an API for time (or whatever your trigger may be) into Ethereum, here's an idea: give your capsule-data to an Executor. The Executor is then made aware of a generously-funded Ethereum contract which will **yield a fixed, small portion (or amount) of its fund—then expire—to one presenting the capsule-data* prematurely; but, after being "primed" by the Trigger event, will then yield all its funding** to one presenting the capsule-data. (*the capsule-data itself wouldn't be in the contract—a hash of it would be baked-in for verification) – JamesTheAwesomeDude Mar 20 '20 at 06:24
  • Expanding on the previous comment: I'm sure someone here is clever enough to come up with a way to fragment the Executor into n (or even n-of-m) parties, which may not even be given a way to contact each other: driving the "trust" requirement even further down, and making it even harder for an adversary to find, then coax the secret out of enough Executors prematurely. – JamesTheAwesomeDude Mar 20 '20 at 06:29
  • ⸺reading through that linked Gwern article, though, it looks like I've been scooped by several years on the smart contract-based secret sharing (the section immediately after the mentioned one); though I want to also point out that it looks like their cryptographic-blackbox program interpreting BTC Blockchain as a “clock” is the closest thing to a canonical solution to OP's query we can reasonably expect, aside from Rivest's squaring trick (which has its own shortcomings). – JamesTheAwesomeDude Mar 20 '20 at 07:07
  • Thanks, I see that the main solutions rely on computational efforts spent to solve problems specifically designed for this purpose or on third parties, as I kind of expected. I have found right now this work that starts from the idea of using a public source of infromation as Bitcoin instead. – Lorenzo May 13 '20 at 23:26
  • What if it takes a different amount of time for different computers? – Maf May 15 '20 at 12:26

23 Answers23

96

Yes.

There has been a lot of work on "proof of work" protocols or "time-lock puzzles." Typically in cryptography, functions are either easy to compute or intractable. These protocols look at functions that are moderately hard to compute.

To do time-release encryption, you need a puzzle with the following properties:

  1. Difficulty of the puzzle can be monotonically increased according to some difficulty parameter
  2. Best algorithm to solve it is intrinsically sequential (parallel computing doesn't help)
  3. Amortized cost of solving a group of puzzles is the same as a single puzzle
  4. There is a trapdoor (shortcut) that allows efficient evaluation of the puzzle

With time-release crypto, the idea is to generate a puzzle that will take a certain amount of time to solve based on an estimate of a person's computational power and how it will grow in the future (e.g., Moore's law). As you can tell, it only gives you a fuzzy indication of how long it will stay secret (see below for a real world example). Property 2 is very important because adding parallel computation is easy and it is hard to estimate how much parallelization is possible.

Note that most proof of work protocols do not care about property 2 because they are used in different ways. These might be based on finding partial collisions/preimages in hash functions or exhaustive search of a small space (e.g., bitcoin), however speedups with parallel computing is trivial in these examples. There are also a number of memory-based puzzles that require lots (more than can be cached) of memory accesses, which is a more predictable measure of time on computers.

Back to time-release crypto. The idea is to instantiate a puzzle $p$ with difficulty $d$: $p=\mathsf{Puzzle}(d)$. A trapdoor $t$ for efficiently solving it is known to the person who generates the puzzle. This person then encrypts her message under key $k$ with a normal encryption function: $c_1=\mathsf{Enc}_k(m)$. She then release an "encryption" of the key she used by combining the key with the solution to the puzzle. Note that she can efficiently solve the puzzle with trapdoor $t$ but the recipient can't. She computes: $c_2=k \oplus \mathsf{Solve}_t(p)$. The ciphertext is $c_1,c_2$ plus a description of the puzzle.

To decrypt, the recipient computes $s=\mathsf{Solve}(p)$, which should take a moderate amount of time. He then recovers the key by $k=c_2\oplus s$, and can then decrypt $c_1$.

The disadvantage to time-release cryptography is that the recipient must devote an entire processor to solving the problem for the period of time that it should remain secret.

The best proposal for a Puzzle with the right properties is due to Rivest, Shamir and Wagner in this paper. It is based on repeated squaring in RSA groups. A recent result precludes any intrinsically sequential time-lock puzzles in the random oracle model (e.g., based on hashing).

In 1999, Rivest created a time capsule message to commemorate the 35th anniversary of MIT's Laboratory for Computer Science. He talks about how he designed it to require 35 years to decrypt. It is an interesting read.

PulpSpy
  • 8,617
  • 1
  • 30
  • 46
  • 15
    Interesting. The problem is, of course, that it doesn't guarantee that anyone will decrypt whatever the secret is, only that they could given a certain amount of time. If what you want is for your secret to become public, you might not want to risk nobody trying to break it. Doing it yourself is a non-answer for a couple of reasons. – Steve Dispensa Sep 03 '11 at 17:08
  • 8
    Requiring a certain amount of computation isn't the same as requiring a certain amount of time to pass, though. – Nick Johnson Sep 04 '11 at 13:04
  • The downside of having a time capsule that you don't want opened until 20 years from now: is that you must spend 18 years encrypting the puzzle. Considering Moore's law it will then take 2 years for the public to decrypt it. Total: 20 years. – Ian Boyd May 12 '12 at 19:17
  • 9
    @IanBoyd The puzzle can be efficiently created. It's solving it that's difficult. – Thomas Dec 27 '12 at 13:37
  • 5
    Problem with "Time Lock Puzzles" is that only the NUMBER of sequential operations to solve them can be controlled. However the TIME for each operation is not well controlled. There can be a factor of perhaps 100 between what software and dedicated hardware achieve. How good is a timer programmed for 15 years that could be over in 2 month? And for such long delays, how reasonable is it to dedicate a powerful CPU core to this for years? For techniques applicable to reality, see this – fgrieu Jan 03 '14 at 06:49
  • 4
    Point 3 is very interesting, but you didn't mention it again in the rest of the text. If I understand correctly, with that property, a single third party could solve many such time capsule problems for the same as solving a single. That would mostly eliminate the problem of the puzzle being too difficult to solve for anyone to bother. Is there anything that actually fulfills that property? – Hjulle Nov 13 '15 at 14:58
  • To add to your mention of Bitcoin and proof of work, block confirmation times on the Ethereum blockchain are fairly consistent. There are programs called contracts that are written on Ethereum blockchain that leverage the fact that n blocks are confirmed within time t. Check out https://github.com/dmozzy/TimeClock –  Aug 07 '17 at 13:23
  • 1
    @CryptoCat You can't use a blockchain compute method to ensure that a message is not decrypted before a given date. The smart contract you linked to uses the blockchain consensus to ensure that the payment can only be sent at a given time, but if it's a secret you're after, one can simply run the decryption routine early on a forked blockchain since no network consensus is required to run the program early. – March Ho Jun 24 '18 at 01:50
47

No.

See the following. http://www.gwern.net/Self-decrypting%20files

It has a decent list of ways you might try to do it. However, there is no guarantee that the desired amount of time would actually elapse until the "lock" was broken. In other words, significantly more or significantly less time might be required.

Now, some MIT guys did something in '99 that they hope will be opened in 2034. however, again, they do leave open the possibility that it could be broken earlier.. or not in anywhere near the amount of time they estimate.

http://people.csail.mit.edu/rivest/lcs35-puzzle-description.txt

Most of the ways available depend on needing to run an operation on a computer that will take a certain amount of time before the final decryption key can be obtained. However, you have no control over hardware. Ergo, you have no real control over the amount of time that would elapse before the final decryption key is acquired.

The MIT guys did mention that they took "Moore's Law" into account. However, most people would argue that Moore's Law has very little to do with overall processing performance. The law was about the doubling of transistor counts every two years; however processor performance has very much outstripped that.

The info on this site says pretty much the same thing: http://dl.acm.org/citation.cfm?id=888615

The secondary way is to give the key to a trusted third party who will only reveal it at a certain point in time. However, this is just as tricky because they may be forced using any number of mechanisms to release it earlier or they may even lose it somewhere along the way.

So, the answer is that there is no implementation accepted by anyone as "secure". There can't be.

Sauce McBoss
  • 103
  • 3
NotMe
  • 570
  • 4
  • 5
  • 8
    I suspect most things encrypted with a scheme such as this will be opened late or never, because nobody is prepared to put that much effort into opening it (eg, nobody cares). – Nick Johnson Oct 24 '11 at 04:52
26

Going with the theme of out-of-the-box solutions started by e501, I do recall at least a half-serious suggestion that, with a retransmitter (or just a big mirror) placed in outer space at a suitable distance from Earth, one could use light-speed lag as an effective time capsule mechanism — just encode the message as a laser pulse and send it out for a round trip of as many light years as you want to delay it by in years.

In principle, you could also do this just by bouncing the light off naturally occurring objects in space, like planets or stars or nebulae. However, the transmission losses involved in this would probably make it infeasible without extremely powerful transmitters and sensitive receivers, to the point where it's not at all clear whether it would actually be any more practical than just launching a huge retroreflector out into space. Also, the brighter the outgoing pulse is, the bigger the risk that scattering from gas and dust along the way might provide a side-channel attack.

Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 7
    Finally a solution involving uncheatable physical time – Tobias Kienzler Aug 13 '12 at 13:09
  • 2
    There may be less secure but more practical ways, e.g. sending a small, hard to detect satellite into orbit around the sun and wait for its small antenna to get back into range. – Maarten Bodewes Sep 18 '13 at 15:56
  • Isn't that going to be equivalent with a radar where the energy requirement goes up with the fourth power of the distance? – kasperd May 12 '15 at 21:50
  • @kasperd: An active retransmitter would cut that down to the square of the distance. And, of course, the scaling law only starts to apply at distances where the beam width exceeds the size of the receiver / reflector, so the bigger you can make the reflector, and the better you can collimate the beam, the further you can reach with the same energy. – Ilmari Karonen May 12 '15 at 23:21
  • But setting up an active retransmitter would take longer time than the desired delay, if it even would be feasible in the first place. – kasperd May 13 '15 at 06:35
  • 2
    @kasperd: Sure, but it's a one-time setup cost. You launch the reflector / retransmitter well in advance, so that you can use it later when it's far enough. I never said this was a practical solution right now (if ever). Although, if you only need a delay of a few seconds, there's a convenient reflector already on the Moon. And we do technically have an active retransmitter at about 17 light hours away, even if contacting it discreetly may be tricky. ;-) – Ilmari Karonen May 13 '15 at 10:42
  • You could install hardware on the Moon which would accept a transmitted light signal, perform some cryptographic 'ratcheting', send it back to Earth where you need to apply your own key to ratchet it further, back to the Moon again and so on. Apply n layers for n * 2.51 seconds of delay. The hardware on the Moon will be too costly to go and adjust or reverse-engineer for most purposes. – Myridium Jun 08 '20 at 04:33
23

No.

With neither a trusted third party nor trusted hardware, we know no system with an even mildly accurate delay of release.

If we accept a trusted third party, there are options. For example:
The trusted third party generates a public/private key pair per hour (for an asymmetric cipher such as RSA-OAEP), publish the public $Pub_t$ keys in advance (signed with the long-term public key of the third party), and publish a regularly updated list of all the past private keys $Priv_t$.
To time-lock some information $P$ until $t$: fetch $Pub_t$, and its signature, from the trusted third party; check the signature; draw a random key $K$ for a symmetric cipher such as AES-CTR; encipher $K$ using key $Pub_t$ giving $KT$; encipher $P$ using key $K$ giving $C$; forget $K$ and $P$; publish the time-locked information $KT||C$.
When time $t$ has come, anyone can fetch $Priv_t$ from the trusted third party; decipher $KT$ using key $Priv_t$ giving $K$; decipher $C$ using key $K$ giving $P$.
In a variant, the trusted third party generates deterministically the $Pub_t$/$Priv_t$ pairs from a master key and $t$; this allows arbitrary precision for $t$ with constant storage.

Trusted hardware with a trusted real-time clock (e.g. some HSM) can be used to implement the time lock (or to implement the above trusted third party).

With trusted hardware lacking a trusted real-time clock (e.g. a Smart Card), the clock can be delegated to a trusted third party. I believe (never done it) that buying a certificate from a certification authority also buys a free service, which answers unauthenticated queries "is this certificate still valid?" with a signed answer "this certificate was still valid at time $t$", which the trusted hardware can check (against the trusted third party's long term public key) to determine that the current time is at least $t$ (on the trusted third party's clock), regardless of how this signed answer has reached the trusted hardware.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
20

Yes. The following paper looks at the question you asked about:

That paper describes how to encrypt a message $M$, so that decrypting $M$ requires a controlled amount of computation (say, $T$ CPU cycles).


Here is the gist of the main scheme. To encrypt, Alice chooses large primes $p,q$ and computes a RSA modulus $n=pq$. Alice also picks an integer $t$ large enough that performing $t$ modular squarings (modulo $n$) will take the decryptor about $T$ CPU cycles. Alice then picks a random value $a$ and computes $b = a^{2^t} \bmod n$; she then uses $b$ as a secret key to encrypt her message (e.g., with AES).

Alice gives the RSA modulus $n$ to the decryptor, and the number $t$. The decryptor can recompute $b$ by squaring $a$, repeatedly squaring $t$ times (modulo $n$ each time). Thus, it will take the decryptor about $T$ CPU cycles to decrypt.

In contrast, Alice can encrypt using much less than $T$ CPU cycles, using the following trick. Alice computes $e = 2^t \bmod \varphi(n)$. Here $\varphi(n) = (p-1)(q-1)$, so Alice can compute $\varphi(n)$, but no one else can. Moreover, Alice can compute $e$ using $2 \log t$ squarings and multiplications modulo $\varphi(n)$, which takes vastly less than $T$ CPU cycles. Alice then encrypts using $b = a^e \bmod n$. Thus, Alice can encrypt much more efficiently than the recipient can decrypt.

To put it another way, Alice can create a puzzle whose difficulty she can control very precisely. The only way to decrypt is to solve the puzzle. For instance, she can arrange that it will probably take about 20 years to decrypt. Moreover, creating the puzzle is much quicker than solving it (she can create the puzzle in seconds, even though it will take decades to solve it). This provides a way to send a message that can only be decrypted after performing a certain amount of computation, i.e., after a certain amount of time.

The paper also describes another way to solve the problem, if one has a trusted agent (perhaps implemented using TCG, or perhaps considered trustworthy for other reasons).

D.W.
  • 36,365
  • 13
  • 102
  • 187
16

Because there's no inherent sense of time for a computer, there's not really any way to accomplish this. The best you could do would be to require a lot of computation and try to make it have to be as serial as possible. But even if there's a good way to do that, faster computers could do it more quickly.

If you want something to stay encrypted for a fixed amount of time, your best bet would be to encrypt it using any standard scheme and lock the key or keys in a time-lock safe.

Keith Irwin
  • 261
  • 2
  • 4
11

I'm thinking some sort of Ironkey like device, where the crypto and clock are internal to the device and encapsulated in such a way that if they are physically tampered with, the chip (and the key) self-destructs.

Joe
  • 111
  • 1
  • 2
10

There is such a kind of primitive in the article about timed commitments from Boneh and Naor. This is a kind of encryption scheme where decryption can be forced, but at a heavy non parallelizable cost, and such that it can be proven in advance, at low cost, that forced decryption will work. It relies on repeated squarings modulo a RSA modulus.

Thomas Pornin
  • 86,974
  • 16
  • 242
  • 314
  • The problem with all of these schemes is that someone has to do it. If you tune the work to match your guess at your primary adversary's compute power, and you guess that your adversary has many times your compute power, then you guarantee that nobody but your adversary or someone with more resources than he will be able to decrypt your secret. If you want two things -- 1) it becomes public after time T 2) it becomes public not long after T -- then this system doesn't get you there. You can't do it yourself, and your adversary might decide not to do it. – Steve Dispensa Sep 03 '11 at 20:25
10

InfoBiology by printed arrays of microorganism colonies for timed and on-demand release of messages is a recently development method that leverages biological systems to create messages that impose a limit on the amount of time it takes to learn a message.

The idea is simply to encode a message in a pattern of e. coli colonies. The message is released after the e. coli colonies have been growing in a particular growth medium for a certain period of time (the phenotypic expression of the e. coli is designed to have a particular lag time).

Ethan Heilman
  • 2,276
  • 1
  • 20
  • 40
  • 9
    Your link doesn't work for me, but I did find this news article from Nature. However, this is really just clever steganography; even if the normal way of revealing the message might include a time delay, there's no fundamental reason why someone with the right technology and resources couldn't do it faster by, say, sequencing the DNA of the bacteria directly. – Ilmari Karonen Sep 28 '11 at 16:31
  • 2
    @IlmariKaronen - Thanks, updated the link. I agree completely, an attacker could run a sequencing side-channel attack against the message. I said the same thing here: http://the-scientist.com/2011/09/26/encrypting-e-coli/ . Most security systems are built around models of what an attacker can do. For example AES can be broken by a timing side-channel, but that doesn't mean AES is no longer secure. Furthermore there are some pretty powerful countermeasures that could be used prevent to a sequencing side-channel attack. – Ethan Heilman Sep 28 '11 at 16:57
7

Since there's no way to control your execution environment, there's no way to ensure your algorithm is executed as described, with the actual current time. Thus, the only way to ensure something like this is to make it computationally difficult to decrypt, which is a limit on the amount of computational effort spent, not on the amount of real time spent. The easiest way to do this would be to encrypt the data with a short private key, and require people to factor the public key in order to unlock it.

Nick Johnson
  • 273
  • 1
  • 4
  • 3
    Maybe clinging to an ongoing factoring effort could be useful - e.g. if you know that some project works on factoring some large composite number, use this number as part of your RSA public key to encrypt your message. (Of course, this might not work at all if the number in question has more prime factors than RSA allows - and if it is a number created by someone, this someone might already know the factors.) – Paŭlo Ebermann Sep 03 '11 at 12:43
  • 1
    Requiring people to factor the public key is not a good basis for a solution, because factoring a public key is a task that can be parallelized, and thus the computation needed to factor cannot be easily related to passage of time. You want an inherently sequential problem. See my answer for one solution. – D.W. Sep 04 '11 at 04:46
7

Check out "Time-Lapse Cryptography". Seems like a pretty good system. I doubt the infrastructure is currently in place to support it, but you never know what the authors have out there.

mikeazo
  • 38,563
  • 8
  • 112
  • 180
6

I would try an aproach with a web service. Once you own the server you can rely on the date it has. You crypto information should contain a date that the server validates an once this is reach you can provide real decryt key for user.

  • That's no different, technically speaking*, from a non-cryptographic dead-man's switch. In fact, it's strictly less safe: now you've got to keep the server and the encrypted data maintained. *Emitting a 40KiB message is pretty much the same technical "feat" as emitting a 4KiB key. And you've still got to have that 4KiB key (which is now tantamount to the plaintext of the—presumably publicized—ciphertext edition of the message) unencrypted, so you're at exactly as much risk of your adversary hunting down the server-with-a-key as you are of him hunting down the server-with-a-message. – JamesTheAwesomeDude Mar 20 '20 at 06:10
5

Quoting Rivest et al:

There are 2 natural approaches to implementing timed-release crypto:

  • Use "time-lock puzzles" - computational problems that can not be solved without running a computer continuously for at least a certain amount of time.
  • Use trusted agents who promise not to reveal certain information until a specified date.

So far, so good. Yet, it leaves the question if there's a cryptographic scheme that practically does the job.

Here are some interesting papers and slides on the subject, that haven't been mentioned yet:

And — for what it's worth — there are also related discussions at Redit and at Hacker News too.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
4

How about basing this on radioactive decay?

  • You print the message on a film
  • Encapsulate the film in some tamper-proof (or highly tamper-resistant) enclosure
  • There is only one way to retrieve the film from the enclosure and in that path, put some radioactive material so that you can not retrieve the film without exposing the film to the radiation
  • If one tries to retrieve the film before radioactive material has decayed, the film will be exposed blank by the radiation. After radioactive material has decayed, film can be retrieved safely.
  • Tamper-proof enclosure also prevents removal of radioactive material without damaging the film
  • (Several Challenges in enclosure design of course :-(
user14920
  • 41
  • 1
  • Simply take a lead container large enough to fit the enclosure; take lead container into space, put enclosure into container, exit space with container. – robbat2 Jun 09 '14 at 06:23
  • @Robbat2 that would be a denial of service attack - it would prevent legitimate users from seeing message, but it doesn't affect the privacy of the message, prior to the date the message is due to be revealed. – user2460798 Jun 08 '17 at 21:32
3

You might want to look at "The Burris Numerical System" there is a very good book on it. This numerical system encrypts data in theory in time with only the last number remaining in space. The rest of the number is in theory stored in time. The book is on Amazon and other places. This is the best I have found for using time to encrypt data.

  • 2
    I read the book's description and it certainly seems interesting. Could you please add a few examples? – rath May 04 '14 at 09:51
  • 2
    I'm assuming you wrote the book. Is that correct? – mikeazo May 04 '14 at 12:02
  • 4
    @mikeazo well that was a detail I overlooked. Lloyd if you are affiliated with a commercial product (including any books you've (co)authored) you recommend, it's a very good idea (read: near-mandatory) to disclose your affiliation in the body of the answer on SE sites. – rath May 04 '14 at 20:23
3

Of all these systems, the only method that is time-proven, practical, and at least theoretically reliable, is to use a multi-part key, and distribute that key to separate [people, places] with the information necessary to put them together only available at a certain date.

It is still possible to find repositories that are immune from subpoena, with timed contracts or to be opened only posthumously. Even the government does not have lawful or Constitutional authority to breach attorney-client privilege, for example.

If secrecy is more important than reliability, then distribute your information among several attorney-client agreements. If reliability is more important than secrecy, then distribute all the information among several attorney-client agreements.

Always keep in mind that PEOPLE are the vastly more frequent (but not always) the point of failure. Even so, trying to take people out of the equation -- today -- has little probability of success.

3

How about encoding the data into a laser beam and shooting it out into space in a direction that would have it curve back towards a detector on earth/orbit/moon in 20 years? Kinda like how we know to expect Halley's comet to come around every 75 or so years.

I guess the fundamental here is that astral bodies don't change behavior unexpectedly (or, at least, they are sufficiently dependable), and also that the speed of light is constant in (normal, empty) space. If faster-than-light travel is achieved within the time-frame of your time capsule opening, well.. i guess you'll have bigger things to worry about than your time-encryption being broken.

user76034
  • 31
  • 2
3

Two big problem with the "it will take a computer 20 years to crack it" idea

  1. It will only take 2 years for 10 computers to crack it

  2. brute force cracking is a random process, so it could be cracked almost instantly, at very low admittedly, but not quite zero , probability.

Oh I suppose you could encode using a really really large key .The brute force crack techqnique might then have the expected crack time of 200 years. But the key is calculable, using a process that must be linearly done, so that no parallism is allowed, and it will take 20 years at 20 Gigaflops to process. Actually the speed limit is around 4 Ghz so recently cpu pwoer is coming from parallelism.. which cannot help a linear algorithm... But there is a risk that someone would divise a way to find the resulting key without doing all the intermediate calculations, and thus turn 20 years into a short time ..

Leon
  • 31
  • 1
  • 3
    Point 2 is not a very convincing argument, to be honest. Just because the probability is not zero doesn't mean it's going to happen. Also, speed limit is more like 9GHz, at least to public knowledge. – Thomas Dec 31 '12 at 05:08
  • 2
    Point 1 assumes that cracking can be parallelized. Which isn't necessarily possible - depending on what is being cracked. Proof of work protocols can be designed to not be parallelizable, (such as RSA POW mentioned elsewhere on this page). – user2460798 Jun 08 '17 at 21:28
0

Passcodes on iOS take 80 milliseconds to decrypt.

When you set up the passcode, it’s encrypted with a multi-round algorithm, measuring the time, so that decryption takes 80ms. More rounds on newer, faster hardware.

Decryption is done using a 256 bit key built into the CPU that cannot be extracted, so the decryption must be done on the same CPU. And instead of 80ms you could pick any time.

But it’s not really a solution. Say you want your data be decrypted in twelve months. Then you’d have to encrypt for six months, start decrypting, and the decryption takes another six months. If you decide in 24 months to decrypt the data, it will take six months again.

You need an algorithm that turns a time stamp into one key needed for encryption and one for decryption, and put them on a secure server. That server provides the encryption keys for a time stamp at any time, but the decryption keys only at times past the time stamp. And that server needs to be absolutely locked down. Importantly, the servers notion of “current time” must be unbreakable. Maybe connect it to a telescope and let it check locations of some stars. Or a hardware counter that cannot be advanced more than once per nanosecond without destroying it.

gnasher729
  • 1,218
  • 7
  • 9
  • Two issues: 1) the question requires that encryption is fast, but decryption is slow, which can't be obtained by adjusting the number of rounds in a symmetric encryption/decryption algorithm as stated in this answer. 2) I doubt that in any modern smartphone it holds both that passcodes are encrypted on enrollment and decrypted on verification and the delay for checking a passcode is obtained by adjusting the number of rounds in the cipher used for that. I guess it's used a purposely slow hash, or/and comparison in a secure environment after a delay. If I'm wrong, I'd love a reference. – fgrieu May 26 '23 at 12:53
  • Apples method for file encryption is widely published. 80ms is the time from gathering all information to producing a decryption key, and that time can be made arbitrarily large. – gnasher729 May 26 '23 at 22:29
0

Use a dual radioactive decay key.

You have one element with say a 1000 year half life, and another with a 20-year half life.

You detector is programmed to see the decay products, and only produce the decryption key if the proper ratio of decay products are present.... and if at any time, an improper mix of decay products is present, it destroys the key.

Bubba
  • 9
  • 1
0

Yes.

A solution is to choose an encryption method that inflates the number of bits in the encrypted message to a literally astronomical level.

By doing this, you can guarentee a lower bound on how long it will take to read the encrypted message.

The reason this works is that our universe has a limit on how many bits of info you can store in a given volume. The maximum information is the surface area of the volume measured in Plank areas. If you pick a number of bits that under the best packing scenario (a spherical black hole) would require a given amount of time for all bits to reach a person positioned at the center of the black hole, then there is no possible way that person can receive the encrypted message in under a given time. Eg, if the black hole had a radius of 1 light year, it would take at least a year to read all of the bits that comprise the sphere.

For an idea, the max info in a .5 meter radius sphere is 1.3 x 10^36 bits. That number of bits is astronomical, yet would only buy you an extremely short amount of time before the message could be read.

There may be ways to shave this number of bits down, ie if there are other physical laws that limit data transfer rates besides density packing, or if you can prove that a certain amount of computation must be done and if there is a physical limit on computation time.

William
  • 235
  • 1
  • 6
0

All these comments and answers about outer space and light beams gave me an idea… To encrypt a message so that it is decoded after 1 year:

  1. Choose a celestial body.
  2. Encrypt the contents of the message with a key generated from the position of that celestial body.
  3. Calculate the position at which the object will be in 1 year.
  4. Provide the recipient with the encrypted message and the final position of the object.

After 1 year, the recipient of the message will see the celestial body in the indicated place. A short analysis of its trajectory will allow him to calculate the position at which the object was 1 year earlier, thus enabling him to decode the message.

Of course this is just the general idea, but with some research, this might actually be faisable, at reasonable cost!

-1

Some answers suggest using the inherent speed-of-light limitation to introduce delays that can't be shortened. This is an excellent idea. However, for longer delays, these solutions have the problem of requiring very long distances. Fortunately, one can reduce those distances by using interactive protocols with a required large number of rounds between the parties to amplify the inter-party communications delay.

Suppose now that one party is located on a geosynchronous satellite, and the other parties are located on Earth. Every round-trip to the satellite party would linearly increase the time to execute the interactive protocol, and no advancements in computational power or transmission technology could shorten this delay. The only requirement being that the far-away party (the satellite) won't be tampered with, such as being moved closer to Earth, or being cloned (private keys and all). How this can be guaranteed is another question though.

Farid Hajji
  • 84
  • 1
  • 4