The key never left the box. That was the promise, and it was never the promise the attack needed. On 2026-09-28 Jose Antonio Lanz published Decrypt’s write-up of a preprint on the IACR Cryptology ePrint Archive, Forging 1024-bit RSA signatures in nearly SNFS time, paper 2026/2131, received 2026-09-20 and approved 2026-09-22. The authors are Laura Shea, Miro Haller, Adam Suhl and Nadia Heninger of UC San Diego, and Emmanuel Thomé of INRIA Nancy.
Here is what they did, in numbers I can stand behind. They forged valid RSA signatures on a 1,024-bit key that lived inside a hardware security module. They never extracted it or factored it. They impersonated the module through black-box API interactions. The whole attack took 1,380 CPU core-years spread over five calendar months and 2^32 oracle queries, which is roughly 4.3 billion questions put to a machine that was never supposed to answer a stranger.
Now the asterisks, and I will not bury them. To get the box to sign raw, unformatted numbers, the team switched off its FIPS mode, a certified security setting, and they used a test key of their own. Standard RSA signing pads the message before the mathematics, with PKCS#1 v1.5 or PSS, and padded signatures do not create the opening they climbed through. This is a preprint that has not been through peer review. Bitcoin and Ethereum sign transactions with elliptic-curve signatures, so this is neither a Bitcoin nor an Ethereum break.
That is the drama handled. The verdict worth carrying all week is narrower and more useful: the box did exactly what it promised, and the promise was never the one buyers thought they were paying for. What broke was an interface, not a key.
What Happened, Without the Drama
An HSM is a tamper-resistant device that stores private keys and signs on request. The key inside it is not supposed to exist in readable form outside the device, and in this attack it never did. The attacker did not need it. The attacker needed the API.
The mechanism is worth stating slowly, because the whole story lives inside it. Think of a vault that never opens but stamps any blank paper you slide under the door. Ask it enough times, with well-chosen paper, and you eventually learn to make the stamp yourself. The team asked the box to sign roughly 4 billion numbers of their choosing, then did mathematics on the answers.
Those 4 billion queries are not the finished product. Most of the 1,380 core-years is precomputation. Once that work is banked, the attacker can forge any signature of choice, offline, in 180 core-years. The key stayed in the box the whole time. The attacker simply learned to speak for it.
So the property the buyer paid for, that the key never leaves the box, is technically true and operationally beside the point. The key is the thing the vendor defended. The interface is the thing the attacker used. Thirty years of hardening went into the first and almost none into the second.
The Oracle Is the Defect, Not the Key Size
An oracle is a box that answers questions. In cryptography the word means something precise: a service that performs an operation on input you choose and hands back the result. A signing oracle takes chosen numbers and returns valid signatures over them. It does not leak the key. It leaks something subtler and worse, which is the ability to compute with the key until its only remaining secret is gone.
This is why asking for a longer key is the wrong reflex. The defect is not in the modulus. It is in the interface that will happily perform the operation for a stranger. You can multiply 1,024 by four and get a bigger number, and the oracle will consume that bigger key exactly the same way.
The authors put a number on the haircut themselves.
“Extrapolating our empirical running times to larger key sizes, we conclude that the concrete security of RSA with a signing oracle should be 15 to 30 bits lower than the factoring-based security estimates for the 1024-bit to 4096-bit RSA parameters that are common in practice. Even 4096-bit RSA does not appear to meet a 128-bit security level in this attack model.”
Read that twice. A 1024-bit RSA key has long been treated as roughly 80 bits of strength, well below what anyone should ship today, and a 4096-bit key exists so that people can stop worrying about it. In this attack model it does not appear to reach 128 bits. The oracle does the mathematics on the attacker’s behalf, so a bigger modulus cannot save you.
The idea underneath is older than the demonstration, and that should bother people more than the vault story does. It builds on When e-th Roots Become Easier Than Factoring, an under-appreciated 2007 algorithm by Antoine Joux, David Naccache and Emmanuel Thomé that forges RSA signatures after temporary access to a raw RSA signing or decryption oracle, in time close to the special number field sieve, without factoring the key. Emmanuel Thomé is on both papers. This was not a lucky strike. It was a tool that sat on a shelf: read by a few, ignored by most of the people deploying RSA.
Hardware is a boundary around a physical thing. An API is a boundary around a promise. The industry spent thirty years making the physical thing harder to open, then shipped the promise as an endpoint with a service account.
We Have Known This Since 1998
None of this is a new class of bug, and I have watched this movie before. In 1998 Daniel Bleichenbacher showed that an implementation which answers questions about RSA decryption with PKCS#1 v1.5 padding leaks enough to recover plaintext. A padding oracle. TLS deployments were vulnerable. The fix was to stop leaking padding errors, and eventually to stop using RSA key transport at all.
The same bug was rediscovered at scale in 2017 under the name ROBOT, Return Of Bleichenbacher’s Oracle Threat. Nineteen years, one oracle, one root cause, because the industry patched the leak in some places and left it standing in others.
TLS 1.3 was standardised as RFC 8446 in August 2018 and removed static RSA key transport entirely, leaving RSA only as a signature algorithm. Read that decision carefully, because it is the answer the HSM industry still has not given. The industry’s response to a decryption oracle was not to build a tougher box around RSA. It was to delete the interface that let strangers make the key do work. The IETF did in one specification what a generation of hardware vendors still sell as a feature.
And an oracle is not always a defect. Blind RSA signatures hand one out on purpose: the server signs a value without ever seeing it. David Chaum used blind signatures when he founded DigiCash in 1989. One variant of Privacy Pass uses them, and Cloudflare has said Apple uses a version of Privacy Pass so that users can prove they passed a check, such as a CAPTCHA, without revealing who they are. An oracle is a capability. Sometimes you want it. You just have to know you are holding it.
Why Bitcoin Never Used RSA in the First Place
RSA was published in 1977 by Ron Rivest, Leonard Adleman and Adi Shamir, and the S in the name is Shamir. Its security is generally understood to rest on the difficulty of factoring, though breaking RSA was never proven equivalent to factoring. That last clause has been a quiet nuisance for decades, and it is the crack this paper widened.
Bitcoin launched in 2009 and signed transactions with ECDSA over a 256-bit elliptic curve, not RSA. Schnorr signatures exist on that curve too and only became part of the protocol later, and Ethereum signs with elliptic curves as well. The practical consequence is the part that matters: the primitive actually running in production across the chains is a small elliptic-curve signature, not the scheme this paper dents.
The standard response to a headline like this one is panic, and the panic will be wrong, because it usually is. In January 2023 Chinese researchers claimed a quantum method that threatened RSA. It had factored a 48-bit number. Experts dismissed it, correctly. This time the demonstration is an actual 1,024-bit key, with one asterisk the size of the oracle. Both headlines used the same noun. Only one of them earned it.
The quantum threat, when it lands, is to elliptic-curve signatures and not to RSA, and that distinction is almost always lost in the retelling. Caltech researchers estimated at the end of March 2026 that 10,000 to 20,000 qubits could be enough to run Shor’s algorithm, the method that threatens those signatures. The thing people should actually fear for their Bitcoin is the exact thing this paper does not touch.
Two decisions, one made in 1977 and one in 2009, explain why this is an enterprise story and not a chain story. The first made RSA the default for a generation of enterprise software, because it was what the world already knew how to interoperate with. The second put a 256-bit elliptic curve into production before most enterprise shops had finished writing their RSA roadmaps. I will not pretend the second was a deliberate act of security foresight. It was an engineering choice about signature sizes and verification cost, and it happened to sidestep the exact defect this paper describes. That is how a lot of good decisions get made, and it is why I care more about what a design has to interoperate with than about what it promises.
What You Are Really Trusting When You Buy a Box
When you hold keys, the question that matters this week is not whether your hardware is certified. It is how many interfaces can make your key do work, who can reach them, and what you actually log. A box is one of those interfaces, and it is rarely the only one.
FIPS 140 is the standard that certifies cryptographic modules in the United States and Canada. FIPS 140-3 is the current version, and commercial hardware modules generally need compliance with it to be sellable to regulated buyers. That is what the certificate means: a regulated buyer can purchase it. It is not a claim that the box survives an attacker who is allowed to call the box’s API four billion times.
You are not buying a box. You are buying every interface that can make the box’s key do work, plus everyone who can reach them.
I have seen too many teams buy a certified module and then defeat it with configuration. A FIPS mode switched off because a test suite wanted raw output. An operator quorum that lives in a single password manager. A firmware update path that nobody owns. A signing key that is also, quietly, a decryption key. The paper needed a test key and a disabled certification setting to get its oracle. Real deployments hand out the same oracle through ordinary carelessness, with no research team and no preprint.
This week supplied a reminder that the defect generalises. On 2026-09-28 Bitget’s chief executive said the hacker behind the exchange’s $388 million loss exploited vulnerabilities in third-party products, and that the attack began with small test transfers to probe risk controls. That is the security bill we tallied last week arriving through a different door, and it is the same defect: an interface someone else owned, and nobody watching the volume.
The Bill, and What I Would Actually Do
Now the accounting, because this is where projects actually die. The purchase order is the cheapest line item on the sheet. I have watched teams budget for the box and forget everything around it: the key ceremonies, the operator roster, the firmware update discipline, the log pipeline, the alerting, the person who gets paged on a Sunday. Roughly 80% of the cost of any such system is what happens after go-live, not the purchase order. The box is a rounding error next to the organisation that has to operate it.
The paper hands you the alarm threshold for free. The attack needed 2^32 oracle queries spread over five calendar months. Four billion signing requests in five months is not stealthy. If you log every signing operation and alert on volume, that pattern is loud, and loud is enough. Most teams do not log signing volume at all, which is exactly why they never see the slow version of this.
So here is my standard, in plain words. Do not invent cryptography, and do not fork a standard to feel clever; the good primitives are global and public, and it is the fashion of the moment that gets you breached. Count the interfaces that can make your key do work and write the number down, because you cannot defend a boundary you have not enumerated. Keep the hardware module as one layer among several, not as the answer. Treat a certificate as evidence about a process, not as a property of a metal case.
Then widen the horizon, because the migration you actually have to run is post-quantum and it is on a clock. Google has set 2029 as its deadline to finish migrating its own systems to post-quantum cryptography. That is a large, well-resourced buyer of cryptography telling the market when it wants to be finished, and our Q-Day field notes track what that means for anyone still holding keys. The authors point the same way: they describe their result as classical cryptanalytic evidence in favour of moving away from RSA entirely during the current post-quantum transition. Two arguments for leaving, one quantum and one classical, arriving at the same exit.
Where I Stop Being Certain
I will tell you where my evidence runs out, because it does. Padded RSA is untouched; PKCS#1 v1.5 and PSS do not create the oracle this attack requires. Every elliptic-curve system, which is to say Bitcoin and Ethereum and most of what you hold, is untouched. This is a preprint and not a peer-reviewed result, and the authors themselves call the attack model unusual. An attacker who can already coax a raw, unpadded signing oracle out of your box is in a strong position before this paper is even relevant. The paper does not break a deployment. It removes the excuse of not knowing.
What I would still bet on is the direction, not the decimal. Hardware modules will keep selling, because regulated buyers need FIPS 140-3 on the shelf and that is a real requirement rather than a racket. RSA will keep being deployed, because migrating is expensive and unhurried, and this paper changes the schedule only for the people who read it. And the question worth carrying into next week is not whether the key left the box. It never did. The question is how many doors open onto that key, who is holding the handles, and what your logs would show if someone slid four billion pieces of paper under one of them.
