Time-Lock Puzzle

What is a time-lock puzzle?

A time-lock puzzle encrypts a message so that decrypting it requires a predictable amount of sequential work. There is no secret key to share: anyone can eventually open it, but not before doing the work — and no known method parallelises that work, so extra machines buy you almost nothing. It is, in effect, “send a message into the future.”

How is this different from ordinary encryption?

• Ordinary encryption: without the key you (practically) never open it; with the key it’s instant. Security rests on a secret.
• Time-lock puzzle: there’s no shared key — everyone opens it eventually. Security rests on elapsed sequential time, which you tune by choosing the number of steps.

The construction used here (RSW, 1996)

Rivest, Shamir & Wagner. We pick a modulus N = p·q and a base a. The answer is b = a^(2^t) mod N. To get b you must square t times in sequence:

Each step needs the previous step’s output, so this route to b is strictly serial — and no faster, parallel route to b is known (see Security). The message is then sealed with real AES-256-GCM under SHA-256(b). Everything runs in your browser with JavaScript BigInt and WebCrypto — no backend, no faked math.

Create a time-lock puzzle

Type a secret, choose how much sequential work is required to open it, and generate the puzzle. You get back public parameters that anyone can use to solve it — while the factorisation of N stays your private trapdoor.

Solve the puzzle

Solving means doing the full t squarings in order. Watch the work accumulate — and note that opening another browser tab to “help” would not finish it any sooner.

Security properties

Why parallel machines don’t help

The chain xᵢ₊₁ = xᵢ² mod N is a dependency chain: step i+1 cannot start until step i finishes, and no parallel shortcut to a^(2^t) mod N is known. So an attacker with many cores or a whole data centre gains almost nothing. The delay is set by the time of one squaring on the fastest hardware the attacker can get, multiplied by t: the puzzle opens no sooner than that, and a slower machine only takes longer. (Your own device is usually the slower machine, which is why the demo reports time “on this device” — an estimate for you, not the guarantee against an adversary.)

Sequentiality is an assumption, not a theorem. Nobody has proved that repeated squaring modulo an RSA modulus cannot be parallelised; RSW’s sequential-squaring assumption is a conjecture that has resisted attack since 1996, and this whole construction — along with every VDF built on it — rests on it. The practical claim is the honest one: there is no known parallel speed-up, so more cores buy you almost nothing.

The creator’s trapdoor

The creator knows p and q, hence φ(N) = (p−1)(q−1). By Euler’s theorem they collapse the whole tower into one cheap exponentiation:

That asymmetry — slow for everyone, instant for the holder of the factorisation — is the “trapdoor”. Factoring N would let an attacker recover φ(N) too, which is why the modulus must be large enough to resist factoring.

What if someone cheats or skips steps?

They can’t. The message is sealed with AES-GCM keyed by SHA-256(b). Any wrong answer — from stopping early, guessing, or tampering with the parameters — produces a wrong key, and GCM’s authentication tag rejects it. There is no partial credit and no garbled-but-readable plaintext: it fails closed. Try the “⚡ skip the work” button on the Solve tab to see the rejection.

⚠️ This is an educational build. Real deployments use 2048-bit+ moduli, careful base selection, and a trusted setup so that no party secretly knows the factorisation. The math here is real; the parameters are sized for a responsive demo.

Where time-lock puzzles (and VDFs) are used

• Randomness beacons. Force a delay between when an input is fixed and when the random output is known, so no one can grind the result to their advantage.
• Sealed-bid auctions. Bidders submit time-locked bids; none can be opened until after the deadline, removing the need to trust an auctioneer to keep them sealed.
• Fair multi-party computation & commitments. Guarantee that committed values become readable only after a set time, preventing early peeking or selective abort.
• Blockchain delay mechanisms. Leader election and front-running resistance use enforced delays so an adversary can’t precompute the next step.
• “Send a message to the future.” Escrow, dead-man switches, or delayed disclosure where you want openability without trusting a custodian.

Each case shares one need: a delay that is predictable and that no known amount of extra hardware collapses.

Connection to Verifiable Delay Functions

A Verifiable Delay Function (VDF) is a time-lock puzzle’s close cousin. Both require a fixed amount of sequential work to evaluate. A VDF adds one crucial property: fast public verifiability.

• Time-lock puzzle: proves nothing on its own — you just learn the answer after doing the work (here, AES-GCM lets the solver confirm their own answer).
• VDF: the solver also produces a short proof that anyone can check in milliseconds, without redoing the t steps. “I really did spend the time, and here’s cheap evidence.”

The same RSW squaring chain underlies modern VDFs (e.g. Pietrzak and Wesolowski, 2018), which bolt an efficiently-checkable proof onto a^(2^t) mod N. So this demo is also the engine room of a VDF — minus the proof. A future Crypto Lab demo can build that proof on top of exactly these parameters.