Research published by Anthropic’s Frontier Red Team shows that the seed values behind the most widely used ECDSA elliptic curves, NIST P-192, P-224, P-256, P-384, and P-521, were produced in 1997 and 1998 by a common Unix pseudorandom number generator initialized from a timestamp, not by hashing any text at all. The finding closes a 25-year-old open question in cryptography and, according to Anthropic, strengthens confidence that the curves were chosen without hidden backdoors.
Why the NIST curve seeds were a mystery
ECDSA is the most widely used elliptic curve cryptography standard. It was adopted by the NSA and standardized by NIST in the FIPS 186-2 Digital Signature Standard, published in 2000. The standard lists curves of different sizes and security levels, and for each curve it specifies a seed value. For the curves over prime and binary fields, the FIPS 186-2 specification describes that the seed is used to define the coefficient b of the curve, with a seed parameter whose hash value is used to define the coefficient b. The seeds were provided by the NSA with no explanation of how they had been produced.
One example given in the Anthropic write-up is the seed for NIST P-256:
SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90
No source, no construction rule, and no rationale were published with it. Cryptographers Neal Koblitz and Alfred Menezes summarized the concern in a paper they titled A Riddle Wrapped in an Enigma, which discusses the history and concerns around the seed values.
The decades-old rumor that wasn’t true
For years the best-circulating story was that a longtime NSA employee, Jerry Solinas, had generated the seeds by hashing a humorous phrase such as ‘Give Bob and Jerry a raise’ or ‘Bob and Jerry rule’. Solinas, asked about the story in 2015, said the program used a counter rather than multiple hashing and that he did not know details, adding: ‘If they exist, they are no doubt sitting on a hard drive near the Ark of the Covenant.’ Solinas died in 2023, and other colleagues from that period did not respond to queries.
The rumor inspired an amateur investigation into the origin of the seeds and a bounty for anyone who could find them, but searches for the supposed humorous phrase came up empty.
How a model cracked it in under 30 minutes
In October 2026, an Anthropic employee asked an internal research model to figure out how the seeds had been generated without pointing it at the existing clue. In under half an hour, the model recovered the origins of all five prime-field seeds plus four of the five binary seeds, reproducing every one of them bit-for-bit.
The seeds were not the result of any hash algorithm at all. They were the output of the C library’s lrand48 random-number generator, seeded with a Unix timestamp. The procedure samples bytes from the random number generator initialized by a Unix timestamp for some number of iterations, drawing 20 bytes per candidate. The first 20 bytes are candidate 1, the next 20 bytes are candidate 2, and so on. NIST P-256, for example, required 1,842 iterations of this loop to output the published seed.
What the model did to recover the seeds
The model took a different angle than the phrase-hunting amateurs had. It anticipated what software from that era most likely did: use a pseudorandom number generator that shipped with 1990s C libraries. Those PRNGs are weak enough that their output can be recognized.
The model wrote a scanner that slid along each published seed one bit at a time and tested whether adjacent chunks were consecutive outputs of a 1990s-vintage generator. The scan covered 34 combinations of generator and output slices. A clear pattern quickly emerged: four of the ten prime seeds have a 0 in the top bit for all 20 words when written as five 32-bit words. By chance, that would happen with probability 1 in 2 to the 10th, roughly. That pattern is the signature of the linear congruential generator lrand48, which only returns the top 31 bits of a 48-bit state and leaves the top bit of every output word as 0.
To recover the internal state, the model took the first word, tried all 2 to the 17 possible values of the 17 hidden bits, and checked that the next four words followed. That worked for all four seeds. For the prime-curve seeds, which keep fewer bits of each output, the model turned to a textbook lattice method, the Lenstra-Lenstra-Lovász basis reduction algorithm, to reconstruct the truncated state. Recovering each 48-bit state regenerates all 160 bits of its seed, which does not happen by chance.
The Unix timestamps recovered
Once the PRNG state was known, the model stepped each one backwards until it reached the initialization form that srand48 would have used, with the low 16 bits equal to 0x330E. For the ten prime curves, every recovered initialization timestamped a date between May 1997 and April 1998. The four binary curves’ initializations read as February 1984, but with the timestamps doubled they mapped to April 17, 1998, two weeks after the P-224 run. The program appears to have halved the clock.
The recovered dates and iteration counts, drawn directly from Anthropic’s published reproduction code, are:
- prime239v1, May 15, 1997 at 15:49:03, candidate 2,185
- prime239v2, May 15, 1997 at 15:49:03, candidate 2,320
- prime239v3, May 15, 1997 at 15:49:03, candidate 3,048
- P-192, May 18, 1997 at 14:45:34, candidate 139
- prime192v3, May 18, 1997 at 14:45:34, candidate 5,228
- prime192v2, May 18, 1997 at 14:45:34, candidate 6,013
- P-521, August 8, 1997 at 01:12:04, candidate 1,136
- P-256, August 16, 1997 at 01:52:34, candidate 1,842
- P-384, August 30, 1997 at 14:50:08, candidate 2,688
- P-224, April 3, 1998 at 12:52:07, candidate 7,026
- B-233, April 17, 1998 at 15:24:18, candidate 155
- B-283, April 17, 1998 at 15:27:44, candidate 32
- B-409, April 17, 1998 at 15:30:18, candidate 60
- B-571, April 17, 1998 at 15:32:08, candidate 73
Anthropic published Python code that takes each datetime plus iteration count and produces the published seed, and the program output matches the standards byte-for-byte.
What the finding means for ECDSA security
Anthropic emphasizes that this is not a cryptographic break, a new attack, or a weakness in the ECDSA curves. If anything, the result makes backdoor theories harder to defend: the seeds were produced by a very simple construction that anyone can now reproduce from a known Unix timestamp and a small integer iteration count. As the researchers put it, ‘It is still conceivable that these curves were selected to have a specific property in principle by searching over timestamps to the random number generator. However, you would only need to do that if you were going to disclose the timestamp as some evidence that the seed was innocuously generated.’
Base points: most explained, four still unknown
Each ECDSA curve also specifies a base point G, the public point that every ECDSA key is a multiple of. The seed does not determine G. The model also recovered where some of the base points came from. The base points of the six curves generated in May 1997 (P-192 and the five ANSI X9.62 example curves, prime192v2, prime192v3, and prime239v1 to v3) come from the random-number generator in FreeLIP, Arjen Lenstra’s long-integer arithmetic package; early versions of Victor Shoup’s NTL library shipped the same code. The recipe is to seed the generator with a small integer, throw away seven outputs, then generate candidate x-coordinates from 26-bit outputs reduced mod p, repeating until x lands on the curve.
Anthropic lists the recovered FreeLIP seeds: 20,000 for P-192; 20,420, 20,507, and 20,509 for prime239v1 to v3; and 20,512 and 20,517 for prime192v2 and v3. The base points of P-224, P-256, P-384, and P-521 do not fit this recipe, and the NIST binary curve base points also remain unexplained.
What remains open
Not every 20-byte candidate from each run produced a viable curve, and some viable curves were skipped. For P-256, the published seed is candidate 1,842, but candidate 876 of the same run also gives a prime-order curve of the right size with parameters chosen the same way. P-224’s run passed over three such curves, and the two runs behind the ANSI X9.62 example curves passed over seven more. The researchers do not know what criteria were used and whether the skips were intentional. They note that the number of skipped candidates is small, so weakened-curve selection is unlikely.
The fifth binary seed, B-163, fits none of the attempted reconstructions and remains unexplained.
The bounty and the team
The NIST Elliptic Curves Seeds Bounty, organized by Filippo Valsorda, awarded $36,864, which Anthropic said will be donated to the Internet Security Research Group. The work was conducted at Anthropic by John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini, and Steve Weis. Anthropic also posthumously recognized Jerry Solinas for taking the long-running speculation about his work in good humor.
FAQ
What did Anthropic actually discover about NIST curve seeds?
According to Anthropic’s write-up, the seeds for NIST P-192, P-224, P-256, P-384, P-521, and four binary curves are outputs of the C library’s lrand48 random-number generator, initialized from a Unix timestamp in 1997 or 1998, not hashes of any text. Anthropic published Python code that regenerates each seed exactly.
Does this mean ECDSA has a backdoor?
Anthropic states that the finding is not a cryptographic break or weakness and argues it makes hidden backdoors less plausible, because the seeds were produced by a simple, reproducible procedure.
What is still unknown about the NIST curves?
One of the five binary seeds, B-163, was not recovered. The base points for P-224, P-256, P-384, P-521, and the NIST binary curves have not been explained, and there is no published account of why some viable candidate curves in each run were skipped.