The idea is old enough to predate the internet as we use it. Ronald Rivest, Adi Shamir, and David Wagner wrote it up formally in a 1996 paper on time-lock puzzles and timed-release cryptography, framing the goal as encrypting a message so that it can be decrypted only after a chosen amount of time has passed, without relying on a trusted third party to withhold the key. That "without a trusted third party" clause is the hard part. Anyone can encrypt something and promise not to reveal the key until December. The interesting question is how to remove the promise.
Their paper laid out the two families that still define the field. One measures time as computation. The other measures time as an external clock you can verify. They suit very different needs.
Approach One: Time-Lock Puzzles
A time-lock puzzle encrypts the message under a key that can only be recovered by performing a long, unavoidably sequential computation. The work cannot be parallelized, so throwing a thousand machines at it does not help. Decryption is possible for anyone, but only after roughly the intended amount of wall-clock effort, because the computer has to grind through the steps one after another.
The classic construction uses repeated squaring. You pick two large primes, form their product, and encrypt the message key using the result of squaring a starting value a very large number of times, say squaring it a trillion times in a row. The trick is that whoever built the puzzle knows the primes, which lets them compute the answer with a mathematical shortcut in an instant. Anyone who does not know the factorization has no shortcut. They must actually perform the trillion sequential squarings, and each one depends on the last, so there is no way to spread the work across cores.
The security rests on the belief that repeated squaring modulo a hard-to-factor number is inherently step-by-step. If it could be parallelized, an attacker with more machines could open the puzzle early. The "time" the puzzle enforces is therefore the time of one fast processor working alone, which is why this is a computation-based clock, not a calendar-based one.
This is closely related to the machinery behind verifiable delay functions, which formalize the same sequential-work idea and add a proof that the work was done honestly. It also has a famous demonstration. In 1999 Rivest designed the LCS35 time-lock puzzle for MIT, estimated to take about 35 years to solve, and a self-taught programmer cracked it in 2019, ahead of schedule, because processors got faster than expected.
That anecdote is the honest weakness of the puzzle approach. The release date is only as predictable as your forecast of future hardware speed. You are not really setting a date, you are setting an amount of sequential work and hoping it maps to the calendar you had in mind. For a rough "at least this long" delay it is fine. For "release at midnight on this exact day" it is not.
Approach Two: Trusted Agents and Threshold Networks
The second family uses an external time reference. The original version imagined a trusted agent that publishes signatures or keys tied to specific dates. You encrypt so that decryption needs the value the agent will publish on the target date, and until the agent publishes it, no one can read the message. Simple, and it works, but it reintroduces exactly the trusted party the puzzle approach avoided. If that agent is compromised, coerced, or dishonest, it can leak the key early or refuse to publish it at all.
The modern fix is to remove the single agent and replace it with a distributed network, using threshold cryptography. Instead of one party holding the release secret, a group of independent participants each hold a share, and the release value can only be reconstructed when enough of them cooperate. No single member can leak it early, and no single member can block it, as long as a threshold of them behave honestly.
This is how the well-known "timelock encryption" service built on a public randomness network operates. A distributed network produces a fresh, publicly verifiable value at a fixed interval, forever, on a schedule everyone can see. You encrypt a message so that it can be opened using the value the network is going to produce at a chosen future round. Nobody holds that value yet, because the network has not reached that round, and the threshold design means nobody can force it out ahead of time. When the round arrives, the network publishes the value as part of its normal operation, and the message becomes readable to anyone.
The puzzle approach says "this will take a year of computing." The threshold approach says "this opens at 9pm on the fourteenth, because that is when the network reaches that round." One measures effort, the other measures the calendar. Which you want depends on whether you care about elapsed work or a specific moment.
The Two Approaches Side by Side
| Property | Time-lock puzzle | Threshold network |
|---|---|---|
| Clock is based on | Sequential computation | An external published schedule |
| Trusted party needed | None | A network, no single point |
| Release precision | Depends on hardware speed | Tied to a known date/round |
| Who spends effort to open | The reader, doing the work | Nobody, the value is published |
What It Is Actually Good For
Timed-release encryption is a specialized tool, and being clear about its real uses keeps it out of the hype cycle. The genuine cases share a shape: you want something hidden now and automatically revealed later, without depending on a person to be around, trustworthy, and cooperative at the reveal.
- Sealed-bid auctions and voting. Everyone encrypts their bid or vote to a common future release point, so no one can peek at others' choices before the deadline, and all reveal at once when the moment arrives.
- Fair transaction ordering. In systems where seeing a pending transaction early lets someone jump ahead of it, encrypting transactions until they are committed removes the advantage. This is an active use of timelock in some blockchain designs.
- Embargoed disclosure. A journalist or researcher can encrypt material to a release date so it becomes public on schedule even if they are detained, silenced, or simply unavailable, without handing a key to anyone in advance.
- Dead-man switches and digital inheritance. A secret that unlocks on a future date unless actively renewed, so information surfaces if the holder stops checking in.
Notice what these are not. Timed-release is not a general messaging tool and not a substitute for ordinary encryption. It answers one narrow question, how to make a secret open itself later without a trusted keeper, and for everything else it is the wrong instrument.
Where Haven Fits
Haven does not use timed-release encryption, and the reason is instructive rather than dismissive. Private messaging wants the opposite guarantee. The goal is that a message is readable now by exactly the intended recipient and by no one else, ever, not that it becomes readable by everyone at a future date. Those are different problems with different shapes, and using the wrong one would be a mistake. We keep decryption keys on the endpoints, protected by a passphrase that never leaves your device, so a message is bound to a person, not to a clock. Timed-release cryptography is a genuinely elegant answer to sending secrets into the future, and understanding it sharpens the point that good security starts by naming precisely which guarantee you actually need.