Pangram verdict · v3.3
We believe that this text is a mix of AI and human-written content.
AI likelihood · overall
MixedArticle text · 1,458 words · 15 segments analyzed
Research note · Cryptography The 256 numbers in the key schedule of Ron Rivest’s RC2 cipher were said to come from π, but the method was never published. A card shuffle that uses π’s digits as dice reproduces both of RC2’s tables exactly.
Summary RFC 2268 says the 256-byte table PITABLE in RC2’s key schedule is “based on the digits of PI”, but gives no method, and a second table in the same document is given no origin at all. Both are reproduced exactly by the Fisher–Yates shuffle, using the decimal digits of π as its source of randomness: each draw reads exactly three digits, and draws that would bias the result are discarded. PITABLE starts at the leading 3; the second table starts four digits later.
Rivest’s MD2 hash uses the same shuffle but reads a varying number of digits per draw, which may be why the connection went unnoticed. This is very likely how the tables were originally made, though how Rivest arrived at the rule is not documented.
The question was raised in public by an engineer at RSA Data Security in 1996; an extensive search found no earlier public answer. The result has no bearing on RC2’s security. 1The question RC2 is a block cipher Ron Rivest designed in the late 1980s.
To turn a key into the longer internal key it actually encrypts with, it passes every byte through a fixed table: the numbers 0 to 255 in a scrambled order. Every implementation of RC2 carries the same 256 numbers. A table like this is where a designer could, in principle, hide a weakness. Cryptographers guard against that suspicion by deriving such tables from a public constant like π and showing the derivation, so anyone can rebuild the table and confirm nothing was chosen by hand. These are known as “nothing-up-my-sleeve” numbers, and they only reassure if the derivation is public. RC2 named its constant but never its derivation. Rivest’s specification, RFC 2268, calls the table “an array of ‘random’ bytes based on the digits of PI” and prints it without a method.1 When the cipher’s code leaked in 1996, an engineer at RSA Data Security, which owned RC2, listed in public as an open question how one could tell whether the table came from π.2 No answer followed, and some implementations, such as LibTomCrypt, still carry the comment from the leaked code: “probably derived somehow from pi”.3,4 Section 5 tells that history. This note gives a construction that reproduces the table exactly. 2The answer Picture 256 cards numbered 0 to 255, laid out in order. Take each card in turn, from the second to the last, and swap it with a randomly chosen card at or before its own position. This is the Fisher–Yates shuffle, the standard way to shuffle fairly, and it was not secret. What was never published is where the randomness came from. The tables are reproduced exactly when the dice are the decimal digits of π, read exactly three digits for every draw, starting from the first 3.
Figure 1 plays the first steps. The shuffle, step by step Shuffle21712024919625221181237 Published21712024919625221181237 The first eight of 256 positions, shown in decimal. All 256 match. This animation requires JavaScript. The first steps are: read 314, so card 1 swaps with place 314 mod 2 = 0; read 159, so card 2 swaps with place 159 mod 3 = 0; read 265, so card 3 swaps with place 265 mod 4 = 1; and so on. Figure 1. The first nine steps of the construction, then the result. At each step the next three digits of π choose where the newest card goes: the remainder after dividing by the number of available places. Written out precisely, the construction is Algorithm 1.
The discard step keeps the draws fair. When the number of available places does not divide 1,000 evenly, a draw that lands in the few highest values (960 to 999 when there are 240 places, for example) is discarded and three new digits are read.
Over the whole shuffle this happens 21 times, two of them at the run of six 9s at the 762nd decimal place of π known as the Feynman point.a In total the shuffle uses 828 digits. Algorithm 1. Construction of PITABLE input: d = 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, … (decimal digits of π) rand(n): loop x ← next three digits of d // 0…999 if x < n · ⌊1000 / n⌋: return x mod n // otherwise discard x S ← [0, 1, …, 255] for i ← 2 to 256: j ← rand(i) swap S[j], S[i − 1] return S // = PITABLE Why it may have stayed hidden.
In 2014 Rivest confirmed that his MD2 hash builds its π table with the same shuffle.5 But MD2 reads as few digits as each draw needs: one digit while there are up to 10 places to choose from, two up to 100, three beyond that. Applied to RC2, MD2’s exact rule matches 1 of 256 entries, no better than chance, so the obvious test would have suggested the tables were unrelated. The only change needed is to read three digits every time. 3Verification Algorithm 1 reproduces RFC 2268’s PITABLE in all 256 positions. Figure 2 runs it in your browser, alongside five plausible alternatives, and compares every output with the published table.
Does the method reproduce Rivest’s table? Alternatives: …of 256 positions match the published table Same number as the published tableDifferent numberNumbers shown in hexadecimal, as printed in the RFC This figure requires JavaScript. The reproduction script performs the same comparison and the controls in Table 1. Figure 2.
Each method is run on this page, with π and e computed in integer arithmetic, and its 256 outputs compared position by position with the tables printed in RFC 2268. A random shuffle would match about one position. The match is not the kind of coincidence a broad search could stumble on. There are about 10507 possible orderings of 256 numbers. The search that found the rule tried roughly 100,000 candidates (four digit sources, seven ways of drawing a number, six shuffle orders, 300 starting points, and both the table and its inverse), and exactly one matched in full: the simplest. Variants that change the digit source or the width of each draw fall to chance level. Dropping the discard step leaves the first 112 draws unchanged, so 29 early positions still match before it drifts (Table 1).
Table 1. Positions of PITABLE reproduced by Algorithm 1 and by nearby alternatives. MethodMatching Algorithm 1: decimal π from the leading 3, three digits per draw256 / 256 Algorithm 1 without the discard step29 / 256 Hexadecimal digits of π in pairs, keeping first occurrences2 / 256 MD2’s digit rule (one, two or three digits per draw)1 / 256 Algorithm 1 starting one digit later1 / 256 Algorithm 1 on the digits of e0 / 256 The hexadecimal method in Table 1 is included because, when asked “how was the RC2 PITABLE generated from the digits of pi” on 17 October 2026, Google’s AI Overview described it.
Its own worked example begins 24 3f 6a; the published table begins d9 78 f9. The result was reproduced twice after it was found: by a second implementation written from the RFC and a one-paragraph description of the rule, without access to the first, and by a third using its own computation of π and a fresh copy of the RFC.
4The second table Section 6 of RFC 2268 prints a second permutation of 0 to 255, the RFC’s Table[], called the version table here. It encodes an effective key length of 1 to 255 bits as the RC2Version parameter of RC2-CBC, as used in PKCS #5 and related standards,6 and the RFC says only that it “is not the same table that appears in the key expansion phase”.1 It is Algorithm 1 started at the fifth digit of π (5926…) instead of the first. It matches in all 256 positions, again using 828 digits with 21 discarded draws.
Both tables in the RFC can therefore be produced by one generator, run from two starting points. 5How the table stayed unexplained 5.1An exportable cipher, 1987–1989 In the 1980s the United States controlled the export of strong encryption much as it controlled weapons, and the National Security Agency carried out the technical review. Lotus Development was preparing to sell Notes, a business application with encryption built in, developed for it by Ray Ozzie’s company Iris Associates, and could not obtain an export licence for it using the standard cipher, DES. According to Steven Levy’s account, the NSA agreed in mid-1987 to evaluate a replacement.