Claude Solved a 25-Year-Old Cryptography Mystery—But Bitcoin Is Still Safe

Anthropic says an internal Claude research model traced the unexplained seeds behind several NIST elliptic curves to outputs from the C library function lrand48, initialized with Unix timestamps from 1997 and 1998. The finding addresses a long-running provenance mystery. It does not break elliptic-curve cryptography, reveal private keys, or create a new threat to Bitcoin.

That distinction is essential because “AI solves cryptographic mystery” can easily become “AI cracks encryption.” The research reconstructs how public curve parameters may have been generated. It does not provide an efficient attack against the discrete-logarithm problem protecting signatures.

What the mystery was

NIST standardized a family of elliptic curves commonly labeled P-192, P-224, P-256, P-384, and P-521. Their construction included seed values intended to show that curve coefficients were generated through a prescribed process rather than deliberately chosen to hide a weakness.

The verification procedure is the part that made the mystery durable. In the published standards, the seeds are inputs to a hashing routine that expands them into the curve coefficients, and anyone can rerun that routine and confirm the published parameters fall out the other side. That check answers a narrow question: were these coefficients derived from these seeds? It does not answer the prior question of where the seeds themselves came from, or why those particular values were chosen over any other string of bits.

For years, researchers could verify that the published seeds produced the published parameters, yet the origin of those seeds remained unclear. The unexplained inputs fueled suspicion because the curves were developed with involvement from the US National Security Agency, and cryptography had already seen standards undermined by questionable constants.

The precedent most often cited is the Dual_EC_DRBG random-number generator, whose elliptic-curve constants were later shown to be consistent with a secret relationship that would let whoever knew it predict outputs. That episode did not prove the NIST curve seeds were similarly loaded, but it established that “the constants look arbitrary” was a reasonable thing to worry about rather than a paranoid reflex.

Provenance matters even when no vulnerability is visible. If parameter choices cannot be explained, users must trust that no party searched secretly for a rare curve with a hidden advantage. The search space is the problem: there are vastly many curves that satisfy the standardization criteria, and a generator could in principle try enormous numbers of candidate seeds until one produced a curve with a property only it knew to look for. A verifiable derivation chain closes that gap only if the starting point is itself innocent.

What Claude found

According to Anthropic, the model explored candidate historical random-number generators and initialization methods. It connected the seeds to lrand48, a longstanding pseudo-random generator in C libraries, seeded from plausible Unix timestamps around the period when the curves were created.

lrand48 is a familiar piece of the old Unix toolchain. It belongs to the family of 48-bit linear congruential generators that shipped with System V and related C libraries, and it is seeded with a single value through srand48. Its output is deterministic: given the same seed, it produces the same sequence on any conforming implementation. That determinism is what makes the hypothesis testable at all. If the seeds were drawn from lrand48, then a researcher can replay the generator from a candidate timestamp and check whether the bytes line up.

The matching process reportedly narrowed a huge search space by combining source-code archaeology, knowledge of historical systems, and computational experiments. The result offers a mundane explanation: engineers may have generated the values with ordinary tools and time-based seeds rather than choosing them to encode a secret trapdoor.

A timestamp seed is exactly the kind of choice a working programmer makes without ceremony. It is convenient, it varies between runs, and it requires no coordination. If the curve-generation code called srand48(time(NULL)) or its equivalent and then pulled values from lrand48, the seeds would look arbitrary to later observers while being fully reproducible to anyone who guessed the tool and the moment.

The finding should still be independently reproduced. Anthropic is the primary publisher, and outside cryptographers need to check the timestamp ranges, implementation details, and exact relationship for every curve. The claim spans five curves and two years, so the interesting questions are granular: which timestamp maps to which curve, whether the same code path produced all of them, and whether the match holds under more than one plausible reading of how the generator’s output was converted into seed bytes. A single curve matching by coincidence would be suggestive; all five matching under a consistent story would be strong.

Why this does not break the curves

An elliptic curve’s seed is used to derive public domain parameters. Knowing or reconstructing that seed does not reveal users’ private signing keys. It also does not reverse signatures or make the underlying discrete-logarithm problem easy.

The reason is structural. The seed feeds a derivation that produces the curve’s coefficients and base point—public constants that every implementation already ships. Private keys are generated later, independently, by each user’s own randomness. Recovering the seed tells you how the stage was built; it says nothing about which actors are standing on it.

Anthropic explicitly says no user action is required. The research did not identify a backdoor or a practical cryptanalytic weakness in the NIST curves.

The security discussion is about confidence in parameter selection. A transparent generation story reduces one category of suspicion, but it is not a fresh mathematical proof of every implementation’s security. Systems can still fail through weak random keys, side channels, reused nonces, bad libraries, or compromised endpoints.

It is worth being precise about what has and has not been established. The discrete-logarithm problem on these curves is believed hard on the basis of decades of analysis, not on the basis of where the seeds came from. The new result touches the sociology of trust—whether the parameters were chosen honestly—rather than the mathematics of hardness. A curve with a perfectly documented seed can still be broken by a sloppy nonce; a curve with an opaque seed can still be perfectly sound.

Why Bitcoin is not affected

Bitcoin does not use NIST P-256 for its core signatures. It uses secp256k1, a different curve with parameters defined by the Standards for Efficient Cryptography group. The newly traced NIST seeds therefore do not change Bitcoin’s signature security.

Even if the story involved the same curve, identifying a parameter-generation seed would not automatically expose wallet keys. Breaking Bitcoin would require a practical attack against secp256k1, a catastrophic implementation flaw, or compromised key handling—not historical provenance for another curve family.

The “Bitcoin is safe” line is therefore not reassurance based on hope. It follows from both the nature of the discovery and the fact that Bitcoin relies on a different curve.

What AI contributed

This work illustrates a valuable use for research agents: connecting scattered historical clues, generating hypotheses, testing code, and searching parameter spaces. The output is useful because its claim can be reproduced with deterministic computations rather than accepted on the model’s authority.

That last point is the methodological heart of the story. A language model’s assertion about cryptographic history would be worth little on its own; what gives this claim weight is that it terminates in a check anyone can run. Replay lrand48 from the proposed timestamp, compare the bytes, and the answer is yes or no. The model’s contribution is the search strategy—knowing which generators were plausible in that era, which seeding conventions were common, and how to prune a vast space of candidates down to a few worth testing.

The same approach could help audit legacy standards, trace unexplained constants, reconstruct old software behavior, and prioritize questions for human cryptographers. It is less a magical codebreaker than a tireless research assistant with access to executable tests. Standards bodies have accumulated decades of constants whose origins are documented thinly or not at all, and each one is a candidate for this kind of archaeology.

Verdict

Claude appears to have supplied a credible origin story for constants that had remained opaque for roughly a quarter century. If independently confirmed, the result improves transparency around a widely deployed standard and weakens one source of backdoor speculation.

It does not mean encryption has fallen. No private keys were recovered, no NIST curve was shown to be weak, and Bitcoin’s secp256k1 is outside the finding. The breakthrough is historical and methodological: AI helped turn an old question into a reproducible hypothesis.

For the reader, the practical takeaways are modest and specific. Nothing needs to be rotated, patched, or re-keyed on account of this result. What changes is the ledger of trust: one long-standing “we don’t know why these numbers are what they are” entry can now be replaced, pending replication, with “they came from an ordinary generator seeded by the clock.” That is a smaller headline than “AI cracks encryption,” and a more accurate one.