Claude Solved the Mystery Behind NIST’s ECDSA Curves

For more than twenty-five years, a small unexplained detail sat underneath an enormous share of the internet’s security: nobody outside the original designers could say where the seed values for several standardized elliptic curves came from. On October 16, Anthropic published a surprisingly concrete answer. An internal Claude research model traced the seeds behind widely used NIST curves to the output of lrand48, a simple C-library pseudorandom number generator initialized with Unix timestamps in 1997 and 1998. This is not a new attack on ECDSA, and organizations do not need to rotate keys because of it. The importance is subtler: a reproducible explanation has replaced decades of suspicion around a foundational cryptographic standard—and an AI system found the trail by combining code generation, statistical observation, and old-fashioned cryptanalysis.

The discovery immediately drew attention on Hacker News, where it passed 800 points within a day. That reaction makes sense. ECDSA signatures protect software updates, TLS certificates, secure boot chains, hardware tokens, cryptocurrencies, and countless authentication systems. A weakness in the underlying curves would have consequences far beyond one library or vendor. Anthropic’s result instead provides evidence that the curve parameters were generated by a mundane, historically plausible process. It closes part of a famous mystery while also showing how capable AI systems can help audit the undocumented decisions embedded in old infrastructure.

Why Unexplained Curve Seeds Became a Security Problem

Elliptic-curve cryptography does not rely on one universal curve. A standard names specific mathematical parameters: a finite field, an equation, an order, and a base point used for key generation and signatures. NIST’s FIPS 186-2 standard, adopted in 2000, included curves such as P-192, P-224, P-256, P-384, and P-521. Each prime-field curve also carried a 160-bit seed. Hashing that seed was part of the documented recipe for deriving one coefficient of the curve, which suggested that the curve had been generated rather than hand-picked.

The problem was provenance. The NSA supplied the seeds, but the published standard did not explain how they were chosen. A seed can demonstrate that a designer did not freely manipulate every bit of a parameter only when the seed itself comes from a process that observers can understand. An unexplained random-looking value is not a proof of honest generation; it merely moves the trust question one step backward. Researchers could verify that the published seed produced the published coefficient, but they could not verify why that seed—and not another—was used.

That ambiguity mattered because cryptographic history contains examples of deliberately weakened standards. The Dual_EC_DRBG random-number generator, standardized years later, included elliptic-curve points whose relationship could enable a backdoor. Documents disclosed by Edward Snowden intensified concern about NSA influence over cryptographic standards. NIST eventually withdrew its recommendation for Dual_EC_DRBG. Although that controversy did not prove anything was wrong with the NIST signature curves, it made unexplained curve parameters harder to dismiss as harmless paperwork.

Cryptographers Neal Koblitz and Alfred Menezes documented the debate, and independent researchers searched for memorable phrases that might hash to the seeds. A story circulated that the designers had used a joke such as “Give Bob and Jerry a raise.” No one could reproduce it. A public bounty eventually offered $36,864 for the origin of the seeds. The question remained open not because ECDSA signatures were failing, but because high-assurance cryptography should minimize the number of things users must accept on authority.

How Claude Reconstructed a 1990s Generation Process

Anthropic reports that a researcher gave an internal Claude model the problem without steering it toward the old passphrase theory. The model instead asked what software an engineer in the late 1990s would likely have used. That framing was productive. If the values came directly from a period C library’s pseudorandom generator, the generator’s structure might still be visible in the published bits.

Claude wrote a scanner that moved across the seed data one bit at a time and tested 34 combinations of old generators and output slices. It noticed that the high bits of multiple words were zero more often than chance would reasonably predict. That pattern matched lrand48, a linear congruential generator with a 48-bit internal state that returns 31 output bits. Once the candidate generator was identified, recovering its state became tractable: the model could enumerate the hidden bits for some seeds and check whether subsequent words followed the recurrence.

The prime-curve seeds exposed fewer bits from each generator step, which made the reconstruction more difficult. Claude treated that as a truncated linear-congruential-generator problem and used Lenstra–Lenstra–Lovász lattice basis reduction to recover candidate internal states. Anthropic says all five NIST prime-curve seeds and five ANSI X9.62 example-curve seeds matched the same pattern: output derived from lrand48 shifted to retain a small slice of each state. Each recovered state reproduced the entire 160-bit seed, making accidental matches effectively implausible.

The generator can be run backward as easily as forward. Claude reversed each state until it reached the recognizable form created by srand48, whose low sixteen bits are fixed. The remaining value decoded as a Unix timestamp. For the prime curves, those timestamps fell between May 1997 and April 1998. P-256, for example, maps to August 16, 1997 at 01:52:34 UTC, with the standardized seed appearing as candidate 1,842 in the output stream. Anthropic published short Python code that reproduces the seeds from those timestamps and candidate numbers.

The model also explained the base points for six curves generated in May 1997. Those points appear to come from the random generator in FreeLIP, an older long-integer arithmetic package whose code also appeared in early versions of Victor Shoup’s NTL library. The recipe used small integer seeds, discarded seven outputs, generated candidate x-coordinates, and repeated until a coordinate lay on the curve. That independent reconstruction provides another link to the tools a cryptographic engineer of the period could realistically have used.

What the Discovery Proves—and What It Does Not

The clearest operational message is that this is not a break of ECDSA. A weak random generator is dangerous when it creates secret signing keys or per-signature nonces, because attackers may predict or reconstruct those secrets. Here, lrand48 was used to produce public input to a deterministic parameter-generation process. The timestamp is no longer secret, and learning it does not reveal private keys or make the discrete-logarithm problem easier. Replacing certificates, SSH keys, firmware signing keys, or cryptocurrency wallets because of this announcement would be unnecessary.

The finding nevertheless changes the trust story. Reproducing the seeds from ordinary timestamps and an era-appropriate library function makes deliberate bit-level construction less plausible. The values now look like outputs from a simple program rather than opaque constants selected to hide a secret mathematical property. Anthropic is careful not to claim absolute proof. A malicious designer could theoretically search across timestamps and candidate positions until finding a curve with a desired property. But that would require such weak curves to be common enough to discover through a relatively narrow search, and there is no evidence that they are.

There are unresolved details. The generator skipped some candidates that appear to satisfy the documented requirements, and the reason is unknown. The B-163 binary-curve seed still does not fit the recovered process. The origins of the base points for P-224, P-256, P-384, and P-521 also remain unexplained. Those gaps should temper celebratory claims that every design decision has been proven benign. The better conclusion is narrower and stronger: the origin of the principal curve seeds is now reproducible, and the discovered mechanism is consistent with ordinary engineering rather than an obvious backdoor.

This distinction is important for security communication. Headlines about “weak random numbers” can sound catastrophic, while headlines about an AI “proving ECDSA safe” overstate the evidence. Cryptographic confidence is cumulative. It comes from public specifications, extensive analysis, implementation review, side-channel defenses, and transparent parameter generation. The new work improves one part of that chain. It does not certify every implementation or eliminate every remaining parameter question.

What This Means for Developers and Security Teams

Most teams should treat the announcement as assurance research, not an emergency change window. Existing risks around ECDSA remain the practical priorities: poor nonce generation, side-channel leakage, incorrect signature validation, obsolete hashes, exposed private keys, and unsafe key storage. A perfectly trustworthy curve cannot rescue a system that repeats a nonce or stores a production signing key in an unprotected file.

The useful response is to turn the episode into a review of cryptographic governance. Teams often inventory algorithms but overlook parameters, providers, key origins, and upgrade paths. A mature inventory should record which curves are in use, which libraries implement them, whether deterministic signing is enabled where appropriate, where keys live, and how quickly an algorithm can be replaced. That preparation matters more for post-quantum migration and implementation vulnerabilities than the newly explained timestamps.

• Do not rotate ECDSA keys solely because of this research; Anthropic explicitly reports no new attack or curve weakness.
• Confirm that signing implementations use secure nonce generation or a well-reviewed deterministic construction such as RFC 6979 where applicable.
• Prefer current, maintained cryptographic libraries and platform APIs instead of implementing elliptic-curve arithmetic directly.
• Inventory curve use across TLS, code signing, device identity, SSH, tokens, and hardware security modules so migrations are possible when standards change.
• For new protocol designs, prefer parameter sets with transparent, reproducible generation procedures and clear rationale for every constant.
• Separate mathematical assurance from implementation assurance: test invalid inputs, constant-time behavior, key protection, monitoring, and recovery procedures.

Homelabbers have a similar takeaway. There is no reason to replace a P-256 certificate on a reverse proxy just because the seed came from lrand48. It is far more valuable to automate certificate renewal, protect DNS and ACME credentials, patch OpenSSL or the relevant TLS stack, disable outdated protocol versions, and keep private keys out of broadly mounted container volumes. If a service offers Ed25519 or a modern TLS configuration by default, using it may simplify operations, but this discovery is not a mandate to abandon NIST curves.

The Bigger Story: AI as a Cryptographic Research Assistant

The most consequential part of the story may be the workflow rather than the curve. Claude did not merely summarize papers or generate boilerplate. It formed hypotheses about historical software, wrote search code, recognized a statistical anomaly, applied state-recovery techniques, used lattice reduction, and verified full-length outputs. Humans supplied the problem, evaluated the result, checked its implications, and published reproducible code. That is a more realistic picture of near-term AI-assisted research than the idea of an autonomous system producing unquestionable discoveries.

This kind of problem is unusually well suited to an AI system. The search space crosses software archaeology, number theory, cryptographic folklore, and experimentation. A model can move quickly between those domains and generate disposable tools without the context-switching cost a human researcher faces. It can also try many plausible historical implementations without becoming attached to one theory. The failed passphrase hypothesis had dominated attention for years; approaching the problem from the implementation environment opened a different route.

There are risks in celebrating the model too casually. Research agents can generate convincing false positives, selectively report successful experiments, or misunderstand the security meaning of a mathematical match. A result of this kind needs deterministic reproduction, independent review, clear probability arguments, and publication of the relevant code. Anthropic’s post is strongest where it provides exact timestamps, iteration counts, algorithms, and outputs that others can verify. “The model said so” is not evidence; a model-produced path to repeatable evidence can be.

Security organizations should pay attention because large backlogs of similar questions exist: undocumented binary formats, legacy protocol constants, suspicious random-number sequences, abandoned firmware, and unexplained compatibility behavior. AI agents can help build scanners, compare historical source trees, cluster artifacts, and propose candidate origins. They should run in isolated environments, use versioned inputs, preserve logs, and require human review before any finding affects production or public disclosure.

Looking Forward: Transparency Should Be Part of the Standard

Modern cryptographic design increasingly uses “nothing-up-my-sleeve” procedures: constants are derived from recognizable public inputs, generation scripts are published, and multiple parties can rerun the process. The NIST curve mystery demonstrates why that work is not ceremonial. Even when the resulting mathematics is sound, undocumented parameter choices create a trust debt that can last decades. A few paragraphs describing the generator, seed source, rejection criteria, and software version in 1999 might have prevented years of controversy.

The next questions are concrete. Researchers can investigate why valid-looking candidates were skipped, search for the source program or archival correspondence, identify the remaining base-point procedures, and determine the origin of B-163. Independent teams should reproduce Anthropic’s results rather than relying on its interpretation. Standards bodies should also preserve reference implementations and generation artifacts as first-class records, not disposable working files.

For AI research, the benchmark is now higher. The interesting claim is not that a model can discuss cryptography; it is that a model can produce a novel, falsifiable result that experts can verify. More discoveries will likely come from pairing frontier models with executable tools and carefully scoped historical or scientific questions. The winners will be teams that build strong verification loops, not those that publish the most dramatic model transcripts.

The practical conclusion is reassuring. The internet does not need an emergency ECDSA migration today. Instead, it has gained a better account of how several foundational curves were created and a vivid example of what AI-assisted security research can look like when claims are backed by reproducible computation. The old seeds were not magic phrases or evidence of a hidden trap. They were timestamps, a common C generator, and a forgotten engineering process—exactly the sort of mundane history that transparent standards should preserve from the start.

Source: Anthropic, “Claude reveals ECDSA curve origins,” published October 16, 2026: https://www.anthropic.com/research/ecdsa-curve-origins