NIST P-256 curve seeds traced to a 1997 lrand48 run

A team at Anthropic has worked out where the random-looking seeds behind NIST's P-256 and other standard elliptic curves came from. The seeds were made in 1997 and 1998 by an old C random number generator, lrand48, started from the computer's clock. The find, claimed on October 15, 2026, closes a question cryptographers have argued about for years. It does not weaken the curves.

The bounty and who claimed it

Filippo Valsorda, a cryptography engineer, offered a bounty three years ago to anyone who could explain the seeds. His post announcing the claim says Anthropic researchers claimed it at 01:07:51 UTC on October 15, 2026. The prize was tripled to $36,864 and goes to ISRG, the nonprofit that runs the Let's Encrypt certificate service.

Anthropic published its own write-up on October 16. It names ten researchers, including Nicholas Carlini and Steve Weis. Anthropic says its model Claude spotted the pattern in under half an hour.

Why the seeds mattered

NIST's prime curves, P-192 through P-521, are used for ECDSA, a common way to make digital signatures. Each curve was generated from a 20-byte seed. Under the ANSI X9.62 standard, the seed is hashed with SHA-1 to produce the curve's numbers. A random-looking seed is supposed to prove nobody picked a convenient curve.

The catch was that nobody knew where the seeds came from. They were handed over in 1997 by Jerry Solinas, an NSA mathematician who died in 2023. The story told for years was that they were hashes of English sentences. The worry was simple: if the seeds were freely chosen, someone could try many until one gave a weak curve. Valsorda now writes that the findings "completely rule out the technique described by Bernstein and Lange," two researchers who studied that risk.

How the seeds were made

The method was simple, according to both write-ups. A program passed the current Unix timestamp, the count of seconds since 1970, to srand48(). It then drew 20-byte candidates from the generator and tested each one. Candidates that failed the ANSI X9.62 rules were thrown away.

Claude's first clue was statistical. Anthropic says four of the seeds had a zero top bit in all 20 of their words, a 1 in 5,810 chance for truly random data. That pattern pointed to a weak 1990s generator, lrand48. The team then used lattice reduction, a math technique for recovering hidden numbers, to rebuild the generator's state.

Curve	Generator start (UTC)	Candidate used
P-192	May 18, 1997, 14:45:34	139
P-521	August 8, 1997, 01:12:04	1,136
P-256	August 16, 1997, 01:52:34	1,842
P-384	August 30, 1997, 14:50:08	2,688
P-224	April 3, 1998, 12:52:07	7,026

Crypto Briefing reports the same P-256 figures: timestamp 871696354 and seed C49D360886E704936A6678E1139D26B7819F7E90. Valsorda wrote his own Go version of the algorithm, and Anthropic released its code under the CC0 public-domain license.

What is still unexplained

The answer is not complete. Valsorda found an extra rule beyond ANSI X9.62: a curve is rejected if its order has more bits than the field it is built on. A second rule still escapes him, he writes. The method leaves about twice as many valid seeds as were published.

Anthropic lists the same gaps. Candidate 876 of the P-256 run also gives a valid curve, yet candidate 1,842 was used. The base points for P-224, P-256, P-384 and P-521 remain unexplained, and so does the seed for the binary curve B-163. Anthropic did explain six base points, including P-192's, through a different generator from a library called FreeLIP.

What this means for developers

Nothing in your code needs to change. Anthropic says the work is not a cryptographic break, a new attack or a weakness in the curves. Valsorda adds that practitioners had no serious concerns even before this.

What changes is the argument. Teams that avoided P-256 because its seeds were a mystery can revisit that choice with better evidence. Anthropic says the findings make a backdoor less plausible. The skipped candidates mean the choice is still not fully explained, so the debate narrows rather than ends.

If you work on cryptography, the reproduction code is worth reading. It shows how a statistical test plus lattice reduction can rebuild a generator's state from its output alone. That is a good reminder never to use lrand48 for anything secret.

The open questions are a fair puzzle for anyone curious. The second rejection rule and the missing base points are still unclaimed problems.