19 OCT 2026 — The unexplained numbers behind P-256 and the other NIST elliptic curves came from an ordinary C library random-number generator started from the computer clock in 1997 and 1998. They were not hashes of a forgotten sentence. Anthropic said on 16 October that its Claude model had worked this out, and Filippo Valsorda, the cryptographer who had offered a bounty for the answer since 2023, confirmed the claim the same day after rebuilding the method himself.
Disclosure: RECATOOLS is written with the assistance of Claude, made by Anthropic, whose researchers and model are the subject of this article. Readers should weigh that interest.
Why the seeds drew suspicion
The curves were published in FIPS 186-2, the US Digital Signature Standard dated 27 January 2000. Each prime curve lists a 160-bit seed. Hashing that seed with SHA-1 produces one of the curve's coefficients, the idea being that a value pulled from a hash cannot have been hand-picked. That only reassures if the seed is innocent, and nobody outside the NSA, which supplied the seeds, could say where they came from.
The account that circulated for years came from Jerry Solinas, a long-serving NSA employee. He recalled hashing a joke phrase, something "along the lines of 'Give Bob and Jerry a raise'", in a 2015 statement that Anthropic quotes. Solinas died in early 2023 and the phrase was never found. Valsorda's bounty announcement of 5 October 2023 explained the stakes. P-256 and P-384 sit under the ECDSA certificates that protect much of the web, and some people distrusted the seeds because of the NSA's precedent with Dual_EC_DRBG, an earlier random-number standard. Valsorda himself said he did not think those fears were well founded.
What Claude found
Anthropic's research post says an employee asked an internal model to find where the seeds came from, without pointing it at the passphrase story. In under half an hour, the company says, the model recovered the origin of all five NIST prime-curve seeds, P-192 to P-521. Each is raw output from lrand48, the generator in standard Unix C libraries, initialised with a Unix timestamp.
The program drew 20 bytes at a time and tested each block as a candidate seed. The P-256 seed is candidate 1,842 from a run started at 01:52:34 UTC on 16 August 1997. Five seeds from the ANSI X9.62 standard follow the same pattern, and all ten prime-curve seeds trace to runs started between May 1997 and April 1998. Four of the five binary-curve seeds were also recovered, apparently from a clock value that was halved.
How the result was checked
Verifying the method is simpler than the original search. Old generators like lrand48 leave fingerprints. Four of the ten seeds examined had the top bit clear in every 32-bit word, a pattern Anthropic puts at 1 in 5,810 by chance. From there Claude recovered the generator's hidden state, using a standard lattice technique where only part of each output survived, and ran it backwards to the point where a timestamp would have started it. A recovered state reproduces the whole 160-bit seed, which a coincidence would not do.
Valsorda's announcement says the team claimed the bounty at 01:07:51 UTC on 15 October, and that he wrote his own version in Go to check it. He describes the generator as drand48. That function and lrand48 belong to the same POSIX family and step the same 48-bit state, so the two accounts agree.
We reran the P-256 derivation
RECATOOLS wrote its own short Python script from the parameters in Anthropic's post. The script sets the generator state as srand48 would for timestamp 871696354, which our Unix timestamp converter shows is 01:52:34 UTC on 16 August 1997. It then keeps the top eight bits of each step and takes the 1,842nd block of 20 bytes. The output was C49D360886E704936A6678E1139D26B7819F7E90, identical to the P-256 seed in FIPS 186-2. We also ran the standard's own seed-to-curve test, in which a SHA-1-derived value has to satisfy a fixed equation against the published coefficient b. It held. Candidate 1,841 from the same run gives an unrelated string.
That check has limits. It shows the published recipe regenerates the published seed. It does not show who ran the program or why, because no 1997 record of the run has surfaced. We did not independently check the other nine prime seeds or any base point.
What it means for P-256 users
P-256 users need not change anything. Anthropic's post says "This is not a cryptographic break, new attack, or weakness in the ECDSA curves," and that there is no action for anyone to take. Its argument is that a clock-seeded generator anyone can now rerun leaves little room to steer the result.
Valsorda goes further. He says the finding rules out a 2017 technique, described by Daniel Bernstein and Tanja Lange, for planting weak curves through freedom in seed choice. Even allowing any timestamp in 1997-98 and generous candidate skipping, he estimates "barely 30 bits of freedom", too little to target a rare class of weak curves. He now says he would personally recommend the NIST curves over Curve25519, while noting that they are about to be retired in favour of post-quantum signatures.
What is still unexplained
Anthropic's post leaves several questions open. Candidate 876 of the P-256 run also yields a usable prime-order curve, and P-224's run passed over three more, so not every valid candidate was used. The rule that picked the published ones is unknown. Anthropic says the small number of skips makes a deliberately weakened choice implausible, while conceding that searching across timestamps for some property is conceivable in principle.
The B-163 seed fits nothing tried so far. Claude did trace the base points of P-192 and five ANSI curves to the random-number generator in FreeLIP, Arjen Lenstra's arithmetic library, but how the base points were chosen for P-224 and the three larger NIST prime curves is still unknown. The post also prints the model's working notes. The model briefly asked whether it was inside a test environment, then checked the numbers and concluded the match was real.
View author profile → · Editorial policy
