Claude's reconstruction of P-256's origins reaches an apparently acceptable curve at candidate 876. The published standard uses candidate 1,842. That gap, documented in cryptographer Filippo Valsorda's verification, survives the recovery of a seed whose unexplained origins troubled cryptographers for decades. Developers now have a reproducible account of where the number came from, with part of the selection process still missing.
Anthropic announced on October 16 that an internal research model recovered the origins of the seeds for all five NIST prime curves, including P-256, in under half an hour. The result explains public mathematical parameters. It doesn't recover anyone's private signing key or disclose a new attack on ECDSA.
Why an old seed attracted a bounty
P-256's seed has been visible all along. In NIST's historical FIPS 186-2 specification, it appears as C49D360886E704936A6678E1139D26B7819F7E90, alongside the curve coefficient and base-point coordinates. The standard describes how a seed feeds a SHA-1-based procedure that generates curve parameters. Anyone could check that relationship. The missing information was how this particular starting value had been chosen.
Steve Weis's investigation, first published in September 2023, traced the seeds to NSA mathematician Jerry Solinas. Alfred Menezes, the primary author of the ANSI ECDSA standard, told Weis that Solinas had supplied them to the standards committee. Solinas's later recollection pointed toward hashing a humorous English message, possibly involving a counter. The exact message and hashing details had been forgotten. Weis also reported unsuccessful attempts to obtain records through information requests.
That recollection shaped the search. Valsorda's October 2023 bounty announcement offered $12,288 for recovering the origins of the five seeds, with a charitable donation option worth three times as much. It framed the task as a historical password-cracking problem. Valsorda already considered deliberate weakening implausible, but wanted evidence that could settle lingering suspicion. The assignment was to explain existing numbers, rather than design replacement curves.
The stakes reach ordinary web software. The original bounty announcement points to P-256 and P-384 in ECDSA certificates used to secure web connections. Explaining their origins gives people maintaining certificate systems a checkable answer to a recurring trust question. The bounty sought historical evidence about parameters already built into those systems, so a successful solution could increase confidence without requiring a protocol change.
A clock reading reproduces the published value
The recovered recipe uses the C library's drand48 family of pseudorandom generators. The Linux man-pages documentation specifies a 48-bit internal state and a fixed arithmetic recurrence. Calling srand48 puts the supplied argument into the upper 32 bits and sets the lower 16 bits to 0x330E. Once initialized, the generator follows a repeatable sequence. Its apparent randomness doesn't prevent someone with the starting state from calculating every subsequent output.
Valsorda's Go implementation groups the generator's output into 20-byte candidate seeds. For P-256, the starting argument is 871696354, corresponding to August 16, 1997, at 01:52:34 UTC. The 1,842nd block matches the standardized seed. The implementation also reconstructs streams that produced multiple published ANSI curves from a single initialization, rather than assuming a fresh clock reading for every curve.
We reproduced the P-256 byte sequence locally and compared it with the value in FIPS 186-2. This short Python calculation is enough to repeat that check:
state = (871696354 << 16) | 0x330E
candidate = bytearray()
for i in range(20 * 1842):
state = (0x5DEECE66D * state + 0xB) % (1 << 48)
if i >= 20 * 1841:
candidate.append(state >> 40)
print(candidate.hex().upper())
The output was C49D360886E704936A6678E1139D26B7819F7E90, an exact match. Our check covers the byte-generation claim. It doesn't independently test the mathematical suitability of every earlier candidate. NIST's curve-generation procedure includes further steps between an arbitrary seed and an acceptable curve, so regenerating the bytes is a narrower operation than validating the complete selection history.
How Claude approached the search
According to Anthropic's account, Claude searched for traces of older pseudorandom generators instead of following the forgotten-message story. Zero high bits in several seeds suggested lrand48, which returns 31-bit values. For the prime-curve seeds, recovering hidden generator state required lattice reduction, a mathematical technique for solving structured integer problems. Reversing the generator then exposed initialization values corresponding to dates in 1997 and 1998.
The documented relationship between lrand48 and drand48 explains the different names in the reports. Both advance the same kind of 48-bit state, then expose output in different forms. lrand48 returns a nonnegative integer below 2³¹, while drand48 returns a floating-point value below one. Reproducing the extracted bytes matters more than which interface name appears in a summary.
The rejected candidates still need an explanation
The Go verifier distinguishes generating candidate bytes from testing the resulting curves. Its checks include prime order and resistance to specified mathematical weaknesses. It also applies an inferred rejection rule: the curve order must not require more bits than the field prime. Even after those checks, its comments identify unpublished candidates in several streams. P-256's candidate 876 is among them. Recovering the generator therefore leaves a separate question about acceptance decisions.
Valsorda's account offers possible explanations, including a validation routine consuming output from the same generator or an old implementation bug. He reports no good fit. Neither suggestion is an established account of what the original program did. His security assessment is nevertheless reassuring: the recovered timestamp-based process leaves substantially less freedom to choose a specially weakened curve than an arbitrary 160-bit seed would.
The bounty has been claimed. In his confirmation, Valsorda records the claim on October 15 and says the Anthropic team chose to send the $36,864 charitable award to the Internet Security Research Group, which operates Let's Encrypt. Acceptance of the result establishes that it met the bounty's requirements. It doesn't supply the missing reason for each rejected candidate.
What changes for developers
ECDSA uses public curve parameters alongside separately generated private keys. FIPS 186-5 describes a private key d and public key Q, with the latter calculated from the former and a public base point. Reconstructing the historical input used to define the curve doesn't calculate d. If your application signs data using P-256, the recovered timestamp isn't a newly exposed application credential.
NIST explicitly allows domain parameters to be public and shared by a group of users, remaining fixed for an extended period. That makes their generation history a different security question from the secrecy of a particular signing key. Everyone using the same curve can inspect its defining numbers. The cryptographic design already assumes those numbers are available to an attacker, too.
The same signature standard requires protection of the private key and the per-message secret numbers used in signing. It also specifies deterministic ECDSA, which derives the per-message secret from the message and private key to avoid failures caused by insufficient signing randomness. Those requirements concern secrets created during operation. They remain relevant regardless of how the public curve's historical seed was generated.
The next useful result would explain why acceptable candidates were skipped. Anthropic also leaves other gaps open: the B-163 seed remains unexplained, as do the base-point origins for P-224, P-256, P-384 and P-521. A recovered recipe or further reproducible calculation could resolve those questions. For now, P-256's seed can be regenerated exactly, while the choice to pass over candidate 876 still needs evidence.