Claude Reveals the Origins of ECDSA Curves: How AI Reconstructs the Inside Story of Cryptographic Design

When AI Becomes a Cryptographic Archaeologist

A discussion thread on Hacker News has drawn attention from both the cryptography and AI communities: a user claimed that Anthropic's Claude model could "reveal the origins of ECDSA curves"—that is, explain where the mysterious parameters in the Elliptic Curve Digital Signature Algorithm (ECDSA) actually come from.

This sounds like technical gossip, but it touches on a serious question: how reliable is a large language model's "memory" of the design history behind cryptographic standards?

The "Origin Mystery" of ECDSA Curves

ECDSA relies on specific elliptic curve parameters—such as secp256k1 (the curve used by Bitcoin) and NIST P-256. These curves did not appear out of thin air; their generation process involves a "seed" and a verifiably random generation procedure.

The problem is that the parameter generation details of many standard curves have not been widely circulated. Take secp256k1 as an example: its parameters were chosen by Certicom around 2000, but the specific seed value and derivation process are vague in publicly available literature. The cryptography community has long harbored a concern: if curve parameters were secretly chosen by some organization, a backdoor could theoretically be embedded.

This is precisely why the "curve origin" question is so sensitive—it is not just about mathematics, but about trust.

Are AI's Claims Credible?

According to user feedback in the Hacker News discussion, Claude can provide detailed accounts of the sources of these curve parameters, including possible seed values, generation algorithms, and selection rationale. But the community's reaction has been sharply divided:

Some developers believe this is simply the result of the LLM's training data covering enough cryptography mailing lists, academic papers, and standards documents—a normal case of "knowledge retrieval." Others warn that the model may be "rationalizing and fabricating" uncertain historical details—wrapping speculation in fluent narrative.

This is not unfounded alarm. Large models are most prone to producing output that looks professional but is actually wrong when dealing with low-frequency, ambiguous factual content in their training data. Cryptographic parameters fall squarely into this high-risk category.

Verifiably random generation is the key background for understanding this controversy. To make the selection process of curve parameters externally auditable, standards bodies typically adopt a public derivation method: first choose an arbitrary but public "seed" string, then repeatedly apply hash functions such as SHA-1 to it, mapping the output to the parameters required by the curve equation (such as the prime field, coefficients a and b, base point coordinates, etc.). Anyone can rerun the same seed and algorithm to verify that the parameters indeed came from this process rather than being hand-picked. SECG and NIST curve documents usually include seed values precisely to make such verification possible. The problem is that the seed itself is still "arbitrarily chosen"—if someone first constructs a curve with a backdoor and then reverse-engineers a seed that generates it, verifiability is undermined. Therefore, where the seed came from, who selected it, and whether there was third-party witnessing are the real focus of the "curve origin" controversy.

LLM hallucination takes a special form in this scenario: the model does not fabricate randomly, but rather generates plausible-sounding historical narratives based on statistical patterns from large numbers of similar documents. Cryptography standards documents, mailing list discussions, and academic papers contain numerous sentence patterns like "a certain curve was selected by a certain organization in a certain year," and the model easily applies these templates to curves with unclear details, filling in seed values or selection rationales that do not exist. This kind of output is especially dangerous because it features professional terminology, timelines, and causal logic, making it difficult for ordinary readers to distinguish truth from fiction by intuition. Mitigation approaches include: requiring the model to provide specific sources (RFC numbers, paper page numbers, mailing list links), remaining skeptical of assertions that cannot be traced to a source, and prioritizing claims that can be cross-verified through public records.

Why This Matters

Setting aside the sensationalist shell of "AI revelation," this discussion exposes several issues worthy of attention.

The Trust Foundation of Cryptographic Standards

The security of ECDSA and elliptic curve cryptography rests on one premise: that the curves were not chosen maliciously. NIST curves were once suspected of containing an NSA-planted backdoor (though after the Dual_EC_DRBG incident, such concerns focused mainly on that random number generator rather than the curves themselves).

When AI narrates the "origin stories" of these curves in a confident tone, it may inadvertently strengthen or weaken a particular trust narrative. If the narrative is wrong, it could instead contaminate developers' understanding.

Dual_EC_DRBG is an important case for understanding this trust crisis. It was a pseudorandom number generator recommended by NIST in 2006, internally relying on point operations on two specific elliptic curves. Documents leaked by Snowden in 2013 revealed that the algorithm may have had an NSA-planted backdoor: anyone who possessed a certain secret constant could, given an output, reverse-engineer the internal state and thereby predict subsequent random numbers—and once random numbers become predictable, virtually every cryptographic system that depends on them collapses. After the exposure, Dual_EC_DRBG was widely abandoned. Notably, this backdoor targeted the random number generator, not the parameters of NIST curves themselves; but the shadow it left in public perception made people more inclined to directly associate "unclear curve origins" with "possible manipulation."

The Boundaries of LLMs as Knowledge Interfaces

Claude's performance on such questions is actually a microcosm of LLM capabilities and limitations. The model can quickly integrate fragmented information scattered across RFC documents, academic papers, and developer forums, but it cannot "verify" the authenticity of that information, nor can it distinguish whether it is recalling or inferring.

For developers, the practical attitude is: treat AI's answers as a starting point for retrieval, not as a final conclusion. Any key information about the sources of cryptographic parameters should be traced back to original standards documents or authoritative academic resources.

To understand why models struggle to distinguish "recall" from "inference," one needs to know that LLMs do not maintain a queryable factual database when generating text. They predict the next word one at a time based on context; high-frequency, coherent, repeatedly appearing information in training data is reproduced more stably, while low-frequency, contradictory, or scattered facts are easily "smoothed" by the language model's fluency into a seemingly complete narrative. The selection process of cryptographic parameters often appears only in a few mailing lists, internal company documents, or unpublished meeting minutes—exactly the kind of information that falls in the model's weak zone. Moreover, the model cannot proactively declare "I am not sure here" unless explicitly asked or trained for alignment—so it gives equally confident tone even on uncertain content.

Practical Recommendations

If you are interested in ECDSA curve parameters, rather than relying on the model's verbal account, it is better to directly consult SECG (Standards for Efficient Cryptography Group) standards documents, NIST's FIPS 186 series, and the original technical discussions surrounding secp256k1.

AI can help you find direction, but the trust chain of cryptography must ultimately rest on verifiable public records.

The value of this "Claude revelation" incident may not lie in what answers it provided, but in reminding us: when AI begins to narrate technical history, we need the ability to independently verify more than ever before.