Anthropic Says It Solved the Origins of NIST’s ECDSA Curve Seeds

Researchers say they have reconstructed how the seed parameters behind the most widely deployed elliptic curve cryptography standard were generated, removing a long-standing cloud over the provenance of the NIST P-192, P-224, P-256, P-384 and P-521 curves. The same internal model also matched base point recipes for six of the curves to a 1990s long-integer library, though the base points for the four NIST curves named above and the binary curves remain unexplained.

For business owners, the practical effect is simple. A standard that quietly secures HTTPS handshakes, code signing, software updates and payment flows has a partially reproducible history for the seeds it depends on. The reconstruction, according to Anthropic, does not trigger software updates, certificate changes or key rotations, because the seeds were never the hidden material that protects signing keys.

What Anthropic actually found

NIST adopted ECDSA in 2000 as part of the FIPS 186-2 Digital Signature Standard, which lists standard curves of varying sizes and security levels. For curves over prime and binary fields, the specification publishes a seed parameter whose hash value defines the coefficient b of the curve. The seeds were reportedly supplied by the NSA with no explanation or justification. Years of speculation included the theory that former NSA mathematician Jerry Solinas had generated them as the hash of a humorous passphrase such as “Give Bob and Jerry a raise,” a recollection he gave in 2015 before dying in 2023. His colleague Bob Reiter wrote the code but did not remember the details either.

Anthropic’s Frontier Red Team reports that, in October 2026, an employee asked an internal research model to determine how the seeds were generated without pointing at the rumored phrase clue. In under thirty minutes the model identified the source: the C library function lrand48, a pseudorandom number generator seeded with a Unix timestamp. No hash algorithm was involved.

The generator drew 20 bytes per iteration as a candidate seed. P-256, for example, was the 1,842nd candidate from its run, initialized on August 16, 1997 at 01:52:34 UTC. P-224 came 7,026 candidates into a run initialized on April 3, 1998. The prime-curve generation runs all map back to timestamps between May 1997 and April 1998.

How the recovery worked

With phrase searches exhausted, the model approached the problem from the generator side, scanning each published seed one bit at a time and testing whether adjacent chunks matched the output of any 1990s pseudorandom number generator. The scan covered 34 combinations of generator and output slices.

One pattern stood out. Four of the ten seeds had zero in the top bit for all twenty 32-bit words, an arrangement that would occur by chance with probability 1 in 5,810. That is a signature of lrand48, a linear congruential generator that returns the top 31 bits of a 48-bit internal state. With the prime-curve seeds, which retained fewer bits of each output, recovering the truncated state required a lattice reduction routine, the Lenstra-Lenstra-Lovász algorithm, run across every possible window. All five NIST prime-curve seeds plus five more from the ANSI X9.62 standard matched the same construction, lrand48() 23, and each recovered 48-bit state regenerates all 160 bits of its seed.

The four binary-curve initializations read as February 1984 when read directly. When doubled, they point to April 17, 1998, two weeks after the P-224 run, which Anthropic describes as a clue that the program may have halved the clock before seeding.

Anthropic also notes that the five NIST seeds, five ANSI X9.62 example seeds and the four binary seed reconstructions map to real calendar dates, and the recovery code on its publication page reproduces every value bit-for-bit. Anthropic plans to donate the $36,864 seed bounty to the Internet Security Research Group.

What remains open

The work does not close every question. Anthropic was not able to explain how the base points for P-224, P-256, P-384 and P-521 were generated, and the NIST binary curves’ base points are also unresolved. The fifth binary seed, B-163, fits no generation method the model tested.

Some viable candidates were skipped during the runs. P-256’s published seed is candidate 1,842, but candidate 876 of the same run also yields a prime-order curve of the required size with parameters chosen the same way. The P-224 run passed over three such curves, and the two ANSI X9.62 example runs passed over seven more. Anthropic says the small number of skipped candidates makes deliberate selection of weakened curves implausible, but the selection criterion is unknown.

A separate, long-running critique of these curves is summarized in the paper “A Riddle Wrapped in an Enigma” by Neal Koblitz and Alfred Menezes, which catalogs historical concerns about the seeds and the design choices around them.

What this means for the trust picture

Anthropic is explicit that this is not a cryptographic break, a new attack or a weakness in ECDSA. The seeds are public parameters used to derive curve shapes, not private signing keys. According to Anthropic, reconstructing them does not let an attacker forge signatures.

What changes is the trust story. Before the result, the seeds were published numbers whose origin no one could verify. After it, the article says the seeds can be reproduced from a common, dated pseudorandom number generator and a clock. That can remove one of the persistent grounds for suspecting a backdoor in the curves, and it may give cryptographers and auditors a concrete generation method to check against any future curve proposal.

What to do now

1. No software patches, certificate re-issuances or key rotations appear to be warranted by this finding, since the seeds are public curve parameters and not secret material.
2. Treat this as a clarification of the trust history behind ECDSA rather than an alert, since ECDSA has not been openly broken and no new attack has surfaced.
3. For risk documentation, customer security questionnaires and security pages, you can note that the NIST curve generation method is now publicly reproducible from a 1990s C library random-number generator, which may lower the prior suspicion of a hidden backdoor.
4. If your stack depends on ECDSA P-256, P-384 or P-521, no migration may be needed at this time; if you have already moved to post-quantum signatures for other reasons, this finding does not change that decision.
5. Watch for any future NIST update that explains the remaining base points and the B-163 seed, since those are the open pieces of the provenance story.

Neal Koblitz and Alfred Menezes reviewed the concerns about these seeds in their paper “A Riddle Wrapped in an Enigma,” a reference point for the cryptographic community during the years the seed origin stayed open.

FAQ

Did the NIST curve seeds contain a backdoor?

No. Anthropic reports that the seeds were produced by a common pseudorandom number generator, lrand48, initialized with Unix timestamps in 1997 and 1998. Reproducible generation from a weak but ordinary PRNG is the opposite of a concealed design choice.

Does this finding break ECDSA?

No. The seeds are public curve-generation parameters, not private signing keys. Anthropic states explicitly that the work is not a cryptographic break, a new attack or a weakness in the curves.

Should businesses using ECDSA P-256 rotate keys or change certificates?

No. The result is a historical reconstruction of how the curve parameters were generated. The result does not appear to expose signing keys, enable signature forgery, or require any operational change.

See our editorial disclaimer for how our articles are produced.