What the solved NIST P-256 seed mystery means
The unexplained seeds behind P-256 and its sibling curves turn out to be clock-seeded lrand48 output. Here is why that matters and what is still open.
Anthropic’s research post Claude reveals ECDSA curve origins reports that an internal research version of its Claude model worked out where the unexplained seed values behind the NIST P-192, P-224, P-256, P-384 and P-521 elliptic curves came from. According to Anthropic, the seeds were not hashes of a secret phrase, as long rumored. They were output of the C library’s lrand48 random-number generator, started from a Unix timestamp. That one fact, plain clock-seeded output that anyone can regenerate, is what turns a decades-old suspicion into a mostly closed question.
The background you need
ECDSA stands for Elliptic Curve Digital Signature Algorithm. A digital signature lets you prove a message came from the holder of a private key, without revealing that key. ECDSA does this using math on an elliptic curve, a specific equation whose points can be combined in a way that is easy to compute forward and very hard to reverse. Curves like P-256 sit underneath a large share of everyday cryptography, including HTTPS connections and many signing systems.
A curve is defined by a handful of numbers called parameters. One of them is a coefficient called b. Another is the base point, G, which according to Anthropic is the fixed point that every ECDSA public key is a multiple of. If someone picking these parameters knew of a rare class of weak curves, they could in theory choose a weak one on purpose. That is the fear behind the word backdoor.
To guard against that, standards often use verifiably random parameters. You publish a starting value, the seed, and derive b by running the seed through a hash function. A hash scrambles input so thoroughly that you cannot steer the output. So the designer could not have hand-picked b directly.
The catch: the designer could still have tried many seeds and kept one that produced a curve they liked. Proof that b came from a seed is only reassuring if you also know where the seed came from. According to Anthropic, NIST adopted these curves in 2000 as part of the FIPS 186-2 Digital Signature Standard, and the seeds were provided by the NSA with no explanation or justification. The P-256 seed, for example, was a 160-bit hex string with no stated origin.
That silence mattered more because the NSA is widely understood to have been behind a different NIST standard, the Dual_EC_DRBG random-number generator, which many cryptographers came to regard as deliberately backdoored. After that, unexplained NSA-supplied constants drew extra scrutiny. Anthropic points to a summary of the controversy by Neal Koblitz and Alfred Menezes, and notes that an amateur investigation and a bounty, organized by Filippo Valsorda, grew up around finding the seeds.
Two more terms. A pseudorandom number generator (PRNG) is a formula that produces numbers that look random from a starting value. lrand48 is one shipped with C libraries. It is a linear congruential generator (LCG): multiply the current state by a constant, add another, keep the remainder. srand48 sets its starting state, and a Unix timestamp is the clock time counted in seconds since 1970. LCGs are fine for simulations and weak for cryptography, because their output has patterns you can spot and reverse.
An analogy: think of the seed as a lottery ticket number someone handed you, saying only that they picked it. Now you learn it came from a cheap ticket machine whose starting point was the time of day, and you can rerun the machine yourself. Where the analogy breaks: a clock reading can still, in principle, be chosen by trying many times. Anthropic addresses that possibility directly, below.
What actually changed
The curves did not change. No new attack was found. Anthropic states it plainly: “This is not a cryptographic break, new attack, or weakness in the ECDSA curves.” What is new is the explanation of where the numbers came from.
According to Anthropic, the search worked like this. Earlier attempts, including by Anthropic employees, chased the humorous-passphrase rumor and came up empty. Claude instead guessed the generating software used a 1990s C-library PRNG and wrote a scanner to test whether chunks of each seed looked like consecutive outputs of such a generator. It noticed that some seeds had a zero top bit in every 32-bit word, which Anthropic says would happen by chance with probability 1/5,810, and which matches lrand48 returning only the top 31 bits of a 48-bit state.
For the prime-curve seeds, fewer bits were kept, so Claude used the LLL lattice-reduction algorithm, a standard tool for this kind of truncated-LCG problem. Because an LCG runs backward as easily as forward, Claude stepped each state back to the form srand48 produces. According to Anthropic, all ten prime-curve seeds (five NIST, five from the ANSI X9.62 standard) trace to Unix timestamps between May 1997 and April 1998. Each candidate seed was 20 bytes drawn from the generator. P-256’s published seed was candidate 1,842 of its run.
Anthropic also reports two extras. Four binary-curve seeds decode to February 1984 unless the timestamps are doubled, which gives April 17, 1998, so Anthropic suggests the program may have halved the clock. And the base points of six curves from May 1997, including P-192, come from the random-number generator in Arjen Lenstra’s FreeLIP library. Anthropic says no NIST base point had been explained before. The post includes short Python code that regenerates the seeds and those base points.
What it means for you
The practical message is short. Anthropic writes: “There is no action to be taken or things to do differently.” It adds that most researchers trusted the curves already, and that the findings make deliberate backdoors much less plausible.
Why does the timestamp detail matter more than the rest? Because the backdoor worry was never about the hash step. It was about whether the seed was secretly shopped for. A seed that falls out of a common, weak, clock-started generator is about as ordinary as a seed gets, and the method is now public.
There is one wrinkle Anthropic flags itself. Not every candidate made a usable curve, but some usable ones were skipped. For P-256, candidate 876 of the same run would also have worked. P-224’s run passed over three such curves, and the ANSI runs passed over seven more. Anthropic says it does not know the criteria, or whether this was an unintentional artifact. It argues that because the number of skipped candidates is small, it does not believe it is plausible that weakened curves were selected, since that would imply weak curves are common and easy to find. It also concedes that searching over timestamps is still conceivable in principle, while noting you would only bother if you planned to disclose the timestamp as evidence.
What to watch: independent cryptographers reproducing the results, and anyone explaining the skipped candidates. Also note who did the work. This is Anthropic reporting on its own model, published by its Frontier Red Team. The published code is what lets outsiders check it.
What we don’t know yet
- B-163. According to Anthropic, the fifth binary seed fits nothing Claude tried and remains unexplained.
- Most base points. Anthropic could not explain how the base points for P-224, P-256, P-384 and P-521 were chosen, nor those of the NIST binary curves.
- Why candidates were skipped. The selection criteria are unknown.
- How many runs there were. Anthropic says nothing in the numbers shows this.
- The halved clock. The binary-curve reading is a suggestion that the program may have halved the clock, not a confirmed fact.
- Human confirmation. Jerry Solinas, the NSA employee at the center of the rumor, died in 2023, and Anthropic says other colleagues from the time were not responsive.
One more loose end has a tidy answer: Anthropic says the $36,864 bounty for finding the seeds will be donated to the Internet Security Research Group.
FAQ
Does this mean P-256 is broken or unsafe?
Why would a weak random-number generator be good news?
Is the whole mystery closed?
Related reading
2026-10-14
What the 11-year-old Rust borrow checker bug means
A newly reported Rust soundness hole lets safe code read freed memory. Here is what lifetimes, variance and Drop have to do with it, and who should care.
2026-10-17
What interactive refactoring in gopls means for Go devs
gopls v0.24.0 refactorings can now ask you questions first. It relies on a proposed LSP change, which decides whether your editor gets it.
2026-10-17
What websites blocking AI agents means for your work
Yelp, Delta, JPMorgan Chase and others are turning away AI agents. Here is why, and how to check before you hand an agent a real task.
2026-10-17
What Amazon buying DuckDB's makers means for Aurora users
AWS bought DuckLabs and put DuckDB inside Aurora PostgreSQL. What you can now query, what it costs, and what stays open source.
2026-10-16
What the Collabora CODE flaw means for Nextcloud
Attackers hit Nextcloud servers for a month before CVE-2026-110447 existed. Here is how to check if you run the vulnerable app and what to do.
Get the best tools, weekly
One email every Friday. No spam, unsubscribe anytime.