Anthropic’s latest explanation of where the NIST curve seeds came from reads, on the surface, like a tidy piece of cryptographic archaeology. But buried inside it is something that touches a design decision Satoshi Nakamoto made 17 years ago, one that still shapes why your crypto wallet can’t talk to your iPhone’s fingerprint sensor.
Those seeds had been an open mystery since 2000, when NIST published its elliptic curve standards with a cryptic “SEED” value attached to each curve and no explanation of where the numbers came from. Because the NSA supplied them, that silence hardened into a decades-long suspicion that one or more curves had been secretly searched for until a weak one turned up, with cryptographers Neal Koblitz and Alfred Menezes writing a well-known paper on the controversy and a five-figure bounty sitting unclaimed. According to Anthropic, Claude cracked it by reverse-engineering the software that must have generated the seeds rather than searching for a leaked explanation. It noticed that several published seeds had an improbable pattern of cleared bits, a statistical fingerprint of lrand48, a weak pseudorandom number generator bundled with 1990s C libraries. From there, Claude used lattice reduction (the LLL algorithm) to recover the generator’s hidden internal state from the visible seed bytes, then ran that state backward until it matched how the generator is normally initialized. The result: ten separate NIST and ANSI curve seeds all turned out to come from feeding an ordinary Unix timestamp from 1997 or 1998 into that generator, with no hashing, no secret phrase, and nothing more exotic than a clock. Anthropic says Claude worked all of this out in under 30 minutes.
Two curves, one old grudge #
Bitcoin, and every chain built on the same account model since, including Ethereum and the rest of the EVM world, runs on an elliptic curve called secp256k1. That is not the curve almost everything else around you uses. Modern hardware security, from Apple’s Secure Enclave to the WebAuthn standard behind passkeys, runs on a different curve called secp256r1, better known as P-256, one of the exact curves Claude just investigated.
That mismatch is not cosmetic. Apple’s Secure Enclave, the dedicated chip that has guarded device keys since 2013, is built around P-256. Passkeys and WebAuthn, the password-replacement standard backed by the FIDO Alliance and W3C, are P-256 by design too. Ethereum’s base accounts only understand secp256k1, so a private key sitting in your phone’s Secure Enclave or synced through iCloud Keychain simply cannot sign a standard Ethereum transaction. It’s a wrong-shaped key for the lock.
That’s why wallet teams have spent years building workarounds instead of just using the hardware security already sitting in a billion pockets. On-chain P-256 signature verification used to be prohibitively expensive in gas, and proposals like RIP-7212 only exist because of this exact mismatch, adding a cheap way for smart contract wallets to verify P-256 signatures so that passkey-based accounts become practical. Rollups including Optimism, Arbitrum, and zkSync have committed to supporting it for exactly that reason.
Why Satoshi picked the “weird” curve #
So why does Bitcoin run on secp256k1 at all, if P-256 is the one everyone else standardized on? The leading explanation for years has been distrust. P-256 is a NIST curve, and NIST curves came bundled with those unexplained seed values the NSA supplied with no justification. secp256k1, by contrast, has simple, transparent parameters that don’t require trusting an unexplained government-supplied number. In the wake of the Dual_EC_DRBG scandal, a separate and far more damning case where a NIST-standardized random number generator turned out to contain an actual, exploitable NSA backdoor, that kind of caution wasn’t paranoia so much as pattern recognition.
That is almost certainly part of why Nakamoto picked secp256k1 for Bitcoin. It is also, now, the thing Claude’s finding speaks to directly. If the P-256 seeds really do trace back to nothing more exotic than a Unix timestamp fed into a weak 1990s-era random number generator, as Anthropic describes, that’s meaningfully different from a seed secretly searched for until it produced a weakened curve. It doesn’t retroactively prove P-256 is backdoor-free. But it does remove one of the main pieces of circumstantial evidence that made people suspicious of it in the first place, which happens to be the same evidence that nudged Bitcoin toward a different curve entirely.
What this does and doesn’t change #
None of this makes secp256k1 and P-256 suddenly interchangeable. Bitcoin and Ethereum aren’t about to migrate curves, and the practical reasons developers have built bridges like RIP-7212 instead of waiting around for this exact kind of reassurance remain exactly as valid as they were last week. Crypto wallets will keep needing smart-contract-level workarounds to talk to Secure Enclave and passkey infrastructure regardless of how trustworthy P-256 turns out to be.
What does change is the shape of the argument. “We don’t trust NIST’s curve because of an unexplained NSA-supplied number” was a reasonable, if unprovable, position to hold for 25 years. That specific argument just got considerably weaker, not because someone proved P-256 is safe, but because an AI model spent half an hour on a problem a large, motivated community had failed to crack since 2000. It’s also a fairly clean example of the kind of research throughput Anthropic has been pointing to all year, in the same vein as a Harvard mathematician using Claude to disprove an 87-year-old conjecture in algebraic geometry or Claude surfacing a previously unknown biological system with CRISPR-like properties. The company has also been tracking how much of its own internal research Claude now drives, and a 25-year-old open problem solved on what the finding describes as a simple prompt is the kind of result that tends to end up in that tally.