Puzzles · Puzzle series

The treasure chest puzzle

Alice has to send Bob a treasure through a thieving postman, with no key ever travelling. Six levels, from padlocks to discrete logarithms.

By B Klug (GitHub) · Oct 23, 2026 · 8 min read

Alice wants to send Bob a treasure. The only way is the post, and the postman opens anything that isn't locked and keeps what's inside. Alice and Bob each own padlocks and their own keys, but they've never met and can't send a key, because the postman would copy it. How does the treasure reach Bob safely? This puzzle has six levels, from a children's riddle to the mathematics that secures the internet, and you can play every one of them on this page. Nothing you do is sent anywhere, and the answers aren't in the page. Each is checked against a hash.

Your progress is remembered in this browser only, if it allows it. The page works without that.

Level 1: padlocks, and the shape of the solution

The riddle has a neat answer that needs no key to travel. Alice locks the chest with her padlock and sends it. The postman can't open it, and neither can Bob, but Bob can add his own padlock beside hers and send it back. Now the chest has two locks. Alice takes hers off, which she can do because she has her key, and sends the chest again, locked only with Bob's lock. Bob unlocks it and opens it. The chest made three trips and was never on the road without a lock. The postman saw it three times and never could open it.

The history, and why it matters

This is a three-pass protocol, also called Shamir's no-key protocol. It's usually credited to Adi Shamir around 1980. It went unpublished in his own work but appears in the literature soon after. James Massey and Jim Omura developed a version for digital messages in 1982 and patented it (US patent 4,567,600), which is why the exponentiation version in the later levels is called Massey–Omura. It matters because of what you just did: two parties who have never shared a secret can send one anyway, each adding and removing a lock only they control. The idea behind it, a lock that can be removed in any order, is called commutative encryption. The article has the full history and the maths.

Level 2: why XOR is a bad padlock

Computers can use XOR as a lock: XOR the message with a secret key, and XOR with the same key to unlock. XOR doesn't care about order either: (m ⊕ a) ⊕ b = (m ⊕ b) ⊕ a, so it's commutative, and the three-pass protocol works mechanically. Alice sends m ⊕ a, Bob returns m ⊕ a ⊕ b, Alice removes her key and sends m ⊕ b, and Bob removes his. If the keys are random and as long as the message, each transmission on its own looks like random noise, because XOR with a random key reveals nothing.

The solution, and why the lock fails

The trouble is that Eve, the postman, saw all three. XOR the three transmissions together: (m ⊕ a) ⊕ (m ⊕ a ⊕ b) ⊕ (m ⊕ b). Each of a and b appears twice and cancels, and the message appears three times, which is once, so the result is m. XOR is linear, so combining what's sent undoes the locks. A real padlock is easy to put on and impossible to take off without the key, and XOR is far too easy to take off. The XOR tool lets you do the cancellation by hand and shows what a repeating key does for you (nothing good).

Level 3: exponentiation as a padlock

We need an operation that commutes like XOR but can't be undone by combining transmissions. Raising a number to a power modulo a prime does it. If p is a prime, (m^a)^b = (m^b)^a mod p, so locks can be added and removed in any order. To remove a lock with exponent a, raise to d where a·d ≡ 1 (mod p − 1). This works because of Fermat's little theorem: m^p−1 ≡ 1 (mod p) for any m not divisible by p, so raising to a·d, which is 1 plus a multiple of p − 1, gives back m. For the lock to be removable, gcd(a, p − 1) = 1, so that the inverse d exists.

A whole exchange with a prime small enough to follow by hand

Take p = 23, the treasure m = 7, Alice's lock exponent a = 3 (its inverse modulo 22 is 15, since 3 × 15 = 45 = 2 × 22 + 1), and Bob's b = 5 (inverse 9, since 5 × 9 = 45). The numbers come from scripts/examples/three-pass-small.mjs:

Pass	Computation	Result
1. Alice → Bob	7³ mod 23	21
2. Bob → Alice	21⁵ mod 23	14
3. Alice → Bob	14¹⁵ mod 23 (removes her lock: this is 7⁵)	17
Bob opens it	17⁹ mod 23	7

Bob ends with 7, the treasure. The page's level does the same with a 12-digit prime and exact big-integer arithmetic, and asks you for the two unlocking exponents. To find them you use the extended Euclidean algorithm, which the helper shows step by step. Eve's problem is now different. From m^a, m^ab and m^b she has to find an exponent, which is a discrete logarithm.

Level 4: break the small one

The protocol only protects you if finding that exponent is hard, and "hard" depends on the size of p. In level 4 the prime has six digits. Eve recorded x₁ = m^a, x₂ = x₁^b and x₃ = m^b.

The attack, step by step

Find Bob's exponent. Pass 2 is pass 1 raised to b, so b is the discrete logarithm of x₂ to the base x₁. Baby-step giant-step finds it in about a thousand steps for a 6-digit prime (the calculator).
Invert it. Compute b⁻¹ modulo p − 1 with the extended Euclidean algorithm.
Take Bob's lock off. Pass 3 is m^b, so raising it to b⁻¹ gives m.

The treasure was chosen to be a primitive root modulo p, which guarantees the discrete logarithm has exactly one answer in the range, so the attack can't go astray. The cost of the attack scales with the square root of the prime, √p. For a 6-digit prime that's about a thousand steps. For a 2,048-bit prime it's about 2¹⁰²⁴, roughly 10³⁰⁸, which is the difference between a blink and longer than the universe has existed. So the protocol is sound, and the prime has to be thousands of bits long.

Level 5: the postman fights back

One weakness survives any prime size. In the three-pass protocol Alice never checks whose lock came back on the chest. Imagine the postman isn't merely watching but acting. When Alice's chest comes by, he puts on a lock of his own and sends it back to Alice as if it were from Bob. Alice expects a second lock, so she removes hers and returns the chest. The postman now holds a chest locked only with his own lock, and he opens it. The protocol kept the treasure from someone who only listens, but it did nothing against someone who can also change what's sent: a man-in-the-middle attack.

The fix: know whose lock it is

What's missing is authentication, a way for Alice to be sure the lock on the chest belongs to Bob. In real systems that comes from verifying a key fingerprint in person (the "safety numbers" in Signal), from certificates that tie a key to a name and are vouched for by someone Alice already trusts, or from digital signatures. It's a different guarantee from secrecy, and a system needs both. It's also where this puzzle meets end-to-end encryption: the encryption is the easy part, and knowing who you're talking to is the hard part.

The ending: the way it's really done

The three-pass protocol needs three trips, which on a network means a conversation. Public-key cryptography does it in one. Bob generates a pair of keys, one public and one private. The public one works like an open padlock that anyone can snap shut but nobody can open, and the private one is the only key. Bob publishes the public key, Alice locks the message with it, and only Bob can unlock it. That's the idea Whitfield Diffie and Martin Hellman published in 1976, and which the British GCHQ researchers James Ellis, Clifford Cocks and Malcolm Williamson had found in secret a few years earlier. RSA and Diffie–Hellman are two ways of making the padlock, and the story of its double discovery is one of the best in cryptography.

And cipher.ink?

We don't solve Alice's problem. A cipher.ink passphrase, or the key in a secret link, is a key you have to get to the other person, which is exactly where the postman puzzle starts. Passphrase mode asks you to send the passphrase by a second channel, say on the phone, so the postman who sees the link never sees the key. A secret link carries the key in the link itself, so whoever has the link can open the message. That's why burn after reading exists, and why protecting the link matters. We say it plainly because the alternative is pretending that encryption makes the problem of getting a secret to someone disappear. It doesn't. It moves the problem to the key. How we handle it, and where it stops, is in the security page and the article on client-side encryption.

Questions about the puzzle

Is my progress saved?

In your browser's local storage, if it allows it, so you can come back to the level you were on. Nothing is sent to a server, and clearing your browser data resets it.

I'm stuck. Where are the answers?

Each level has three hints, revealed one at a time. The answers themselves aren't in the page, only their SHA-256 hashes, so there's no point looking in the source. The explanation under each level, in the collapsed section, walks through the solution.

Can I play a level directly?

Yes: add ?level=3 to the address, or press the level buttons at the top of the puzzle.

Is this real cryptography?

The mathematics is real. It's the same exponentiation that Diffie–Hellman and the Massey–Omura protocol use, with exact big-integer arithmetic. The primes are deliberately small so you can break them. Real systems use primes of 2,048 bits or more, or elliptic curves.