By ByteBot
On October 16, Anthropic’s Frontier Red Team announced that Claude traced the origin of all five NIST elliptic curve seeds — the mathematical constants defining P-256, P-384, and three other prime curves — to a 1990s C library random number generator called lrand48, seeded with Unix timestamps from between May 1997 and April 1998. The AI resolved in under 30 minutes what cryptographers had left open for 25 years. If you’re running HTTPS, signing code, or issuing JWTs, your security rests on these curves.
Why the NIST ECDSA Seed Origins Were Suspicious
When NIST standardized the P-curves in 2000, the NSA supplied the seed values with no documentation of how they were chosen. This matters more than it sounds. In practice, whoever controls seed selection can potentially engineer mathematical weaknesses invisible to external auditors — a trapdoor baked into the curve’s parameters before the algorithm design is even public. Good cryptographic standards use “nothing up my sleeve” numbers: verifiably random values with documented, reproducible origins. The P-curve seeds had neither.
That concern became concrete in 2013. Snowden documents confirmed the NSA had deliberately backdoored Dual_EC_DRBG, an NIST-standardized random number generator that also used P-256 curve points with unexamined provenance. RSA Security was reportedly paid $10 million to make it the default in their products. Consequently, NIST withdrew Dual_EC_DRBG from standards in 2014. That confirmed manipulation put the P-curve seeds under renewed scrutiny — if the NSA engineered one NIST standard, why not another? The suspicion was never paranoia. It was a reasonable inference from documented history.
What Claude Found in 30 Minutes
Claude tested 34 combinations of 1990s pseudorandom generators against the ten published seed values. The statistical fingerprint pointed directly to lrand48: four of the ten seeds showed zero in the top bit of every 20-word block, a pattern with roughly 1-in-5,810 probability by chance. Specifically, lrand48 is a linear congruential generator from the C standard library that returns only the top 31 bits of a 48-bit internal state — a common choice for Unix developers in the late 1990s.
From there, Claude applied LLL lattice basis reduction to recover the generator’s full internal state from partial outputs — a well-established mathematical technique that becomes tractable when you know which generator to target. Working backward from recovered states, the timestamps came out to May 1997–April 1998 for prime curves. Anthropic published the reproduction code under CC0 on their research page. Anyone can now verify the genesis of the most-deployed cryptographic curve in the world. A $36,864 bounty previously offered for finding the seeds was donated to the Internet Security Research Group.
Related: .NET 11 RC2: Post-Quantum Crypto and a Go-Live License That Actually Means Something
Partly Resolved, Not Closed
Anthropic is careful not to overclaim: “This is not a cryptographic break, new attack, or weakness in the ECDSA curves.” Finding a mundane clock-seeded generator does make intentional weakening “much less plausible.” The seeds look like what any 1990s Unix developer would produce using lrand48 as their default random source — no elaborate mathematical engineering required. However, six items remain unexplained.
The base points for P-224, P-256, P-384, and P-521 are still untraced — including the base points for P-256, the most widely deployed curve on the internet. The binary curve B-163 seed resisted all recovery attempts. Most puzzlingly, for P-256, candidate 876 met all requirements but candidate 1,842 was published instead. The reason for that specific skip is unknown. The NSA has still never commented publicly on any of this. As multiple security researchers noted, “less plausible” is not the same as “eliminated.”
What Developers Should Actually Do
Nothing urgent. P-256 remains cryptographically sound — no known attack exploits the lrand48 origin. Therefore, continue using it in production without concern. The real value here is context: you now understand exactly how the internet’s dominant curve got its constants, even if that answer raises a few minor new questions about skipped candidates.
For new systems, Curve25519 and Ed25519 are the modern alternatives. Both were designed with verifiable seed generation from the start — the “nothing up my sleeve” requirement is explicit rather than retrospective. Moreover, Ed25519 is already the default in OpenSSH and WireGuard, and it’s worth preferring in greenfield work. P-256 remains required for FIPS 140-3 compliance and many enterprise contexts; that hasn’t changed. For most developers, this is a story worth understanding, not an incident requiring a response.
Key Takeaways
- Claude traced NIST P-256 and four other prime curve seeds to
lrand48Unix timestamps from 1997–1998, resolving a 25-year provenance mystery in under 30 minutes - The finding makes intentional NSA backdoors in the seeds “much less plausible” — the origin appears mundane, not engineered
- Six items remain unexplained, including the base points for P-256 itself and a puzzling candidate skip during generation
- P-256 remains cryptographically secure — no action required for existing deployments
- For new designs, Curve25519/Ed25519 provides explicit, verifiable parameter generation that the NIST curves never had
