Claude traced NIST curve seeds to 1990s timestamps

The seeds behind NIST's P-curves were never hashes of a joke phrase. Anthropic says they came from the C library's lrand48 random-number generator, started from the system clock. Because those clock readings can be recovered, we now know when the curve-generation runs happened: between May 1997 and April 1998.

"It's just timestamps," the team writes in Anthropic's account. In October 2026 an Anthropic employee asked an internal research model how the seeds were generated, without pointing it at the old rumour. In under half an hour the model found the origins of P-192, P-224, P-256, P-384 and P-521. The NSA had supplied these seeds with no explanation, and NIST adopted them in FIPS 186-2 in 2000. Anthropic says this is not a break or a new attack: "There is no action to be taken." Its argument is that a common pseudorandom number generator (PRNG) seeded from the clock, which anyone can now rerun, leaves much less room for a planted backdoor. The $36,864 bounty goes to the Internet Security Research Group.

From top bits to timestamps

Several Anthropic employees had already searched for the humorous phrase and found nothing. Claude came at the problem from the other end. It guessed that the generating software used a PRNG that shipped with 1990s C libraries. Those generators are weak enough that their output can be recognised. Claude wrote a scanner that slid along each published seed one bit at a time, testing whether neighbouring chunks looked like consecutive outputs of such a generator. It tried 34 combinations of generator and output slice.

The signal was in the top bits. Split into five 32-bit words, four of the ten seeds had a zero top bit in every one of their 20 words. That happens by chance with probability 1/5810. It is the signature of lrand48, which keeps a 48-bit state and returns only the top 31 bits. To recover the state, Claude took the first word, tried all 2¹⁷ values for the 17 hidden bits, and checked that the next four words followed. That worked for all four seeds. Anthropic's reproduction code shows these are the binary-curve seeds B-233, B-283, B-409 and B-571.

The prime-curve seeds kept less of each output, only lrand48() >> 23. Recovering the state of a truncated linear congruential generator is a textbook lattice problem, solved with LLL basis reduction. Claude didn't know which bits would show, so it ran the solver over every window. Five NIST prime-curve seeds and five ANSI X9.62 example seeds all fit the same pattern, and each recovered 48-bit state regenerates all 160 bits of its seed.

The generator runs backwards as easily as forwards. For each seed Claude stepped the state back until the low 16 bits equalled 0x330E, the form that srand48 sets. A state like that turns up once every 65,536 steps, so finding one proves nothing by itself. But for all ten prime-curve seeds, the value at that point read as a Unix timestamp. Each candidate seed is 20 draws, so the published P-256 seed, candidate 1842, sits 36,840 lrand48 calls after srand48 was called at 01:52:34 UTC on 16 August 1997.

The runs, in order

The recovered timestamps (UTC, from Anthropic's code) line up against the history of the standard like this:

• 15 May 1997: one run produces the seeds for prime239v1, v2 and v3.
• 18 May 1997: one run produces P-192, prime192v3 and prime192v2.
• 8 August 1997: P-521.
• 16 August 1997: P-256.
• 30 August 1997: P-384.
• Fall 1997: Jerry Solinas gives the seeds to Alfred Menezes, primary author of ANSI X9.62, according to Menezes as quoted by Saweis.
• 3 April 1998: P-224.
• 17 April 1998: B-233, B-283, B-409 and B-571. Read directly, these initialisations date to February 1984. Doubled, they land two weeks after the P-224 run, so the program may have halved the clock.
• 1999: ANSI X9.62 is published, and the seeds' provenance is questioned on Usenet almost at once, per Saweis.
• 2000: NIST adopts ECDSA in FIPS 186-2.
• 2015: Solinas recalls a hash of a message "along the lines of 'Give Bob and Jerry a raise'", and says he believed "there was a counter rather than multiple hashing."
• 2023: Solinas dies. In October, according to Schneier on Security, a $12K prize is posted to recover the seeds.
• October 2026: Claude recovers the seeds.

Two of these items don't quite agree. If Menezes received the seeds in fall 1997, then P-224 and the binary seeds were apparently generated months after that handover. They may have arrived in a later batch. Solinas's memory of a counter now reads a lot like the candidate index, though nothing was hashed.

Base points from FreeLIP

The seed doesn't determine a curve's base point G, which every ECDSA public key is a multiple of. Six curves from May 1997 got theirs from the random number generator in FreeLIP, Arjen Lenstra's long-integer package. Early versions of Victor Shoup's NTL shipped the same code. Those six are P-192 and the X9.62 examples prime192v2, prime192v3 and prime239v1 to v3. The recipe: seed the generator with a small integer, throw away seven outputs, build candidate x-coordinates from 26-bit outputs reduced mod p, and repeat until x lies on the curve. The seeds are 20000 for P-192, 20420, 20507 and 20509 for prime239v1 to v3, and 20512 and 20517 for prime192v2 and v3. Each needed between one and five tries. Anthropic says that as far as it knows, no NIST base point had been explained before. The base points of P-224, P-256, P-384 and P-521 don't fit this recipe.

Skipped curves

Not every candidate yields a usable curve, but some usable ones were passed over. For P-256, candidate 876 of the same run gives a prime-order curve of the right size, built the same way, 966 candidates before the published one. The P-224 run skipped three such curves, and the two runs behind the X9.62 examples skipped seven more. Anthropic doesn't know what criteria were applied, or whether the skips were deliberate. It argues that with so few skips, choosing a weakened curve would only work if weak curves were common and easy to find. Searching over timestamps for a specific property is still possible in principle. Anthropic notes that this would only be worth doing if you planned to disclose the timestamp as evidence of innocence. B-163 fits nothing tried so far, and the base points of the NIST binary curves are also unexplained.

Claude's internal reasoning at the time, as Anthropic quotes it, included this line:

It’s verified by direct computation on my side: 160-bit match from a 32-bit seed + small index: no chance coincidences (10 × 160 bits). It’s real.