Claude Reportedly Traced NIST Elliptic-Curve Seeds, but Verification Lags

What the report says about NIST elliptic curve seeds

Claude reportedly traced the origin of NIST elliptic curve seeds in under 30 minutes, according to a single report that surfaced in an AI news roundup dated October 17, 2026. That claim rests on one secondary source, so treat it as unverified. The AI News Today top stories roundup attributes the work to Anthropic researchers and summarizes it in a few paragraphs.

If the account holds, it answers a question cryptographers have asked for roughly 20 years: where the seeds behind the standard curves came from. According to the roundup, the seeds were not produced through cryptographic hashing. Instead, they came from lrand48, a pseudorandom number generator found in many Unix-style C libraries, seeded with Unix timestamps.

The roundup also says the P-256 seed took 1,842 iterations to produce. The researchers reportedly plan to donate a $36,864 bounty to the Internet Security Research Group, the nonprofit behind Let's Encrypt.

Where the seed origin accounts conflict

The roundup's headline credits lrand48 with the seed origin. Its body describes something different for six other curves, whose base points reportedly trace back to a generator called FreeLIP, with seeds between 20,000 and 20,517. Those two accounts are not obviously compatible.

They could describe different parameters, or the summary could have blended two steps of the process into one. USA 24 cannot tell which from the material available. USA 24 also could not find a public description of FreeLIP that would confirm how it works or whether it is linked to the NIST curves at all.

Until the primary research is public, the most accurate reading is that the report contains at least one unresolved inconsistency. Readers should not assume the lrand48 account applies to every curve named in the roundup.

Which systems depend on P-256 and related curves

P-256 is one of the most widely deployed elliptic curves. It appears in TLS, the protocol behind most encrypted web traffic, as well as in code signing and many authentication systems. That breadth is why a question about how the curves were made draws attention from security teams, even if no practical weakness has been identified.

The roundup does not discuss which products or services would be affected by a change in understanding of the seeds. It also does not claim that any curve is broken, weakened or unsafe to use. That distinction matters, because explaining where a parameter came from is a different question from proving that the parameter is secure.

What has and has not been verified

The table below separates the figures in the roundup from what USA 24 could confirm. Every figure rests on the same single source.

USA 24 searched for a paper or blog post from Anthropic, a statement from NIST and reactions from independent cryptographers. It found none of them. Without a primary document, the figures above cannot be checked against the original research.

The roundup says the findings would let anyone reproduce how the curves were generated, which the researchers reportedly argue strengthens confidence in them. That argument only works if the reproduction steps are published. Nothing yet shows that they are.

Why the origin question still carries weight

The suspicion behind this question has a documented history. In 2013, reporting on leaked documents suggested the National Security Agency had worked to weaken a random-number standard. NIST withdrew that standard, Dual_EC_DRBG, in 2014. The episode left many cryptographers wary of any standard whose constants lacked a clear, public origin.

That history explains why a reproducible account of seed generation would matter. A documented process gives skeptics something concrete to test, and it gives NIST a way to answer questions without asking the public to take its word for it. A vague or unrepeatable explanation would do little to ease concerns.

The analysis also has limits. Showing how a seed was produced does not, by itself, prove that the resulting curve is free of hidden weaknesses. Cryptographers will still ask whether the seed values were chosen to favor a particular outcome and whether outside researchers can repeat the derivation. A primary paper would need to address both questions.

What engineers should do now

Consumers have no action to take based on this report alone. Engineers and security teams face a different situation, but the right response right now is patience rather than changes to production systems.

1. Keep current curve choices in place until a primary paper and independent review are available.
2. Look for the Anthropic paper or blog post, and check whether it publishes reproduction code or data.
3. Check whether the paper's account of P-256 matches NIST's own documentation for the curve.
4. Watch for a NIST statement and for responses from cryptographers who review the parameter derivation.
5. Keep TLS libraries and other cryptographic dependencies on their normal update schedule.

What to watch next

Three developments would settle most of the open questions: a primary document from the research team, a response from NIST, and an independent review by a cryptographer who can test the derivation. The lrand48 and FreeLIP discrepancy matters just as much, because it determines which curves the claim touches. A paper that names the generator for each curve would resolve it quickly.

The bounty is also a useful signal. If the Internet Security Research Group confirms receipt, that would show the research team is willing to stand behind its account in public. Silence from the group would leave the claim where it is now.

For context on how AI systems are being tested in security settings, see USA 24's coverage of disclosures that OpenAI models hacked live systems. This story will be updated if a primary source appears or if NIST responds.