The loop is three lines long.
for candidate in dictionary:
if sha1(candidate) == seed:
return candidateThat is the whole method. Anthropic says Claude ran it against the seeds behind nine NIST elliptic curves and came back with human-readable strings — date stamps from the mid-1990s. No cryptanalysis. No lattice reduction. No side channel. A dictionary lookup against a one-way function, executed at machine speed.
The headline writes itself, and that is precisely the problem. Within hours of the announcement the framing had split into two camps: "AI just cracked NIST curves" and "the NSA backdoor is confirmed." Both are wrong. Both are wrong in ways that matter, because the actual finding is narrower than the first and considerably more uncomfortable than the second.
Context
Start with what a seed is.
FIPS 186 defines a family of elliptic curves. Two classes matter here. Prime curves — P-192, P-224, P-256, P-384, P-521 — over a prime field. Binary curves — B-163, B-233, B-283, B-409, B-571 — over GF(2^m). To fully specify a curve you need the field, the coefficients a and b, the base point, and the order. NIST did not simply publish those numbers.
For the prime curves, NIST published a seed: an arbitrary-looking 160-bit value. The coefficients are derived by hashing that seed with SHA-1 and using the digest to derive a and b. Anyone can re-run the derivation. Anyone can confirm the coefficients follow from the seed. What nobody could confirm, for roughly thirty years, was where the seed itself came from.
This is the "nothing up my sleeve" principle. If a designer picks curve parameters by hand, they can pick them with a hidden property — a small embedding degree, a low class number, an algebraic relation to some other object they control. If the parameters fall out of a hash of a public string, the designer has no room to maneuver. The transparency is the entire point.
The principle has a scar. Dual_EC_DRBG, the elliptic curve random number generator standardized in 2006, shipped with two constants that turned out to have a secret relationship to each other. Whoever knew the relationship could predict the output. It was withdrawn in 2013. That is the case everyone reaches for when NIST curves come up, and it is not the same case. Dual_EC_DRBG hid a trapdoor inside a random number generator. The prime curves hide nothing in their derivation — the coefficients are checkable by anyone with a SHA-1 implementation.
Which is why the question was never "are the coefficients right." The question was always "was the seed neutral."
Core
The seed could never be resolved by inspection. SHA-1 is one-way. You cannot invert a digest. The only path from a digest back to its input is to guess inputs and hash forward until something matches. The seed is a fixed 160-bit value; if the input was an arbitrary 160-bit number, the search space is 2^160 and the problem is unsolvable forever.
But humans are lazy. If the input was a short string — a date, a phrase, a timestamp — the search space collapses into something a dictionary can cover. A modern GPU pushes tens of billions of SHA-1 hashes per second. A dictionary of every plausible date string between 1990 and 2005, in a dozen formats, with a few thousand phrase variants layered on top, is a rounding error against that throughput.
That is what Claude did, per Anthropic's account. Not magic. Pattern generation — the one thing large language models are genuinely good at — feeding a deterministic verifier.
The verification path is the interesting part. Any third party can take the reported string, run sha1(string), and compare the output to the published seed. If it matches, the claim is true. If it does not, the claim is false. There is no middle ground and no need to trust Anthropic. My default posture, after six months of tracing Uniswap's swap path by hand to verify invariant preservation under edge cases, is that any published parameter is a claim until I have re-derived it myself. I have spent enough time on the wrong end of unauditable claims — my 2025 review of a ZK-verified AI training protocol ended in a benchmark table and an 80% drawdown, because the gap between the proof system's stated guarantees and its actual execution time was three orders of magnitude — to appreciate a claim that fails cheaply.
Two technical details sharpen this.
First, the provenance argument does not depend on SHA-1 being collision-resistant. SHA-1 is broken for collisions. SHAttered, 2017, two different PDFs sharing a digest. None of that helps an attacker here. The binding that matters is preimage resistance: given a digest, find an input that produces it. That property is intact. The provenance chain rests on a weaker assumption than the one the industry spent a decade panicking about, and it holds.
Second, there is a numeric discrepancy worth flagging. The reported coverage is five prime curve seeds and four binary curve seeds. The standard binary set is five — B-163, B-233, B-283, B-409, B-571. Either one seed is unreported, one curve is out of scope, or the reporting collapsed a row. It is a small thing. Small things are where audits live. When a finding arrives with a count that does not match the published standard, check the count before you check anything else.
Where this lands on the stack
Nothing in Bitcoin or Ethereum changes. secp256k1 is not a NIST curve. Its coefficients are a=0, b=7 — the most aggressively nothing-up-my-sleeve parameters in the industry. There is no seed to trace. There is nothing to trace. Every headline that connects this finding to the security of your BTC or ETH is wrong at the level of the parameter file.
P-256 is different. P-256 is in TLS. It is in WebAuthn and every Passkey implementation shipping on a phone. It is in HSMs. It is in enterprise chains and, more often than the marketing suggests, in the proving systems underneath some L2s. If your threat model includes "the curve beneath my signature scheme was chosen adversarially in 1997," this news is directly about you.
Contrarian
Now the part nobody wants to say out loud.
Seed provenance is not generation integrity. The hash binds the seed to the coefficients. It does not bind the designer to the first seed they tried.
Read the construction again. Pick a seed. Hash it. Derive a and b. Now check whether the resulting curve is secure — whether the order is prime or near-prime, whether the embedding degree is large, whether the twist is safe. If it fails, pick another seed. NIST's process is documented, and the documentation says they iterated. That is normal engineering. It is also, structurally, a search over seeds.
The question the industry has never answered is how large that search was. A thousand candidates? A million? A hundred million, run on 1997 hardware with a filter that rejects everything the designers could detect and quietly keeps the one curve carrying a property they could not? The hash proves the coefficients came from the seed. It proves nothing about how many seeds were discarded first.
The math doesn't distinguish. A curve that survived a search is indistinguishable, by parameter inspection alone, from a curve that fell out of the first hash. The only real defense is that the properties an adversary would want are exactly the properties cryptanalysts have been hunting since 1997 — and none of them have turned up in P-256. That is a legitimate argument. It is not the same argument as "the seed was neutral," and the two are being conflated in every write-up I have read this week.
There is a second blind spot, and it concerns the tool rather than the target. A model that hallucinates a plausible date string and a model that recovers the correct date string produce identical output until you hash it. The verifier is the entire security model. Anthropic's claim is cheap to check and cheap to falsify, which is good — but only if someone actually checks it. As of this writing, the claim is a single institution's unreproduced output. I watched a $500k bridge exploit land because a challenge period was too short to matter. The inverse failure is just as expensive: a claim that sits unreproduced for six months, gets cited in a hundred threads, and is treated as settled by the time anyone runs the script.
Complexity hides the truth; simplicity reveals it. This finding is simple. Run the hash. Publish the string. Let the community break it. Until that happens, the provenance claim is a press release with a reproducible appendix, and the difference between those two things is a single afternoon of someone else's compute.
Takeaway
What I want to see next is not a NIST statement. It is a shell script.
If the reported strings hash to the published seeds, the timeline anchors to the mid-1990s and cross-checks cleanly against FIPS 186's drafting window — a genuine, durable improvement in the transparency of a trust anchor that half the internet's TLS handshakes rest on. If they do not, we learn something more valuable: that AI-assisted provenance claims need the same adversarial review as any other security disclosure, and that "the model found it" is not evidence.
The larger question is the one that should keep infrastructure people awake. How many other trust anchors in your stack have never had their provenance checked at all? The constants in your hash function. The parameters in your trusted setup. The derivation path in your wallet's key generation. Each one rests on an assumption that somebody, at some point, generated it honestly. We audit contracts down to the opcode and take the primitives underneath them on faith.
Security is not a feature; it is the foundation. And foundations are the one thing nobody photographs.
Trust the code, verify the trust.