Numbers that fueled decades of suspicion about a widely used cryptographic standard may have a mundane explanation: an old random-number generator initialized from the clock. In research published October 16, Anthropic says an internal Claude model recovered the origins of multiple standardized elliptic-curve seeds. The researchers say users need not change anything.
An unexplained choice, not a broken standard
The mystery concerns ECDSA, an elliptic-curve digital signature standard adopted by the U.S. National Institute of Standards and Technology in 2000. Its specifications included seed values—starting numbers whose hashes help define the curves. The NSA supplied those seeds without explaining their origins. That left a question hanging over the standard: had someone deliberately selected parameters with hidden weaknesses?
One longstanding lead suggested the seeds came from hashing a humorous phrase. Anthropic employees had tried that route without success. This October, an employee asked an internal research model to investigate without supplying the clue. According to Anthropic, Claude identified the origins of all five NIST prime-curve seeds in under half an hour. The answer was not a passphrase: it was output from lrand48, a pseudorandom-number generator included in C software libraries.
This is not a cryptographic break, new attack, or weakness in the ECDSA curves.
Anthropic researchers
From recognizable bits to a reproducible recipe
Instead of guessing words, Claude investigated what 1990s software might have produced. It wrote a scanner to test the published seeds for recognizable generator output. A pattern of zero bits pointed toward lrand48. For seeds containing less of each output, it used lattice reduction, a mathematical method for recovering the generator’s internal state from partial information.
The recovered states reproduced every bit of five NIST prime-curve seeds and five ANSI X9.62 example-curve seeds, the researchers report. Running the generator backward led to initialization values corresponding to Unix timestamps between May 1997 and April 1998. The recipe draws successive 20-byte candidates; for P-256, candidate 1,842 matches the standardized seed. Anthropic published reproduction code alongside the finding.
Four NIST binary-curve seeds also matched lrand48. Their initialization values look like February 1984 timestamps, but doubling them produces dates on April 17, 1998. The authors suggest the original program may have halved the clock value; that explanation remains tentative. They interpret the simple, reproducible generation process as evidence against deliberate backdoors, rather than evidence that weak randomness broke the curves.
Recovering the recipe does not explain every choice
The investigation also reached beyond seeds. Each curve has a base point, a fixed point used to derive public keys, which the curve seed does not determine. Claude traced the base points of P-192 and five ANSI example curves to the random-number generator in FreeLIP, a long-integer arithmetic package. The recipe starts from a small integer, discards seven outputs and then generates candidate coordinates until one lies on the curve.
Three gaps remain
- One seed still resists explanation: B-163 did not match anything Claude tried.
- The base-point recipe does not explain P-224, P-256, P-384 or P-521, nor the NIST binary-curve base points.
- Some apparently viable curves were skipped. In P-256’s run, candidate 876 also met the described requirements, yet the published curve used candidate 1,842. The selection criteria remain unknown.
The authors judge the small number of skipped candidates unlikely to indicate deliberate weakening: that would imply weak curves were common and easy to find. They acknowledge that searching across timestamps could, in principle, target a particular property. The recovered numbers cannot reveal how many generation runs occurred.
Reader comments
Newest comments first. Replies stay oldest first.