The NIST curve seeds behind some of the most widely used elliptic curves have a new explanation, and it is much more mundane than a hash function. Anthropic says an internal research model traced the seeds for nine curves to a C library random number generator from the 1990s, seeded with ordinary Unix timestamps. The company is careful to say this is not a break in anything. The interesting part is what it does to an old suspicion.
Here is what the write-up claims, what is verifiable, and what is still unexplained.
In this article
- What Anthropic says it found
- How the NIST curve seeds were traced
- Why a boring answer matters
- What is still unexplained
- What it means if you build with ECDSA
- Editor’s take
What Anthropic says it found
According to Anthropic’s research page, the model recovered the seeds for the NIST prime curves P-192, P-224, P-256, P-384 and P-521, plus four binary curves: B-233, B-283, B-409 and B-571. The seed for a tenth, B-163, is still unexplained.
A seed, in this context, is the starting number published alongside a curve so that others can check the parameters were not chosen to hide a weakness. For years, cryptographers have asked where those NIST curve seeds actually came from. Anthropic’s answer is that they are not hash outputs at all. They come from the lrand48 generator in the old C library, started from a Unix timestamp.
The dates are specific. The page says the prime-curve timestamps fall between May 1997 and April 1998. The binary-curve timestamps are less certain, and the authors say the program that produced them may have halved the clock, which would explain why the numbers do not line up as cleanly.
How the NIST curve seeds were traced
The method is a nice piece of detective work, and it is also the part readers can check. The model guessed that the seeds came from a weak 1990s generator and wrote a scanner to look for that generator’s fingerprints. A pattern of zero top bits pointed toward lrand48. For the prime curves, it then recovered the generator’s internal state using lattice reduction, a standard technique known as LLL.
The test that matters is the last one. Each recovered state regenerated the full seed. Anthropic says that would not happen by chance, which is why it treats the explanation as solid. The page also provides reproduction code, released under a CC0 license, that regenerates the seeds and some of the base points, so anyone can rerun it.
The work was done by ten named researchers at Anthropic. The write-up does not mention outside review beyond that reproducibility, so treat the headline as a company finding that others can now test, not as a settled result.
Why a boring answer matters
Anthropic is explicit: this is “not a cryptographic break, new attack, or weakness in the ECDSA curves.” The curves are no easier to attack today than they were yesterday.
What changes is the story around them. If the NIST curve seeds were produced by a plain random number generator started from a clock value, a deliberately engineered backdoor looks much less plausible, because an attacker would have had to get lucky or work backward through a process that anyone can now reproduce. Anthropic says as much, arguing that backdoor theories become far less likely.
That is a modest claim, and it is the right size. Cryptography runs on trust that the parameters were chosen honestly, and unexplained constants are the sort of thing that erodes it. Replacing “nobody knows” with “a timestamp and an old generator” is a real gain for that trust, even if it proves nothing about intent.
What is still unexplained
The page lists several gaps, and they are worth reading before repeating the headline. The base points for P-224, P-256, P-384, P-521 and the NIST binary curves remain unexplained. The model did explain the base points for P-192 and several curves from a different standard, ANSI X9.62.
There is also an oddity in the data. Some candidate seeds that would have worked were skipped for reasons nobody knows. One example the authors give is candidate 876 for P-256. If the original authors skipped candidates, the selection criteria are unknown, and nothing in the numbers shows how many generation runs took place.
So the accurate summary is narrower than “mystery solved.” The seed question has a convincing, checkable answer for nine curves. The question of how the rest of each curve’s parameters were picked is partly open, and the B-163 seed is untouched.
What it means if you build with ECDSA
For most developers, nothing changes today. You do not need to swap curves, rotate keys or change a library because of this finding, and Anthropic does not suggest you should. The practical value is on the trust side: when someone asks whether the standard curves can be trusted, there is now a documented, reproducible account of where the NIST curve seeds came from, instead of a shrug.
It also gives security teams a useful template for evaluating claims like this one. Ask whether the result can be reproduced from public code, whether the authors list what they could not explain, and whether they say plainly what the finding does not show. This one does all three. That does not make it correct, but it makes it easy to test, and testing is what the field will do next.
A fair question is why this took until now. The answer is probably unglamorous: the search space was large, the hypothesis (an old library generator seeded by a clock) is unfashionable, and the lattice step needs the right framing. A model that tries many cheap hypotheses and checks each against the target number is well suited to that kind of grind. Anthropic’s page describes exactly that loop.
Editor’s take
Watch what outside cryptographers do with the reproduction code, not the press release. If independent teams regenerate the seeds and agree on the lrand48 explanation, the backdoor argument gets harder to make. If they find a flaw in the reasoning, we will hear about it quickly, because the check is cheap to run.
The wider lesson is about AI as a research tool. This is a case where a model did a narrow, verifiable job: form a hypothesis, build a scanner, and produce output that regenerates a known number. That kind of result is easy to check, which is exactly why it is more believable than a vague claim of insight. For related reading on what AI agents do when no one is checking, see our report on OpenAI’s newly disclosed agent incidents, and for the business side of the same technology, what the new AI exclusions mean for liability insurance.
What to watch next: independent confirmation of the NIST curve seeds explanation, and whether anyone can explain the remaining base points.
