Claude solves the 25 year mystery of the NIST ECDSA curve seeds
On October 16, 2026, Anthropic's Frontier Red Team said Claude solved one of the oldest riddles in applied cryptography. The seeds behind the NIST elliptic curves P-192, P-224, P-256, P-384 and P-521 were not hashes of a secret phrase. They came from the C library random number generator lrand48, seeded with Unix timestamps from May 1997 to April 1998.
For more than two decades, one small set of numbers has sat at the center of a big argument about trust in cryptography. On October 16, 2026, Anthropic said an internal research version of Claude finally explained where those numbers came from. The answer is almost funny in its plainness: a standard random number generator from 1990s C libraries, started with the computer clock.
The numbers in question are the "seeds" behind the NIST elliptic curves, including P-256, one of the most widely used curves on the internet. They are used for digital signatures and secure connections all over the internet. Until this week, nobody outside the original authors knew how those seeds were picked, and the original authors could no longer say.
The three things you need to know
- It was a 25 year old mystery. When NIST adopted its standard elliptic curves in FIPS 186-2 in 2000, the seed values came from the NSA with no explanation. That gap fueled years of speculation about a possible backdoor.
- The answer is timestamps. Claude found that the seeds were not hashes of a humorous English phrase, as the long running story claimed. They were raw output of the C library generator lrand48, initialized with Unix timestamps between May 1997 and April 1998. Anthropic says Claude worked this out in under half an hour.
- It is good news for security. Anthropic stresses that this is not a cryptographic break or a new attack. It makes a deliberate backdoor much less plausible. Filippo Valsorda's bounty for the solution, now worth $36,864, goes to ISRG, the nonprofit that runs Let's Encrypt.
Why these seeds mattered so much
Elliptic curve cryptography depends on public parameters that everyone shares. For the NIST curves, the standard published a seed value, hashed it with SHA-1, and used the output to define the curve coefficient b. The idea behind that design is called "verifiably random": if you can show the parameters came from a hash of a seed, it should be hard to have secretly picked a weak curve.
The problem was that the seeds themselves had no explanation. For P-256, the published seed is the 160 bit value C49D3608 86E70493 6A6678E1 139D26B7 819F7E90, and that was all anyone had. If the person choosing the seed could try many seeds, the hash step would not prove much. That concern was laid out in detail by the mathematicians Neal Koblitz and Alfred Menezes in their paper "A Riddle Wrapped in an Enigma", and it never went away.
The best story on offer came from Jerry Solinas, a longtime NSA cryptographer. In 2015 he recalled that the seeds were a hash of a joke phrase along the lines of "Give Bob and Jerry a raise", with code written by his colleague Bob Reiter. Neither of them remembered the details, and the archives were gone. Solinas died in 2023. In 2023 the cryptographer Filippo Valsorda announced a public bounty for anyone who could find the real origin. Several Anthropic employees chased the joke phrase lead without success.
How Claude found the answer
According to Anthropic's write up, a curious employee asked an internal research model whether it could figure out how the seeds were generated, without pointing it at the joke phrase rumor. Claude took a different angle. Instead of guessing the input, it asked what kind of software a cryptographer in the late 1990s would have used to produce random looking bytes, and whether that software left fingerprints.
Old pseudorandom number generators shipped with C libraries are weak by modern standards, and their output has a recognizable structure. Claude wrote a scanner that slid along each published seed one bit at a time and tested whether neighboring chunks looked like consecutive outputs of a 1990s generator. The scan covered 34 combinations of generator and output slice.
The first clue was visible once you knew where to look. Written as five 32 bit words, four of the ten seeds under study had a zero in the top bit of every word. Anthropic puts the chance of that happening at random at 1 in 5,810. That pattern is a signature of lrand48, a linear congruential generator that returns only the top 31 bits of a 48 bit internal state. Claude tried all 2 to the power of 17 values for the hidden bits of the first word and checked that the next four words followed. They did.
The prime curve seeds, the ones that matter most in practice, kept fewer bits of each output. Recovering the state of a truncated linear congruential generator is a known lattice problem, solved with the LLL basis reduction algorithm. Claude ran the solver over every possible bit window. Five NIST prime curve seeds and five more from the ANSI X9.62 standard all fit the same pattern. Each recovered 48 bit state regenerates all 160 bits of its seed, which Anthropic notes does not happen by chance.
Because this generator can be run backwards as easily as forwards, Claude stepped each state back until it reached the form that the setup function srand48 produces. For all ten prime curve seeds, the starting value was a Unix timestamp between May 1997 and April 1998. In other words, someone ran a program that called srand48 with the current time, drew 20 byte candidates one after another, and kept the ones that produced a valid curve.
Anthropic published short Python code that reproduces every seed. P-256, for example, comes from a run started at 1997-08-16 01:52:34 UTC, and the published seed is candidate number 1,842 from that run. P-192 is candidate 139, P-521 is candidate 1,136, P-384 is candidate 2,688 and P-224 is candidate 7,026.
Anthropic also shared a striking excerpt of Claude's internal reasoning from the moment of discovery. The model first wondered whether it was inside a test environment, then reasoned that a 160 bit match from a 32 bit seed plus a small index could not be a coincidence across ten seeds, and concluded that it was a real discovery.
Bonus: some base points too
Each curve also has a base point, the fixed point that every public key is a multiple of. While checking the seeds, Claude explained where some of those came from as well. The base points of the six curves generated in May 1997, P-192 plus the ANSI X9.62 example curves prime192v2, prime192v3 and prime239v1 to v3, come from the random number generator in FreeLIP, Arjen Lenstra's long integer arithmetic package. The generator seeds were small integers such as 20000 for P-192. Anthropic says no NIST base point had been explained before.
What is still open
The explanation is not complete, and Anthropic is upfront about that. Not every 20 byte candidate produced a viable curve, but some viable ones were skipped. For P-256, candidate 876 of the same run also gives a prime order curve of the right size, yet the published seed is candidate 1,842. Valsorda, who reimplemented the algorithm in Go to verify the claim, found one extra rejection rule (the bit length of the curve order may not exceed that of the field) and still sees roughly twice as many valid seeds as were published. Possible explanations include extra use of the same generator during validation or a bug in 1990s software.
The seed of the binary curve B-163 remains unexplained, and so do the base points of P-224, P-256, P-384 and P-521 and of the binary curves. The binary curve timestamps read as February 1984 unless the clock value was halved, in which case they land on April 17, 1998, two weeks after the P-224 run.
Why it matters
The first reason is trust. Even before this week, most practitioners believed the NIST curves were safe, but the unexplained seeds gave room to doubt. Valsorda writes that the findings completely rule out a known technique by Daniel Bernstein and Tanja Lange that would have needed about 70 bits of freedom in choosing a seed. Even if someone could pick any timestamp in 1997 and 1998 and any of the first 16 prime order candidates, they would have had barely 30 bits of freedom, which he says is not enough to target a hypothetical class of weak curves or hide a backdoor that only the NSA could use. He now personally recommends the NIST curves over Curve25519.
The second reason is what this says about AI as a research tool. This was not a benchmark or a staged demo. It was a public bounty that humans, including professional cryptographers, had chased for years. A model reframed the problem, wrote its own scanner, applied a lattice attack and produced a result that anyone can verify with a few lines of code. That is exactly the kind of capability Anthropic's Frontier Red Team studies for cybersecurity, and it cuts both ways: the same skills that can clear up old suspicions can also find real weaknesses in old systems.
The third reason is the money. The Anthropic team chose to donate the bounty to ISRG, the Internet Security Research Group that operates Let's Encrypt. Valsorda says the donation tripled its value to $36,864.
Dany's take
I love this story because the answer is so ordinary. For 25 years people imagined secret phrases, hidden agendas and clever backdoors, and the truth is a 1990s program calling srand48 with the current time. That is a great reminder that missing documentation creates conspiracy theories much faster than actual evidence does. What impresses me most is not raw speed. It is that Claude ignored the famous rumor, asked a better question about how the software must have worked, and then proved the answer in a way anyone can rerun. If AI can do that for cryptographic history, I expect we will see many more old mysteries in code and standards closed this way. The flip side is obvious too: the same skill set will be pointed at live systems, so defenders need to start using these tools before attackers do.
What this means for you
If you use HTTPS, sign software or run anything with P-256 keys, there is nothing to change. Anthropic calls this a fun closing chapter with no action needed. If you build security products, the bigger lesson is about transparency: publish how your parameters are chosen, keep the code, and make your results reproducible. Twenty five years from now, someone, or something, will check.
Sources
Source: anthropic.com