Anthropic: Claude traced the NIST elliptic-curve seeds in half an hour — not hashes, just lrand48 plus 1997 Unix timestamps

Start with the problem itself. ECDSA is the most widely used elliptic-curve cryptography standard, adopted by NIST in 2000 as part of the FIPS 186-2 Digital Signature Standard. For curves over prime and binary fields, the specification publishes a 'seed' parameter whose hash defines the curve's coefficient b. The trouble is provenance: the seeds were provided by the NSA with no explanation or justification. NIST P-256's seed, for instance, is C49D3608 86E70493 6A6678E1 139D26B7 819F7E90, and nobody knew where it came from. Koblitz and Menezes wrote a survey, 'A Riddle Wrapped in an Enigma', devoted to the controversy.

The most popular story was 'a hash of a humorous passphrase'. Jerry Solinas, a longtime NSA employee, said in 2015 that he believed a counter rather than repeated hashing was used, that the message was along the lines of 'Give Bob and Jerry a raise' or 'Bob and Jerry rule', that Bob Reiter actually wrote the code, and that Reiter did not remember the details either. Solinas died in 2023 and colleagues from that period did not respond, so the trail went cold. Anthropic says several employees chased that theory without success — it turned out to be wrong.

The real answer is about method. Anthropic writes that in October 2026 a curious employee asked an internal research model whether it could figure out how the seeds were generated without any hints. In under half an hour, Claude found the origins of the P-192, P-224, P-256, P-384 and P-521 seeds — none of them the output of any hash algorithm, but of the C library's lrand48 generator seeded with a Unix timestamp. The mechanism: initialise the generator with timestamp t, draw 20 bytes per round as a candidate seed, so the first 20 bytes are candidate one, the next 20 candidate two, and so on. P-256 needed 1,842 iterations to produce the standardised seed.

How it was found is more interesting than the answer. Searching for hashes of joke phrases found nothing, so Claude changed angle: assume the software that generated the curves used a pseudorandom generator shipped with 1990s C libraries. Those old generators are weak enough that their output can be recognised, and recognising it can reveal the initial state. It wrote a scanner that slid along each published seed one bit at a time, testing whether adjacent chunks were consecutive outputs of a 1990s-vintage generator across 34 combinations of generator and output slice. Then it noticed a pattern in the top bits: written as five 32-bit words, four of the ten seeds have a zero in the top bit across all 20 words, which would happen by chance with probability 1/5,810. That is the signature of the linear congruential generator lrand48, which returns only the top 31 bits of a 48-bit state. The state was recovered by taking the first word, trying all 2^17 values of the 17 hidden bits and checking whether the next four words followed — it worked for all four seeds.

The prime-field seeds came from the same generator but kept fewer bits of each output, so the internal state had to be recovered from truncated output. Anthropic says that is a textbook lattice problem, solved with the Lenstra–Lenstra–Lovász (LLL) basis-reduction algorithm. Because it did not know which bits of the state the seeds might expose, the model ran the solver over every window. All five NIST prime-curve seeds plus five more from ANSI X9.62 showed the same pattern: lrand48() >> 23, and each recovered 48-bit state regenerates all 160 bits of its seed, which does not happen by chance. The timeline fell out too: every srand48 initialisation for the ten prime seeds was a Unix timestamp between May 1997 and April 1998, while the four binary-curve initialisations read as February 1984 and, with the timestamps doubled, map to April 17, 1998 — two weeks after the P-224 run, suggesting the program may have halved the clock.

State the conclusion the way the original does, without inflating it. Anthropic says plainly: this is not a cryptographic break, not a new attack, not a weakness in the curves; if anything it makes it more plausible that the curves were chosen without backdoors or deliberate weaknesses. People distrusted the NIST parameters because they arrived without any account of how they were chosen. It now looks like the seeds were generated in a very simple way — a common pseudorandom generator initialised from the clock, reproducible by anyone — which leaves far less room for subversion. The page also says outright that readers should treat this as a fun closing chapter, with no action to take and nothing to do differently.

The boundaries need stating too. First, this is Anthropic's own account, including the 'under half an hour' timing claim, with no third-party reproduction log; however, they published reproducible code under CC0, including a script that regenerates the ten prime-field and four binary-field seeds and code that generates base-point x coordinates via LIP's zrandom and checks them against the published points, which makes the result independently testable. Second, gaps remain: the fifth binary seed, B-163, fits nothing tried and is still unexplained, and nobody knows how the base points for P-224, P-256, P-384 and P-521 were generated, or those of the NIST binary curves. Third, the original notes that some candidates were skipped: P-256's candidate 876 also yields a prime-order curve with parameters chosen the same way, the P-224 run passed over three such curves, and the two runs behind the ANSI X9.62 examples passed over seven more, with the selection criteria unknown. Anthropic's judgement is that so few candidates were skipped that selecting weakened curves is implausible, but no definitive answer is offered. Fourth, none of this changes anyone's security configuration; it is not a reason to touch your TLS settings.