Introduction 🤖
In 2000, NIST published FIPS 186-2 with a set of elliptic curves that went on to secure TLS, SSH, code signing and countless embedded devices. Each of those curves was built from a seed: a public number fed into a hash to derive the curve parameters. The seeds came from the NSA, with no explanation of how they were chosen, and that silence kept a question open for more than 25 years: could the agency have searched for seeds that produced curves with a weakness only it knew about?
On 16/10/2026, Anthropic's Frontier Red Team published the answer. An internal Claude research model, given the published seeds and no prior theory, found in under half an hour that they are outputs of an ordinary C library random number generator seeded with the clock of a computer running in 1997 and 1998. The result is not a break of ECDSA, not a new attack and not a weakness in the curves, as the authors state explicitly.
Technical Context: How a Verifiably Random Curve Is Built 🔐
The NIST curves follow the "verifiably random" method from ANSI X9.62. A seed goes into SHA-1, and the hash output determines the curve coefficient b. The idea is that nobody can pick b directly: anyone can recompute the hash and confirm the curve came from the seed. The weak point of the method was always the seed itself. If whoever generated it could try millions of seeds and keep the one that produced a curve with a hidden property, the hash would only hide the choice.
The reconstruction shows how the seeds were actually produced:
- Generator: lrand48, the 48-bit linear congruential generator of the C standard library, initialised with srand48(time), where time is the machine's Unix timestamp.
- Prime-field curves: P-192, P-224, P-256, P-384 and P-521 match timestamps between May 1997 and April 1998. The P-256 seed corresponds to 16 August 1997.
- Binary curves: B-233, B-283, B-409 and B-571 match the same method with the clock halved; read raw, the timestamps fall in February 1984, and doubled they land on 17 April 1998.
- Example curves of ANSI X9.62: prime192v2, prime192v3 and prime239v1 to v3 were recovered as well.
- Base points: for P-192 and the ANSI prime curves, they come from the random number generator of Arjen Lenstra's FreeLIP library, which early versions of Victor Shoup's NTL also shipped.
The earlier theory, that the seeds were the hash of a humorous passphrase, turned out to be wrong. The authors released reproduction code under CC0, and its outputs match the published seeds and base points 📊.
Practical Implications: What Changes and What Does Not ⚠️
For anyone running P-256 or P-384 today, nothing changes. The seeds were always public, so recovering how they were made exposes no secret, and private keys generated on these curves are unaffected. What changes is the weight of the backdoor hypothesis. A simple, reproducible generator fed by the clock leaves little room for a deliberate search for weak curves; the authors note that such a search would only succeed if weak curves were common and easy to find, which would be a problem of its own.
The result does not close every question, and the authors are explicit about the gaps:
- Some viable candidate seeds were skipped for unknown reasons; for P-256, candidate 876 was passed over.
- The number of times the generation program ran is unknown.
- The seed of the fifth binary curve, B-163, remains unexplained.
- The base points of P-224, P-256, P-384, P-521 and the NIST binary curves remain unexplained.
There is also a side lesson. A clock-seeded lrand48 is perfectly adequate for producing public parameters, and completely inadequate for producing secret keys: anyone who knows roughly when such a key was generated can recreate it. The NIST seeds were safe only because they were never meant to be secret.
Bitcoin sits outside this discussion. It uses secp256k1, a curve defined by two small fixed numbers rather than a hashed seed, so the question of a manipulated seed never applied to it.
Strategic Conclusion 🛡️
Keep the NIST curves where they are deployed. The research gives no reason to migrate, and the reproduction code lets any team verify the claim instead of trusting it. Curve choice still deserves attention for a different reason: quantum computing threatens elliptic curve cryptography regardless of how a curve was generated, and post-quantum migration plans should move forward on their own schedule.
The episode also shows the value of transparency in standards. Parameters published with their full derivation, as later designs such as Curve25519 did, never need a 25-year investigation. The $36,864 bounty organised by Filippo Valsorda for the seeds will be donated to the Internet Security Research Group, the non-profit behind Let's Encrypt, and the authors honour the memory of NSA mathematician Jerry Solinas, who died in 2023.
Original research published by Anthropic's Frontier Red Team on 16/10/2026, reported by Shaurya Malwa on CoinDesk on 17/10/2026.
Fonte Original: https://www.anthropic.com/research/ecdsa-curve-origins
