How RC2’s π table was made

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.¹ 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 π.² 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.

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.

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

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.

The match is not the kind of coincidence a broad search could stumble on. There are about 10⁵⁰⁷ 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).

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,⁶ and the RFC says only that it “is not the same table that appears in the key expansion phase”.¹ 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.

4.1Where else the second table lives

The same 256 bytes turn up outside RC2. Lotus Notes and its server, Domino, hash passwords with a 256-byte “magic table”, which password-recovery tools carry for four generations of the format, from Notes 5 hashes to Notes 8.5 ID files.⁷ Quarkslab pointed out in 2013 that the array is the one in OpenSSL’s RC2 code.⁸ It is the version table, not PITABLE, so the shuffle above explains the table behind Notes passwords too (Figure 3). That fits the history in Section 5: RC2 was designed for Lotus.

5How the table stayed unexplained

1. 1987–89
   Rivest designs RC2 for Lotus, which needs exportable encryption for Notes.
2. 1996
   The code leaks to sci.crypt with the comment “probably derived somehow from pi”. RSA’s Robert Baldwin asks in public how anyone could tell.
3. 1998
   RFC 2268 prints both tables, “based on the digits of PI”, without a method.
4. 2013
   Comments on Hacker News and Cryptography Stack Exchange note that the RC2 and MD2 tables are still unexplained.
5. 2014
   MD2’s table is explained, from an email by Rivest. The same method, applied to RC2, matches only by chance.

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. Lotus engaged Rivest, who designed RC2 within a few weeks; Lotus paid for the work and RSA Data Security held the rights.⁹ (Rivest’s 1997 draft specification is dated “Created 1987”; a 1998 paper he co-authored gives the design date as 1989.^1,10)

Rivest submitted the design to the NSA, which asked for “a couple of tweaks”. Ozzie, who led the negotiations, put the obvious question to Rivest:

“How do you know they’re not doing something to weaken it?”Ray Ozzie to Ron Rivest, as recounted by Levy⁹

Rivest judged the suggestions technically sound and adopted them. Levy’s account does not say what they were.

5.2Secrecy and disclosure, 1989–1998

In 1989 the NSA verbally offered Lotus an export licence for RC2 with keys limited to 32 bits. In 1992 an agreement negotiated through the Software Publishers Association gave expedited export approval to retail software using RC2 or its sibling RC4 with keys of at most 40 bits,¹¹ on the condition that RSA and its licensees keep the designs secret.⁹ RC2 shipped worldwide inside commercial products while its internals, including the table, remained unpublished.

/* 256-entry permutation table, probably derived somehow from pi */ static const unsigned char permute[256] = { 217,120,249,196, 25,221,181,237, 40,233,253,121, 74,160,216,157, 198,126, 55,131, 43,118, 83,142, …

On 29 January 1996, RC2’s source code was posted anonymously to the Usenet group sci.crypt; references to debugging tools suggested it had been reverse-engineered. Four days later Robert Baldwin of RSA Data Security posted a list of open technical questions about the cipher to the cypherpunks mailing list. The first concerned the table:

“How can you tell whether the permutation is based on some sequence of digits from PI?”R. W. Baldwin, “RC2 technical questions”, 2 February 1996²

No answer appears in the thread. In March 1998 Rivest published RC2 as RFC 2268, printing the table in full without a construction.¹ A paper he co-authored the same year states only that the table “was derived from the expansion of π”.¹⁰

5.3A related table, explained in 2014

Rivest’s MD2 hash function contains its own 256-byte permutation, “constructed from the digits of pi” according to its specification,¹² and it too was unexplained for years. In 2013, commenters on Hacker News and Cryptography Stack Exchange noted that both the MD2 and RC2 tables remained unexplained.¹³ In 2014 a Stack Exchange user obtained the MD2 construction from Rivest by email and posted it.⁵ We found no published work that applies it to RC2.

6Discussion

It helps to separate three claims. Established by computation: Algorithm 1 reproduces both published tables exactly, and anyone can check this with the published script. Strongly supported, but not proven: this is the method, or something very close to it, by which the tables were originally made. A short rule that matches every entry of both tables, while its near variants fail, is hard to explain any other way, and the rule is Rivest’s own documented MD2 shuffle with one change. Not established: exactly how Rivest arrived at it, including whether he tried other rules or starting points before settling on this one. The tables alone cannot tell us that.

The last point matters for the “nothing up my sleeve” question. The 256 entries were not chosen one by one: they follow from a short rule applied to π. That leaves far less room for deliberate selection than a table chosen entry by entry, but it does not remove it entirely. A designer could, in principle, have tried several simple rules or starting points and kept one; the second table’s different starting point shows that such choices were made. Nothing here tells us what the NSA’s 1987 changes were, or whether they touched this table.

The result does not affect RC2’s security. The cipher has long been deprecated, though it persists in older PKCS #12 certificate files, and knowing the origin of a public table makes it neither weaker nor stronger. Rivest presumably always knew the method; the claim here is only that it had not been published.

The search for earlier work covered the 1996 cypherpunks archive and part of the sci.crypt discussion (Google Groups’ search was rate-limited), the 1998 design paper, the Japanese government’s CRYPTREC evaluation of RC2, Cryptography Stack Exchange, Hacker News, GitHub, X, IACR ePrint, and searches in Chinese, Russian and Japanese. It found the question asked several times and never answered. Semantic Scholar and print-only sources could not be searched fully, so an earlier explanation may exist in a source we did not reach. Corrections are welcome and will be credited here.

7A note on method

This result came from an experiment in using AI agents on neglected problems whose answers can be checked exactly. In October 2026, Anthropic reported that its model Claude had traced the seeds of the NIST elliptic curves to a standard C library random-number generator seeded with timestamps from 1997 and 1998.^14,15 I set up a pipeline that collects long-unanswered questions, ranks them by whether a solution would verify itself, and assigns the most promising to AI coding agents.

RC2’s table was the first result. The agent, Claude, reasoned that if one of Rivest’s π tables had been explained, the other might yield to the same method, and found the three-digit rule. OpenAI’s Codex wrote the independent second implementation described in Section 3, and a later sweep of other “derived from π” tables found the second RC2 table. None of this needs to be taken on trust: the script in the repository computes π and checks both tables against the RFC in under a second.