Claude uncovers the origin of the seeds for NIST's ECDSA curves: an lrand48 generator initialized with Unix time

Anthropic has published a piece on its research blog by its Frontier Red Team. According to the post, an internal research model, Claude, has solved a roughly 25-year-old cryptography mystery: how the “seeds” for the standard elliptic curves behind ECDSA were generated. This is the company's own account of its own model, and the code it includes lets readers reproduce the results.

The post stresses that this is not a cryptographic break, a new attack or a weakness in the curves. It asks readers to see it as a “fun final chapter” after years of speculation. No action or change is needed, and the post says most researchers already trusted the curves.

Background: ECDSA is the most widely used elliptic-curve cryptography standard. NIST adopted it in 2000 as part of the Digital Signature Standard (FIPS 186-2), which lists curves of different sizes and security levels. For the curves over prime and binary fields, the specification published a “seed” parameter whose hash value defines the curve's b coefficient. The NSA supplied these seeds without explaining where they came from. For example, the seed for NIST P-256 is C49D3608 86E70493 6A6678E1 139D26B7 819F7E90.

With no explanation on record, people suspected for years that the curves had been chosen with backdoors or deliberate weaknesses. Neal Koblitz and Alfred Menezes summed up the controversy in “A Riddle Wrapped in an Enigma”. There was also amateur research and a bounty for anyone who found the seeds.

The best available story credited the seeds to Jerry Solinas, an NSA veteran, who was said to have hashed a joke phrase along the lines of “Give Bob and Jerry a raise”. That was his own account in 2015, though he was unsure of the details. Solinas died in 2023 and the others involved did not respond, so the question remained open.

The finding: according to Anthropic, several employees had tried and failed to find the phrase. In October 2026, one of them asked an internal model whether it could work out how the seeds had been generated, without giving it the hint about the phrase. In under half an hour, Claude found the origin of the seeds for NIST P-192, P-224, P-256, P-384 and P-521. None came from a hash algorithm. They were output from lrand48, the C library's random number generator, seeded with a Unix timestamp.

The algorithm draws bytes from the generator, seeded with a timestamp t, over n iterations. Each iteration takes 20 bytes as a candidate seed: the first 20 bytes are candidate 1, the next 20 are candidate 2, and so on. For P-256 it took 1,842 iterations to reach the standardised seed.

How it was found: once searches for the phrase failed, Claude switched approach and tried to infer how the software that generated the curves must have worked. It guessed that the software used a pseudorandom generator from 1990s C libraries. These generators are weak enough that their output can be recognised, and recognising it would reveal which one was used and might make it possible to recover its initial state.

Claude wrote a scanner that went through each published seed bit by bit, checking whether adjacent chunks were consecutive outputs of a generator from that era. It covered 34 combinations of generator and output slice. It then noticed a pattern: in four of the ten seeds, the top bit was 0 in all 20 words. The post says the odds of that happening by chance are 1 in 5,810. It was the signature of lrand48, a linear congruential generator that returns only the top 31 bits of a 48-bit state.

To recover the state, Claude took the first word, tried all 2^17 possible values of the 17 hidden bits and checked that the next four words matched. It worked for all four seeds in question.

The prime-curve seeds came from the same lrand48 but kept fewer bits of each output. The post says recovering the state of a truncated linear congruential generator is a classic lattice problem, solved with the LLL basis-reduction algorithm. Because Claude did not know which bits of the state the seeds revealed, it ran the solver over every possible window. The five NIST prime seeds and five more from the ANSI X9.62 standard all followed the same pattern: lrand48() >> 23. Each recovered 48-bit state regenerates all 160 bits of its seed, which does not happen by coincidence.

This generator runs backwards just as it runs forwards. Claude therefore stepped each seed's state back to the form srand48 would produce, with the low 16 bits equal to 0x330E. That form comes up once every 65,536 steps, so on its own it proves nothing. What matters is that, for all ten prime seeds, each initialisation matched a Unix timestamp between May 1997 and April 1998.

The four binary-curve initialisations read as February 1984. When the timestamps are doubled, they correspond to 17 April 1998, two weeks after the P-224 run. The post suggests the program may have divided the clock by two. The sample code reproduces the seeds for P-192, P-224, P-256, P-384 and P-521, the ANSI curves prime192v2, prime192v3 and prime239v1 to v3, and the binary curves B-233, B-283, B-409 and B-571, together with their dates and iteration counts.

The article also includes Claude's internal reasoning during the process. The model wondered whether it was in a simulated or test environment and why something so obvious had gone undiscovered for 25 years. It concluded that direct computation, with 160-bit matches for each of the ten seeds, ruled out coincidence.

The base points: each curve has a base point G, the fixed point of which every ECDSA public key is a multiple. The seed does not determine it, so this remained a separate question. While checking the seeds, Claude also found where some of these points came from.

The base points of six curves generated in May 1997 come from the random generator in FreeLIP, Arjen Lenstra's long-integer arithmetic package. Early versions of Victor Shoup's NTL library included the same code. The six curves are P-192 and the five ANSI X9.62 example curves: prime192v2, prime192v3 and prime239v1 to v3.

The recipe is simple. Seed the generator with a small integer and discard seven outputs. Then build candidate x-coordinates from 26-bit outputs reduced modulo p, repeating until x lands on the curve. The generator seeds are 20000 for P-192; 20420, 20507 and 20509 for prime239v1 to v3; and 20512 and 20517 for prime192v2 and v3. According to the post, no NIST base point had been explained until now. The included code confirms that all six match the published values.

Open questions: not every 20-byte candidate yields a viable curve, and Anthropic noticed that some potentially valid curves were skipped. For P-256, the published seed is candidate 1,842, but candidate 876 from the same run also gives a prime-order curve of the right size, with parameters chosen the same way. The P-224 run skipped three such curves, and the two runs for the ANSI X9.62 example curves skipped another seven. It is unknown what criteria were used, or whether this was an unintended artefact.

Because there are so few skips, the authors do not find it plausible that weakened curves were chosen, since that would mean weakened curves are common and easy to find. They acknowledge it is still conceivable that someone searched through timestamps to get a particular property. But that would only make sense if the timestamp were later revealed as proof that the curves were generated innocently, and nothing in the numbers shows how many runs there were.

The seed for the binary curve B-163, which matches nothing tested, also remains unexplained. So do the base points of P-224, P-256, P-384 and P-521, and those of the NIST binary curves.

The authors' reading: Anthropic says the result gives them more confidence that the curves were chosen without backdoors or deliberate weaknesses. The seeds were generated very simply, with a common pseudorandom generator seeded from the clock, and anyone can now reproduce them. That leaves far less room for manipulation. This is the authors' conclusion about their own finding, and the open questions remain.

Other details: the $36,864 bounty for finding the seeds will be donated to the Internet Security Research Group. The authors are John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini and Steve Weis. The code is released into the public domain (CC0 1.0). The authors pay posthumous tribute to Jerry Solinas and thank Filippo Valsorda for organising the NIST elliptic-curve seed bounty.

Why it matters: beyond cryptography, the case is an example of a model reasoning on its own. It formed a hypothesis about how the software had been written, designed a statistical scanner, applied a known lattice technique and checked the result with calculations. All of this rests on Anthropic's account, with no independent verification in this post, though the reproducible code lets others check it.