Anthropic says Claude traced NIST P-256 curve seeds to a 1997 clock and lrand48

One of cryptography's long-standing small mysteries — where the seeds behind NIST's elliptic curves came from — now has an answer, and it is mundane. According to an Anthropic write-up published October 16 and relayed by Gabriel Anhaia on dev.to, the seeds for P-256 and its sibling curves came from lrand48, a pseudorandom generator that shipped with 1990s C libraries, each run seeded with a Unix timestamp between May 1997 and April 1998. Filippo Valsorda, the cryptographer behind a public bounty on the question since 2023, says he verified the claim by reimplementing the algorithm in Go. Nothing on P-256 needs to rotate.

A riddle left open since 2000

When NIST standardized ECDSA in FIPS 186-2 in 2000, each of the curves P-192 through P-521 was derived from a seed. Anthropic says the NSA supplied those seeds with no explanation, and the leading theory was that they hashed a humorous passphrase that nobody ever recovered. The gap bred suspicion: whoever picks a seed can, in principle, keep trying until the resulting curve has a property only they know about, and Anthropic notes people long wondered whether the seeds hid deliberate backdoors. BleepingComputer reported in 2023 that no evidence of a backdoor existed, but nothing ruled one out. That year, Valsorda and a group of cryptographers offered $12,288 for the original sentences, tripled to $36,864 if the winner donated the money to charity.

What the research model found

Anthropic credits an internal research model with the answer, reached — by the company's own account of an internal run — in under half an hour. The model guessed that a 1990s C library PRNG was involved, then recovered the generator's internal state from the published seeds, a problem Anthropic describes as a textbook lattice exercise.

The findings, as relayed by the dev.to post:

• The seeds for P-192, P-224, P-256, P-384 and P-521 are lrand48 output, each from a run seeded with a Unix timestamp; P-256's run decodes to August 1997.
• Four binary-curve seeds — B-233, B-283, B-409 and B-571 — fit the same scheme, with a clock value that appears to have been halved.
• The published P-256 seed is candidate 1842 of that run, though candidate 876 also yields a prime-order curve; why 876 was skipped is unknown.
• The base point for P-192, plus five ANSI X9.62 example curves, came from a different generator, FreeLIP, seeded with small integers.

There is one naming discrepancy: Anthropic says lrand48 while Valsorda says drand48. Both belong to the same POSIX family, a linear congruential generator over 48-bit arithmetic — one engine, different output formats.

Anthropic also published two Python scripts, dedicated to the public domain under CC0, that reproduce the seeds and selected base points. The team claimed the bounty and directed it to the Internet Security Research Group, the non-profit behind Let's Encrypt, which per Valsorda triggers the tripled $36,864 amount.

The backdoor question, in bits

Valsorda's argument is quantitative. A 2017 technique from Bernstein and Lange would need roughly 70 bits of freedom in seed choice to steer toward a class of weak curves. Limited to any timestamp in 1997–98 and any of the first sixteen prime-order candidates, the NSA would have had barely 30 bits — enough, per Valsorda, to completely rule out that technique. Anthropic is more cautious, saying the findings make a backdoor much less plausible, and stresses that this is not a cryptographic break, a new attack, or a weakness in the ECDSA curves. Valsorda goes further, calling the result the completion of the NIST curves' rehabilitation and saying he would now personally recommend them over Curve25519, Ed25519 and X25519.

What remains unexplained

The riddle is not fully closed. Anthropic writes that the fifth binary seed, B-163, matches nothing the model tried, and that how the base points for P-224, P-256, P-384 and P-521 were generated remains unknown. Valsorda adds that one of two extra selection criteria still escapes the researchers.

Why it matters

P-256 is the curve behind every ES256 signature on a JWT, and for its users the answer is to do nothing. Anthropic says so explicitly: no keys to rotate, no curves to swap.

Two things lift this above trivia. First, a trust question that stood since the late 1990s fell to a guess about old C libraries plus a standard lattice technique, and the result is independently checkable: Anthropic's scripts are public and Valsorda's Go reimplementation is on GitHub. Second, the generator is the real lesson. A 1997 program seeded a non-cryptographic PRNG from the clock, and decades later its output can be traced back to the second it ran. POSIX warns that the drand48 family should be avoided whenever safety matters, and Python's random module and JavaScript's Math.random() carry the same caveat. Anything minting session IDs, reset tokens, API keys or invite codes should draw from the operating system's cryptographic generator instead — secrets in Python, crypto.randomBytes in Node.js, crypto/rand in Go, or crypto.getRandomValues() in the browser.