On October 16, 2026, Anthropic announced that it had determined that the "seeds" for the NIST standard elliptic curves used in the ECDSA digital signature scheme were generated from timestamps in 1997 and 1998. The company says its internal research AI model, Claude, worked out how the seeds were generated in under 30 minutes, and it has published code that reproduces the origin of the seeds, a question that had long gone unanswered. Cryptography engineer Filippo Valsorda, who had put up a bounty for solving this problem, also reported that he verified the results with his own implementation. The findings ease suspicions that weaknesses were deliberately built in during the selection of the standard curves, but questions remain about why certain candidate curves were chosen over others and where some of the base points came from.
A 20-byte seed generated from a 1997 timestamp
The research concerns five elliptic curves over prime fields standardized by the U.S. National Institute of Standards and Technology (NIST). Curves such as P-256 come with a "seed," a public value used to derive the curve's coefficients. The procedure of running this seed through SHA-1 and deriving the curve parameters from the result has long been known. However, the National Security Agency (NSA), which supplied the curves, reportedly never explained how the seeds themselves were chosen.
This opacity fueled suspicion that curves with deliberate weaknesses might have been selected. For example, the P-256 seed is a 160-bit value, written in hexadecimal as C49D360886E704936A6678E1139D26B7819F7E90. Because the value is public, the curve parameters can be recomputed from it. But why this particular value was adopted was unknown, and the transparency of the selection process remained a long-standing concern.
The generation method Anthropic uncovered is relatively simple. First, a Unix timestamp is used to initialize lrand48, the pseudorandom number generator in the C standard library, and the upper 8 bits of its output are taken one byte at a time. Twenty bytes are collected to form a seed candidate, and the corresponding curve is checked to see whether it meets certain conditions. If it is not accepted, the next 20 bytes are used to build a new candidate, and the process repeats.
For P-256, the time used to initialize the random number generator was 01:52:34 UTC on August 16, 1997, and the seed that was adopted was the 1,842nd candidate. This makes it possible to reproduce a 160-bit value of unknown origin from a specific time and candidate number. Previously, some had speculated that the seed was derived from a hash of some text, but this discovery points to a different generation method. It is, however, a finding about how the seed was produced, and it does not overturn the known process of deriving curve parameters from the seed using SHA-1.
Identifying the 1997 timestamp from the random number generator's traits
According to Anthropic, rather than searching for the text the seeds were derived from, Claude focused on the random number generators used in 1990s software. A pseudorandom number generator bundled with a C library of that era might leave a distinctive pattern in its output. The idea was to work backward from the numerical characteristics of the published seeds to narrow down the software used to generate them.
The clue was that when some of the seeds were split into 32-bit units, the most significant bit was always 0. lrand48 outputs values whose most significant bit is 0, so lining up its output would show the same kind of bias. However, the seeds used for the NIST prime-field curves retained only part of the random number generator's output. Confirming the bit bias alone was therefore not enough to pin down the generator's internal state.
Claude therefore applied the LLL algorithm, a lattice basis reduction technique, to the problem of recovering the internal state from partially missing output. This method recovered the 48-bit internal state, from which the full 160 bits of the seed could be reproduced. By then stepping the generator's state backward, Claude identified a state in the form produced by the initialization function srand48. When that value was examined, it corresponded to Unix timestamps between May 1997 and April 1998.
Still, finding numbers that correspond to dates in the 1990s is not by itself sufficient proof that the seed generation method has been solved. What supports the explanation is that the published seeds can be reproduced exactly from start to finish, and that the same use of the random number generator was confirmed across multiple curves. Note also that the "under 30 minutes" figure is the time Anthropic reported for this search, not a measurement of any AI product's general problem-solving ability. The company describes the model used as an internal research version of Claude.
Even with the seeds' origin known, questions about curve selection remain
For the five NIST prime-field curves, the generation method was reproduced for every seed, but the origin of the curve's "base point" was uncovered only for P-192. The base point is the predetermined point G on the elliptic curve, the starting point for computing public keys. The seed determines the curve's coefficients, so knowing how it was generated does not automatically reveal how the base point was chosen.
Based on the reproduction code and the explanation of base points published by Anthropic, what has been found about the five NIST prime-field curves can be summarized as follows. The dates in the table are the Unix times believed to have been used to initialize the random number generator, expressed in UTC. ANSI X9.62's example curves and the binary-field curves are not included.
| NIST curve | Date and time corresponding to seed generator initialization (UTC) | Number of adopted candidate | Origin of base point |
|---|---|---|---|
| P-192 | May 18, 1997, 14:45:34 | 139 | Reproduced with FreeLIP's generator |
| P-224 | April 3, 1998, 12:52:07 | 7026 | Unresolved |
| P-256 | August 16, 1997, 01:52:34 | 1842 | Unresolved |
| P-384 | August 30, 1997, 14:50:08 | 2688 | Unresolved |
| P-521 | August 8, 1997, 01:12:04 | 1136 | Unresolved |
For the P-192 base point, it turned out that the random number generator of FreeLIP, a multiple-precision integer arithmetic package, had been used. It can be reproduced by initializing the generator with a small integer, discarding the first seven outputs, and then searching for an x-coordinate that works as a point on the curve. Anthropic confirmed the same generation method for the five example curves included in ANSI X9.62. The base points of the remaining four NIST prime-field curves, including P-256, could not be reproduced this way.
Furthermore, even with the seed generation method known, the reason a particular seed was adopted from among many candidates is not fully explained. For P-256, for example, the 1,842nd candidate was adopted, but an earlier one, the 876th, also yields a curve with a suitably sized prime order. In other words, finding a candidate that meets the basic conditions did not mean it would be adopted. P-224 also skipped three candidates, so identifying the random number generator and working out the criteria used to screen candidates remain separate problems.
The detailed examination of this question comes from the report by Filippo Valsorda, who had offered the bounty. He implemented the generation procedure independently in Go and pointed out that the conditions described in ANSI X9.62 alone could not reproduce the candidate selection, and that there are two additional undocumented conditions. One of them excludes candidates whose curve order n has a bit length exceeding the bit length of the prime p that defines the curve. This is not simply a requirement that n be smaller than p; in ANSI X9.62's example curve prime239v2, n is in fact larger than p.
Even with this condition added, however, not all of the rejected candidates can be explained. Valsorda has considered possibilities such as the curve validation process consuming the same random sequence, or bugs in the programs of the time, but has not found a mechanism that explains the remaining mismatches. Even so, with the seed generation procedure now reproducible, it is possible to examine which candidates were skipped, and why, based on specific numbers. What was once a vague question about the opacity of the selection process has been reframed as a verifiable technical problem.
Suspicion of deliberate weaknesses recedes, but this is not a complete proof of security
Anthropic explains that this result does not reveal a new attack or vulnerability in ECDSA curves, but strengthens confidence that the curves were chosen without deliberately built-in weaknesses. What was recovered is the internal state of the random number generator used when the public parameters were generated, not the private keys held by ECDSA users. The discovery therefore does not leak any existing private keys or immediately undermine the security of digital signatures. The company is not asking users to change their settings or how they use the technology.
Valsorda has also assessed how much room there was to build a deliberate weakness into the curve selection process. Even assuming the selector could pick any time in 1997–1998 and freely choose among the first 16 candidates with prime order, the degrees of freedom available would be only about 30 bits. That is far below the 70 bits of freedom assumed by a specific backdoor hypothesis discussed in the past. He therefore takes the view that methods based on that hypothesis can be ruled out, but this is an assessment based on certain assumptions and does not mean the security of the NIST curves in general has been mathematically proven.
The explanation also has limits in scope. The seed for the binary-field curve B-163 remains unexplained, and for the other four binary-field curves, the interpretation that the random number generator was initialized with half the timestamp comes with reservations. The results published so far consist mainly of Anthropic's technical explanation and reproduction code, along with Valsorda's independent implementation and verification report. The process from generation to adoption has not been completely explained for every curve.
According to Valsorda, Anthropic's research team claimed the bounty on October 15. Because they chose to donate it, the prize tripled to $36,864 and will go to the Internet Security Research Group (ISRG), the nonprofit that runs Let's Encrypt. The long-running bounty over the origin of the seeds has been settled, but the reasons for rejecting certain candidates and the unresolved base points will require further evidence about the programs of the time and the developers' decisions. The significance of the result is that it makes the generation process of the standard curves, which previously had to be left to speculation, verifiable through specific timestamps and code.