The NIST curve seeds mystery is finally solved — with Claude's help

What happened

In 1997, NIST published a family of elliptic curves — P-192, P-224, P-256, P-384, P-521 — that went on to secure most of the public internet. ECDSA on P-256 is what your browser is doing right now to talk to this site. Each curve was generated from a seed: a 160-bit value fed into SHA-1 to produce the curve parameters. The seeds were published alongside the curves. They looked random. Nobody could explain why those particular bytes.

For 25 years, "where did these seeds come from?" was one of the loudest unanswered questions in applied cryptography, and the vacuum was filled with the obvious guess: the NSA, which drafted the curves, picked seeds whose hashes produced curves with some secret weakness. The suspicion was never crazy. It was later proven that the NSA had in fact backdoored Dual_EC_DRBG, a different NIST crypto standard, by choosing "random" constants with a known relationship. If they did it once, why not twice?

On October 15, Anthropic and Filippo Valsorda — ex-Go crypto maintainer, now running the Geomys cryptography consultancy — published parallel posts explaining that the mystery is solved. The seeds are SHA-1 hashes of ASCII strings. The strings are mundane. One of them, according to Valsorda's writeup at words.filippo.io/seeds-solved, is a joke phrase along the lines of "Jerry deserves a raise" — Jerry being Jerry Solinas, the NSA mathematician who actually generated the curves and died in 2023 without ever publishing the recipe. The seeds are boring. The curves are not backdoored by seed choice.

Why it matters

This matters for three different audiences, in increasing order of how much they'll care.

For working engineers, the practical implication is close to zero. You were already using P-256 and you're still using P-256 — the news is that one old anxiety about it is now firmly resolved rather than merely unproven. The curves' real problems — ECDSA's nonce-reuse foot-guns, the lack of rigidity in how parameters were chosen, the awkward prime shapes compared to Curve25519 — were never about the seeds. If you'd already migrated signature workloads to Ed25519 for the engineering reasons, keep going. If you're stuck on P-256 for FIPS compliance, you can stop worrying slightly more than before.

For the cryptographic community, this closes a loop that has been open since Dan Bernstein and Tanja Lange's 2013 "SafeCurves" project made the rigidity critique mainstream. SafeCurves documented that the NIST curves are "manipulable" — a seed could in principle have been grind-searched to produce a weak curve — and recommended Curve25519 specifically because its parameters are derivable from a short, obviously-rigid description. That critique stands. But the companion worry, that someone had actually done the grinding on the NIST curves, now has a concrete rebuttal: no, they hashed a joke about Jerry.

For AI tooling, this is the more interesting story. The way the problem was finally solved: Valsorda described the search space to Claude — plausible phrase templates, plausible encodings, plausible SHA-1 preprocessing conventions a 1997 cryptographer might have used — and had the model generate and test candidates, iterating on the templates when they didn't hit. It is a tidy example of an LLM doing the brute, patient, slightly-creative-but-mostly-boring part of a cryptographic archaeology problem that a smart human had been circling for a decade. The model didn't invent the method. It accelerated the search enough to make the method tractable.

That's a template worth noticing. The job wasn't "ask the AI to solve crypto." It was "a human expert formulates a tight hypothesis, uses the model to enumerate the long tail of variants faster than they could by hand." The humans know what plausible 1990s NSA-mathematician behavior looks like. The model knows how to grind.

What this means for your stack

If you ship anything that uses P-256 — which is almost everything that does TLS, JWTs, WebAuthn, Apple Secure Enclave operations, or FIDO2 — the operational guidance doesn't change. Keep what you have. The seed story was the loudest FUD talking point against the NIST curves and it's now defanged. That doesn't make P-256 the best choice today; it just means one of the historical reasons to avoid it is retired.

If you're making a greenfield decision between P-256 ECDSA and Ed25519 on Curve25519, Ed25519 is still the better default for most new systems: deterministic signatures, no nonce foot-gun, faster, parameters derived from "the smallest prime of the form 2^255 − k that satisfies the design constraints," which is as rigid as it gets. Pick P-256 when you need FIPS 140 validation, hardware acceleration on older platforms, or interop with WebAuthn authenticators that only speak ECDSA. The seed news changes none of that math.

If you're doing anything adjacent to post-quantum migration — and you should be, NIST finalized ML-KEM and ML-DSA last year — the lesson generalizes. The provenance of your crypto primitives matters, and "we don't know where this constant came from" is a legitimate thing to escalate on even if the primitive has no known weakness. The next time you see a parameter set with unexplained magic numbers, that's a defect report, not a vibe.

Looking ahead

The seeds mystery being solved by Claude is the kind of story that will be a footnote in the history of ECC and a prologue in the history of AI-assisted cryptanalysis. Nothing about the method was supernatural — someone was going to do this eventually, with or without a language model. But the model shaved years off the clock, which is the pattern you should expect everywhere this decade: not AI doing science alone, but AI compressing the search-and-verify loops that already made science slow. The curves are safe from this particular critique. Jerry got his joke immortalized. Your TLS handshake is unchanged. The useful question now is which other 25-year-old "we never figured out where this constant came from" mysteries are suddenly a weekend project.