⏱️ Reading time: 9 min
A 26-year-old cryptographic mystery has been solved in under 30 minutes: the NIST curve seeds used by ECDSA didn’t come from a secret NSA hash, but from a 1990s random number generator seeded with the system clock. Anthropic revealed this on October 16, 2026, after asking an internal Claude research model to trace the origin of those parameters.
📑 En este artículo
The result isn’t a flaw or an urgent patch. It’s confirmation, almost three decades later, that those parameters were generated without hidden manipulation.
TL;DR
- Claude solved the 26-year-old mystery behind the ECDSA seeds in under 30 minutes.
- The seeds for P-192, P-224, P-256, P-384, and P-521 come from lrand48(), not a secret hash.
- Computing the P-256 seed took 1,842 iterations of a generator seeded with a Unix timestamp.
- Anthropic rules out backdoors: the method used is now reproducible by anyone.
- Jerry Solinas, the NSA engineer who died in 2023, left a clue in 2015 that turned out to be wrong.
What Is ECDSA
ECDSA is the elliptic curve based digital signature algorithm that NIST adopted in 2000 as part of the FIPS 186-2 standard, and it depends on a set of standardized curves whose NIST curve seeds remained publicly unexplained for 26 years.
Today, ECDSA signs TLS certificates, protects Bitcoin transactions, and authenticates SSH keys on millions of servers. Its security depends on the underlying elliptic curve, one of the five pairs defined by the FIPS 186-2 standard (P-192, P-224, P-256, P-384, and P-521), having no deliberately hidden mathematical weakness.
That curve is defined by an equation and a constant, called b, which in turn is calculated by applying a hash function to a 160-bit number: the seed. NIST published the seeds along with the curves in 2000, but never explained where those numbers came from.
Elliptic curves became popular over RSA because they achieve comparable security levels with much shorter keys, making them more efficient for mobile devices and high-volume connections. That efficiency partly explains why ECDSA dominates much of today’s modern TLS connections and the signatures of several elliptic curve based cryptocurrencies.
What Happened With the NIST Curve Seeds
On October 16, 2026, Anthropic published a research report describing how an employee asked an internal Claude model to figure out, with no prior clues, how those seeds were generated. The model took less than half an hour to find the origin of the parameters for P-192, P-224, P-256, P-384, and P-521.
The answer, according to the Anthropic report, is that each seed came from lrand48(), the pseudorandom number generator in Unix C libraries, initialized with a system timestamp. The original program took 20 bytes per generator round as a seed candidate; producing the published P-256 seed took 1,842 iterations.
Anthropic sums it up without drama: “there is no action to take and nothing to do differently,” the report says, presenting the finding as the final chapter of speculation that had already lasted more than two decades.
Context and History
The suspicion started in the standard’s own text. NIST published the P-256 seed as this hexadecimal string, with no footnote:
SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90Mathematicians Neal Koblitz and Alfred Menezes documented the controversy in the essay “A Riddle Wrapped in an Enigma,” and for years an informal reward circulated for anyone who could reconstruct the origin of those numbers.
The most cited clue came from Jerry Solinas, the NSA engineer who worked on the original design. In 2015, he said he recalled the seeds coming from a hash applied to a joking phrase, something like “Give Bob and Jerry a raise,” although he admitted that neither he nor his colleague Bob Reiter had kept the code or the details. Solinas died in 2023 without resolving the question, and according to Claude’s finding, the phrase clue turned out to be completely false.
Technical Details
Claude didn’t try to repeat the search for the joking phrase. Instead, according to the Anthropic report, it proposed a different hypothesis: that the software used in the 90s to generate the seeds relied on a pseudorandom generator typical of that era, and that the pattern of that generator could still be recognized in the published bytes.
To test it, it wrote a scanner that slid a bit window over each seed and compared adjacent blocks against 34 combinations of generator and output segment. That’s where the signal appeared: in four of the ten seeds analyzed, all 20 of the 32-bit words had their high bit set to zero. By chance alone, that coincidence has a probability of just 1 in 5,810.
That pattern is the signature of lrand48(), a linear congruential generator that only returns the top 31 bits of a 48-bit internal state. With that clue, Claude brute-forced the 2^17 possible values of the 17 hidden bits and confirmed that the next four words of each seed matched exactly.
The seeds for the five NIST prime curves (P-192, P-224, P-256, P-384, and P-521) and five more from the ANSI X9.62 standard retained even fewer bits per output, so brute force was no longer enough. For those ten, Claude solved a classic lattice problem using the Lenstra-Lenstra-Lovász (LLL) algorithm, testing every possible bit window until confirming the same pattern across all ten: lrand48() >> 23.
| Technique used by Claude | Where it was applied | What it solved |
|---|---|---|
| Bit by bit scan (34 combinations) | The 10 published seeds | Identify which 90s generator produced each seed |
| Brute force of 2^17 values | 4 seeds with high bit set to zero | Recover the hidden bits of the lrand48() state |
| LLL lattice reduction | 10 seeds (5 NIST primes + 5 ANSI X9.62) | Recover the truncated state of lrand48() >> 23 |
flowchart TD
A["Published seed (e.g. P-256)"] --> B["Bit by bit scan: 34 PRNG combinations"]
B --> C{"High bit zero in all 20 words?"}
C -->|"Yes"| D["Brute force of 2^17 hidden values"]
C -->|"No"| E["LLL lattice reduction"]
D --> F["Internal lrand48 state recovered"]
E --> F
F --> G["Iterations from a Unix timestamp (1,842 for P-256)"]💭 Key point: a probability of 1 in 5,810 isn’t mathematical proof, it’s a statistical signal. What turns the finding into solid evidence is that, beyond detecting the pattern, Claude reconstructed every published seed bit by bit, and all 10 matched exactly.
Impact and Analysis
The result doesn’t fix any active vulnerability. ECDSA remains exactly as secure (or insecure) as it was before October 16, 2026; what changes is the certainty about how its parameters were chosen.
For 26 years, the lack of explanation fueled the hypothesis that the NSA could have tried thousands of seeds until finding one that hid a weakness known only to itself. The fact that the entire process depends on a clock and a public generator, reproducible by anyone with a terminal, drastically reduces the room for that kind of manipulation.
The comparison with RSA is useful. The RSA algorithm doesn’t depend on parameters chosen by a third party: anyone can generate their own key pair from scratch. ECDSA, on the other hand, needs a shared standard curve, and that dependency is precisely what kept the suspicion about the origin of its parameters alive for more than two decades.
One honest doubt remains. The method shows how each seed was generated, but not how many attempts, meaning how many different timestamps, the NSA tried before settling on the published result. If someone had been able to repeat the process with thousands of timestamps and pick the most convenient curve, the clock alone wouldn’t have prevented it. Anthropic doesn’t address that scenario in its report, and it’s the piece that still depends on trust in the original process, not just on the math.
What’s Next
Anthropic doesn’t promise any follow-up action: the report explicitly calls it a “fun closing chapter.” There’s no patch, no new version of ECDSA, and no recommendation to migrate to another curve because of this.
What it does open is a precedent. Using a language model to reconstruct 30-year-old technical decisions from only the published bytes is a method that could be applied to other standards with parameters that were never explained. Cryptography has several more waiting for that same kind of archaeology.
Try it yourself: take the P-256 seed (C49D3608 86E70493 6A6678E1 139D26B7 819F7E90) and follow the full reasoning in Anthropic’s original report before deciding how much to trust a 26-year-old curve.
Frequently Asked Questions
What did Claude find about the NIST curve seeds?
It found that each seed, including P-256’s, is the direct result of the lrand48() generator initialized with a Unix timestamp, not a hash of a secret phrase as had been rumored since 2015.
Why did ECDSA’s parameters matter before this finding?
Because the NSA handed those seeds to NIST in 2000 without explaining their origin, and an elliptic curve with a deliberately chosen parameter could, in theory, hide a weakness known only to whoever chose it.
What is lrand48() and why does it matter for the P-256 curve?
It’s a pseudorandom number generator included in C libraries since the 1990s. The P-256 seed came from 1,842 iterations of that generator started with a system timestamp, and the same pattern appeared in nine other seeds from different curves.
Does this finding mean ECDSA has a backdoor?
No. It’s the opposite: by showing that the generation process was simple, public, and reproducible, the finding reduces the probability of a deliberate backdoor in the NIST curves, although it doesn’t completely rule out that many timestamps were tried before picking the published one.
What happened to Jerry Solinas’s clue about the FIPS 186-2 standard?
Solinas, the NSA engineer who helped design the standard, said in 2015 that he recalled a hash of a joking phrase as the origin of the seeds. He died in 2023, and Claude’s 2026 finding confirmed that this clue, repeated for eleven years, was incorrect.
References
- Anthropic Research: the original report where Claude reconstructs the origin of the NIST curve seeds.
- Wikipedia: history and technical specification of ECDSA.
- Wikipedia: how a linear congruential generator like lrand48() works.
- NIST Computer Security Resource Center: the official source for the FIPS 186-2 standard and its elliptic curves.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Foto de Patrick Martin en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments