It’s a card shuffle, with the digits of pi as the dice. Both of the cipher’s 256-byte tables rebuild exactly that way, thirty years after RSA’s own engineer asked how.
RFC 2268 says RC2’s PITABLE is “based on the digits of PI” and never says how. It is the shuffle Ron Rivest used for MD2’s table, with one change: every draw reads exactly three decimal digits. Run that from the leading 3 and you get PITABLE, 256 of 256 bytes. Run it four digits later and you get the RFC’s second, unexplained table. A short script with no dependencies reproduces both in under a second.
This page computes pi itself, runs the shuffle, and checks every byte against the table printed in RFC 2268. Switch to one of the wrong methods to see what a near miss looks like. It’s about one byte in 256, which is chance.
Each cell is one byte the shuffle produced. Lit cells equal the RFC’s byte at that position.
The interactive rebuild needs JavaScript. The Python script does the same check.
Start with the numbers 0 to 255 in order. Walk up the list. At each step, pick a random position among the ones already visited and swap it with the newest one. That is the Fisher–Yates shuffle (Durstenfeld’s version), the standard way to shuffle a deck fairly. Rivest’s only twist is where the randomness comes from: the decimal digits of pi, read three at a time.
# digits of pi, leading 3 included: # 3 1 4 1 5 9 2 6 5 3 5 8 9 7 9 … rand(n): x = next three digits # 0 … 999 if x < n × floor(1000 / n): return x mod n else: throw x away, read again S = [0, 1, …, 255] for i = 2 … 256: j = rand(i) swap S[j] and S[i−1] # PITABLE = S # 828 digits read, 21 draws thrown away
The throw-away step is what makes the dice fair. With n = 3, the thousand values 000 to 999 don’t split evenly into three groups, so the rule discards 999 and draws again. Over the whole shuffle that happens 21 times. Leave the step out and the shuffle drifts off course at the first discarded draw, ending at 29 of 256 bytes.
Rivest’s MD2 hash (RFC 1319) has its own 256-byte “pi” table, and for 25 years nobody had explained that one either. In 2014 a user on Cryptography Stack Exchange emailed Rivest and posted his reply: the same shuffle, driven by pi’s digits. MD2’s version reads as few digits as it needs: one digit while n ≤ 10, two while n ≤ 100, three after that.
RC2 uses the identical loop and the identical rejection rule, but always reads three digits. That small difference is enough to hide the link. Apply MD2’s exact rule to RC2 and you get 1 matching byte out of 256, so anyone who tried the obvious thing in 2014 would have concluded the tables were unrelated. Rivest’s own description dates RC2 to 1987, and a 1998 paper he co-wrote says 1989, the year MD2 was designed. Either way the two tables come from the same years and the same hand.
RFC 2268 has a second permutation in section 6. It turns a key length into the RC2Version number stored in RC2-CBC parameters, and the RFC says only that it is “not the same table that appears in the key expansion.” It gives no origin. Start the same shuffle at the fifth digit of pi (5926…) instead of the first, and it rebuilds byte for byte: 256 of 256, again 828 digits with 21 draws thrown away. That’s presumably how Rivest made a second table that was different from the first and just as traceable, by running his generator again from a different place.
There are about 10507 ways to order 256 bytes. The search that found this rule tried roughly 100,000 candidates: four digit sources, seven ways of drawing a number, six shuffle orders, 300 starting points. Exactly one matched all 256 bytes, and it was the simplest of them. Every plausible neighbour lands at chance.
24 3f 6a; the real table starts d9 78 f9.Rivest designs RC2 for RSA Data Security as a trade secret. His later write-up says “Created 1987”; the 1998 paper says 1989.
RC2’s source code is posted anonymously to sci.crypt. The table carries a comment that implementations still ship today:
“256-entry permutation table, probably derived somehow from pi”
Robert Baldwin of RSA Data Security posts a list of open technical questions about RC2 to the cypherpunks list. The first one:
“How can you tell whether the permutation is based on some sequence of digits from PI?”
Nobody in the thread answers it.
Rivest publishes RFC 2268. The table is “based on the digits of PI”; the method isn’t given. A paper he co-wrote that year says only “derived from the expansion of π.”
On Hacker News and Cryptography Stack Exchange, people note that the MD2 table “(and rc2 apparently)” remain unexplained.
Rivest explains MD2’s table by email. No public record shows anyone applying that method to RC2.
Both RC2 tables rebuilt from pi. That’s this note.
It changes nobody’s security. RC2 has been deprecated for years, though it survives in old PKCS #12 certificate files, and the origin of a fixed public table doesn’t make it weaker or stronger. What it settles is the “nothing up my sleeve” question. Designers derive constants from pi so outsiders can trust they weren’t chosen to plant a weakness. Until now, RC2’s table only said it came from pi. Now it demonstrably does.
Rivest always knew. My claim is only that the method hadn’t been published. The search for prior work covered the 1996 mailing-list archives, the 1998 design paper, a Japanese government evaluation of RC2, Cryptography Stack Exchange, Hacker News, GitHub code search, X, and searches in Chinese, Russian and Japanese. It found people asking, and nobody answering. If you know of an earlier derivation, tell me and I’ll credit it here.
This came out of an experiment. In October 2026 Anthropic traced the seeds of the NIST elliptic curves to an old random-number function and some 1990s timestamps. It made me wonder how many small, neglected puzzles have an answer that would prove itself if anyone looked. I set up a pipeline to find them. It harvests thousands of old unanswered questions, scores them for whether a solution could be checked exactly, and sends AI coding agents after the best ones.
RC2 was the first hit. The agent, Anthropic’s Claude, reasoned that if one of Rivest’s pi tables had been explained, his other one should yield to the same method. It found the three-digit rule in about fifteen minutes. A second model, OpenAI’s Codex, then rebuilt the result from the RFC and a one-paragraph description without seeing our code. A third rebuild, written separately again, used its own pi routine and a fresh download of the RFC. All three agree. A later sweep across other “derived from pi” tables found the second RC2 table.
None of that needs to be taken on trust. The script is on GitHub: no dependencies, it computes pi itself, and it prints True twice.
Sources. Tables: RFC 2268 §2 and §6. Dates: draft-rivest-rc2desc-00 (“Created 1987”) and Knudsen, Rijmen, Rivest and Robshaw, On the Design and Security of RC2, FSE 1998 (“designed in 1989”). The 1996 comment: the leaked rc2.c as archived in the funet crypto collection. Baldwin’s question: cypherpunks archive, message 48998, 2 Feb 1996. MD2’s method: Cryptography Stack Exchange question 11935, answer of 2 Aug 2014. Match counts: computed by the published script; the search that ruled out about 100,000 alternatives is logged in my working files and available on request.
The script computes pi, rebuilds both tables, compares them with RFC 2268, and runs the controls. If you find an earlier derivation, or a hole in this one, I’d like to hear about it.
First published October 17, 2026. RC2 tables as printed in RFC 2268; every match count is reproduced by the published script.