- Anthropic says its model traced the seeds of five NIST prime curves to a 1990s random number generator in under 30 minutes. One seed and many base points remain unexplained.
- Anthropic says this is no break and needs no action. It is one case, run on an internal model after earlier human attempts and a bounty.
- The open question for leaders: if weak-generator output can be recognized this fast, which unexplained components of your own might merit a structured review?
Much of the security we rely on rests on trust nobody could check. A standard is published, vendors adopt it, and the question of where its constants came from fades into folklore. This week, Anthropic reported an answer to one such question. The lesson here is a question, not a verdict: if the output of a weak, old generator can be recognized this quickly, what else might be checkable?
What Anthropic reports
ECDSA is a widely used standard for digital signatures. NIST adopted it in 2000 in the FIPS 186-2 Digital Signature Standard. The standard lists elliptic curves, each defined partly by a published "seed" value. Anthropic says the NSA supplied those seeds with no explanation. For years, some people wondered whether they hid a deliberate weakness.
The best-known theory was that a longtime NSA employee, Jerry Solinas, had hashed a humorous passphrase. That theory led to an amateur investigation and a public bounty. Several Anthropic employees also chased it without success. In October 2026, one employee asked an internal research model to work out the origin without the passphrase clue.
Anthropic reports that the answer came in under 30 minutes for the five NIST prime-field curves: P-192, P-224, P-256, P-384 and P-521. The answer was not a hash. The seeds came from lrand48, a random number generator in the C library, started from a Unix timestamp. That is a number counting seconds on the clock.
The post gives no time for the binary-curve seeds. It explains four of the five binary seeds, and one remains unexplained.
How the model found it
The model did not keep searching for the phrase. It asked how the original software must have worked. Its guess was that a weak generator from 1990s C libraries had produced the seeds, because such generators leave recognizable patterns.
It then wrote a scanner to test each seed against 1990s-style generators. A pattern appeared: four of the ten seeds had a zero in the top bit of all 20 words. Anthropic puts the odds of that by chance at 1 in 5810. The pattern fits lrand48, which returns only the top 31 bits of its 48-bit internal state.
The prime-curve seeds revealed fewer bits. The model recovered the hidden state with LLL lattice reduction, a standard mathematical method. It then stepped the generator backwards to a valid starting state. Every one of the ten prime-curve starting states was a timestamp between May 1997 and April 1998.
What it settles and what it leaves open
Anthropic says this is not a cryptographic break or a new attack. It argues the finding makes a backdoor much less plausible, because the process was simple and anyone can now repeat it. It advises readers to take no action.
Several gaps remain. The B-163 seed fits nothing the team tried. Each curve also has a base point, a fixed starting point for its keys. Anthropic traced some of those to a random number generator in an older arithmetic library. For four of the prime curves (P-224, P-256, P-384 and P-521), the team still does not know how the base point was chosen. The same is true for the NIST binary curves.
Some workable curves were also skipped. For P-256, an earlier candidate, number 876, would have produced a valid curve too. Anthropic does not know why the published one was chosen. It judges deliberate weakening unlikely, since few candidates were passed over.
Anthropic adds that someone could still have tried many timestamps and published a favorable one. The numbers do not show how many attempts were made.
One caveat covers the whole story. This is Anthropic's account of its own model's work. The post says the process is reproducible, so outsiders can check it.
One case, and a question
Treat this as a single data point. It ran on an internal research model that readers cannot use. It came after an amateur investigation, a bounty and failed human attempts. It does not show that audits are now cheap in general.
It does show something narrower. Old weak generators leave recognizable traces, and the model reasoned from how 1990s software was likely built. If that kind of trace can be found in half an hour, which other unexplained values in trusted systems might also be checkable? One case cannot answer that. It is still the right question to put to your team.
What to ask your team
First, ask for a short inventory of the cryptographic standards and curves your products and vendors use. Anthropic says ECDSA needs no change. You still want to know where you depend on it.
Second, ask where security-relevant values, such as keys, tokens and identifiers, come from. Any place that still uses a general-purpose generator for security deserves a look.
Third, ask which long-trusted components have no documented origin, and whether any merit a structured review. Anthropic's model was internal, so ask your security staff and vendors what review options exist today.
Trust built on silence may be easier to question than it was. The organizations that gain will decide in advance what they can no longer take on faith.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Anthropic.
