Claude Solves a 25-Year ECDSA Mystery: Is Bitcoin Security at Risk?

A Long-Standing Question in Cryptography

Cryptography is one of the foundations of digital security. From internet communications and digital signatures to blockchain transactions and authentication systems, elliptic curve cryptography (ECC) plays a critical role in protecting digital information.

However, the security of cryptographic systems depends not only on the difficulty of mathematical problems but also on how their underlying parameters are selected.

For decades, one question remained unresolved: How were the parameters of certain elliptic curves standardized by the US National Institute of Standards and Technology (NIST) originally chosen? More specifically, why had the origins of their seed values never been explained?

On October 16, 2026, research published by Anthropic provided an important answer with the assistance of Claude. Researchers discovered that the seed values of five NIST prime-field elliptic curves had been generated using lrand48, a pseudorandom number generator commonly available in the 1990s, initialized with Unix timestamps.

This discovery did not mean that the cryptographic curves had been compromised. Its significance was the reconstruction of a parameter-generation process that had remained unexplained for approximately 25 years.

What Are ECDSA and Elliptic Curve Cryptography?

ECDSA stands for Elliptic Curve Digital Signature Algorithm. It uses elliptic curve mathematics to generate and verify digital signatures.

Digital signatures allow a message to be verified against a corresponding public key without revealing the private key used to sign it. This provides message integrity and cryptographic authentication associated with the signing key.

The system relies on two essential components:

• Private key: A confidential value used to generate digital signatures.
• Public key: A mathematically derived value used to verify those signatures.

Calculating a public key from its corresponding private key is straightforward. Recovering the private key from the public key, however, is computationally impractical for classical computers when the system uses appropriately selected parameters.

This security property is based on the elliptic curve discrete logarithm problem.

In simplified form, an elliptic curve over a prime field can be represented by the following equation:

y² ≡ x³ + ax + b (mod p)

Here, a and b represent the curve coefficients, while p is a prime number.

Practical cryptographic systems also define additional parameters, including a base point and group order.

One of the long-standing questions concerned how these parameters, particularly the coefficient b, had originally been determined.

The Mystery Behind NIST Elliptic Curve Seeds

NIST standardized several prime-field elliptic curves for digital signature applications, including P-192, P-224, P-256, P-384, and P-521.

Among them, P-256, also known as secp256r1, is widely used in internet security protocols such as TLS and various digital signature applications.

To document how certain curve parameters were generated, the standards included initial values known as seeds. These seed values were processed using a defined SHA-1-based procedure to derive the curve coefficient b.

However, the standards did not explain why those particular seed values had been selected.

This lack of transparency raised concerns within the cryptographic research community.

The individuals responsible for defining the parameters could theoretically select from numerous mathematically valid alternatives. If an undisclosed selection process had been involved, independently evaluating whether certain values were deliberately chosen to introduce weaknesses would become more difficult.

Consequently, some researchers questioned whether the standardized curves could contain hidden vulnerabilities or intentionally introduced backdoors.

One widely circulated explanation suggested that the seeds had been generated from the hash of a humorous phrase referring to Bob and Jerry.

In 2015, cryptographer Jerry Solinas recalled a story along these lines. He identified Bob Reiter as the person who had written the original code but acknowledged that the precise details were no longer available.

The story offered a possible explanation, but it did not establish how the values had actually been generated.

Anthropic's research took a different approach. Rather than attempting to reconstruct a rumored phrase, the investigation focused on identifying mathematical patterns within the published seed values.

How Claude Discovered the Connection to lrand48

Anthropic researchers used Claude to investigate the possible origins of the standardized seeds.

Instead of relying exclusively on historical accounts, the model examined how software available during the 1990s might have generated the published values.

This investigation led Claude to lrand48, a pseudorandom number generator found in traditional C programming environments.

Pseudorandom number generators produce sequences from an initial internal state. Although their outputs appear random, the same algorithm and starting state will reproduce the same sequence.

lrand48 uses a 48-bit internal state and belongs to a family of linear congruential generators.

These older generators can exhibit identifiable mathematical patterns, potentially allowing researchers to reconstruct their internal states from observed output.

Claude examined the published seeds for such patterns, comparing their bit structures and investigating whether consecutive outputs could originate from a known generator.

The analysis also involved lattice-based mathematical techniques, including the Lenstra–Lenstra–Lovász (LLL) algorithm, which can help recover the state of truncated linear congruential generators.

The researchers demonstrated that the seed values of all five NIST prime-field curves could be reproduced using lrand48.

The same pattern was identified in five additional curve seeds from the ANSI X9.62 standard.

More importantly, the recovered generator states corresponded to Unix timestamps.

This indicated that the original parameter-generation software had likely initialized its random number generator using time values obtained from the system clock.

The discovery established a reproducible explanation for values whose origins had remained uncertain for decades.

Why the 1,842nd and 876th Candidates Matter for P-256

One of the most interesting findings involved the P-256 elliptic curve.

During the reconstructed generation process, the random number generator produced consecutive 20-byte candidate seed values.

The seed published in the P-256 standard appeared at the 1,842nd candidate.

However, the researchers identified another important detail.

The 876th candidate from the same generation sequence also produced a valid elliptic curve of the appropriate size, with a prime group order and parameters generated using the same approach.

This finding matters because the investigation established more than the origin of the published seed. It demonstrated that other mathematically valid candidates had appeared earlier in the process.

Why was the 1,842nd candidate selected instead of the 876th?

The researchers could not determine whether additional selection criteria had been applied or why some valid candidates had been skipped.

Importantly, this does not constitute evidence of an intentional backdoor.

The research team considered the relatively small number of skipped candidates inconsistent with the idea that deliberately weakened curves could be found easily.

Nevertheless, certain details of the original selection process remain unknown.

Does This Discovery Prove That NIST Curves Have No Backdoors?

The most significant contribution of the discovery is that a previously unexplained parameter-generation process can now be reproduced.

Demonstrating that the seeds originated from an ordinary pseudorandom number generator initialized with timestamps reduces concerns that they were deliberately constructed to introduce hidden weaknesses.

However, two separate questions must be distinguished:

1. Can the original generation process for the seed values be explained?
2. Can every parameter-selection decision be reconstructed, and can all possible weaknesses be ruled out?

Anthropic's research provides strong evidence addressing the first question, but it does not resolve every aspect of the second.

The investigation also explained how the base point G of the P-192 curve had been generated.

Researchers reconstructed its origin using a random number generation method from FreeLIP, a mathematical software package associated with Arjen Lenstra.

However, the selection processes for the base points of P-224, P-256, P-384, and P-521 remain unexplained.

The seed of the binary-field curve B-163 also remains unresolved.

Therefore, the findings do not demonstrate that ECDSA has been broken, nor do they establish that every historical question surrounding the standardized curves has been answered.

Why Does Bitcoin Use secp256k1?

The P-256 elliptic curve standardized by NIST and the secp256k1 curve used by Bitcoin are different mathematical constructions with distinct parameters.

While P-256 uses the coefficient a = -3, secp256k1 follows the equation:

y² ≡ x³ + 7 (mod p)

The selection of secp256k1 for Bitcoin is separate from the investigation into the origins of NIST curve seeds.

The secp256k1 curve is distinguished by its relatively simple coefficients, particularly a = 0 and b = 7.

These structural differences mean that the parameter-selection processes of the two curves should not be treated as equivalent.

It is sometimes suggested that Bitcoin's creator, Satoshi Nakamoto, selected secp256k1 specifically because of concerns about NIST.

However, without reliable evidence confirming this motivation, such explanations should not be presented as established historical facts.

Bitcoin also supports Schnorr signatures through Taproot, alongside its existing ECDSA-based signature applications.

Schnorr signatures in Bitcoin use the secp256k1 curve as well.

The distinction between P-256 and secp256k1 remains relevant to broader discussions about cryptographic transparency.

When curve parameters are selected through transparent and reproducible procedures, independent security assessments become easier to conduct.

Digital Signatures and Nonce Security in Blockchain

Another important aspect of ECDSA security in blockchain systems concerns the nonce used during signature generation.

When a blockchain transaction is signed, the algorithm uses a private key, the message or its cryptographic digest, and a temporary value known as a nonce.

The nonce is not a wallet address. It is a mathematical input used during the signing process.

In ECDSA, one signature component is calculated using the following relationship:

s = k⁻¹(z + rd) mod n

Where:

• d represents the private key.
• k represents the nonce.
• z represents the message digest.
• r and s represent the signature components.
• n represents the order of the relevant group.

Secure nonce generation is essential.

If the same nonce is reused when signing different messages with the same private key, the mathematical relationship between the signatures may allow an attacker to recover that private key.

Nonce reuse is therefore a serious cryptographic implementation vulnerability.

However, the discovery that lrand48 was used to generate NIST curve seeds does not imply that ECDSA nonces used in blockchain transactions were generated using the same algorithm.

Curve parameter generation and transaction-specific nonce generation are fundamentally separate processes.

Address management also plays an important role in Bitcoin privacy.

An unused Bitcoin address may have no recorded transaction history on the blockchain, but that does not necessarily mean the address itself is unknown.

Using new addresses for different payments can make transactions more difficult to associate with one another.

Nevertheless, blockchain analysis can still identify potential relationships through transaction amounts, spending patterns, and other on-chain information.

Could Quantum Computers Break ECDSA?

Claude's investigation into the origins of NIST curve seeds and the potential impact of quantum computing on ECDSA are two distinct subjects.

The security of current elliptic curve systems relies on the computational difficulty of recovering private keys from public keys using classical computers.

However, a sufficiently powerful, fault-tolerant quantum computer could use Shor's algorithm to solve the elliptic curve discrete logarithm problem.

Such a capability would undermine the security assumptions supporting ECDSA and other elliptic curve cryptographic systems.

This does not mean that current quantum computers can practically recover Bitcoin private keys from secp256k1 public keys.

Similarly, Claude's discovery does not demonstrate that artificial intelligence can calculate private keys or defeat secp256k1.

The relevant long-term challenge is determining how existing cryptographic systems can transition toward algorithms designed to resist attacks from sufficiently advanced quantum computers.

STARKs and Post-Quantum Cryptography

Post-quantum cryptography focuses on developing cryptographic methods intended to remain secure against attacks involving advanced quantum computers.

STARKs are cryptographic proof systems used to demonstrate the correctness of computations.

Their reliance on hash-based cryptographic constructions makes them relevant to certain post-quantum security approaches when appropriate algorithms and security parameters are used.

Research within the Ethereum ecosystem also explores quantum-resistant signatures and STARK-based proof systems.

One example is EIP-8288, a draft proposal addressing the aggregation of cryptographic signatures and STARK proofs.

The proposal explores how such mechanisms could support more efficient verification of post-quantum cryptographic operations.

However, EIP-8288 has not been activated as an Ethereum mainnet upgrade.

It is also important to distinguish between proof systems and digital signature algorithms.

STARKs should not be considered a direct, universal replacement for ECDSA.

A cryptographic proof system and a digital signature scheme serve different purposes and provide different security properties.

Post-quantum migration therefore requires the careful evaluation of signature mechanisms, key management systems, verification procedures, and protocol-level requirements.

For blockchain networks, this transition involves more than selecting a new mathematical algorithm.

Transaction processing, signature verification, computational costs, and the migration of existing users' cryptographic keys must also be considered.

Conclusion: From a Cryptographic Mystery to the Future of Digital Security

Claude's discovery of the origins of NIST elliptic curve seeds provides a compelling example of how artificial intelligence can contribute to cryptographic research.

By reconstructing a parameter-generation process that had remained unexplained for approximately 25 years, the investigation demonstrated how mathematical analysis and AI-assisted research can help resolve long-standing technical questions.

However, the findings do not indicate that ECDSA has been broken.

Bitcoin's use of secp256k1, nonce security in digital signatures, and the transition toward post-quantum cryptography remain separate technical considerations.

The broader lesson is that cryptographic security depends on more than sophisticated mathematics.

The way cryptographic systems are designed, how their parameters are selected, and whether those decisions can be independently verified are equally important.

Artificial intelligence may accelerate investigations into previously unresolved security questions. Nevertheless, independent verification, transparent reporting of uncertainties, and careful interpretation of technical findings remain essential.

For blockchain and digital asset infrastructure, trustworthy security continues to depend on mathematically sound foundations, transparent engineering practices, and rigorous implementation.

Frequently Asked Questions

Did Claude Break ECDSA?

No. Claude helped researchers identify how the seed values of several NIST elliptic curves were originally generated. The discovery did not compromise ECDSA or demonstrate a method for recovering private keys.

Why Is Claude's Discovery About NIST Curves Important?

The research reconstructed a parameter-generation process that had remained unexplained for approximately 25 years. This provides greater transparency into the origins of standardized elliptic curves and helps researchers evaluate historical concerns about deliberate weaknesses.

Does This Discovery Affect Bitcoin Security?

Not directly. Bitcoin uses secp256k1, which differs from the NIST P-256 curve examined in the seed investigation. The findings do not introduce a new attack against Bitcoin's digital signatures.

Why Is Nonce Reuse Dangerous in ECDSA?

Reusing the same nonce when signing different messages with the same private key can expose mathematical relationships that allow an attacker to recover the private key. Secure nonce generation is therefore essential for ECDSA security.

Could Quantum Computers Threaten Bitcoin in the Future?

A sufficiently powerful quantum computer could potentially use Shor's algorithm to undermine elliptic curve cryptography. However, this threat is separate from Claude's discovery. Developing and evaluating post-quantum signature systems remains an important area of long-term blockchain security research.