Whenever I see “RSA broken,” I look for the catch before checking my certificates. Usually, the interesting part isn’t the word broken. It’s what the attacker needed beforehand.
This time, the prerequisite was roughly 4.3 billion raw RSA responses from a hardware security module. That detail deserves almost as much headline space as the breakthrough.
The result is impressive. The apocalypse framing is not.
The key never left the box
In the September 2026 preprint Forging 1024-bit RSA signatures in nearly SNFS time, UC San Diego researchers Laura Shea, Miro Haller, Adam Suhl, and Nadia Heninger, working with Inria’s Emmanuel Thomé, demonstrated signature forgery against a 1024-bit RSA key without factoring its modulus or extracting its private key.
Their computation consumed 1,380 CPU core-years, spread across approximately five calendar months. After that precomputation, forging an arbitrary chosen signature offline still costs about 180 core-years.
So, no, this is not a laptop trick. Your coffee will get cold.
The researchers estimate that factoring a comparable modulus would require 500,000–1,000,000 core-years with current implementations. That’s an enormous gap, but it’s an estimate—not a race between two completed experiments.
<> The private key stayed inside the HSM. The researchers nevertheless reproduced a protected signing capability through the operations the interface allowed./>
That is the part I find genuinely unsettling. “Non-exportable” describes where a secret lives. It doesn’t prove that the surrounding service exposes safe capabilities.
A 2007 idea gets a very expensive demonstration
The mathematical route isn’t new. Antoine Joux, David Naccache, and Thomé described it in 2007 in When e-th Roots Become Easier Than Factoring.
The new contribution is making that route concrete at substantial scale. Under suitable oracle access, the computation approaches the faster special number field sieve cost regime rather than the general number field sieve normally used to estimate RSA factoring difficulty.
Still subexponential. Not polynomial-time magic.
Bruce Schneier’s September 28 response emphasized the necessary qualifications: old algorithm, signature forgery rather than key recovery, raw operations rather than ordinary padded signing, and a “faster” attack that remains expensive.
My take: the implementation is newsworthy enough without pretending every RSA certificate is toast. The paper is also a preprint, not a peer-reviewed conference result.
“We use PSS” needs a follow-up question
Ordinary RSA-PSS signing applies encoding before the private-key operation. This research does not demonstrate a general break of correctly implemented RSA-PSS or PKCS#1 v1.5 signing services.
Blind signatures complicate that reassurance.
RFC 9474 specifies blind RSA signatures whose final signatures verify as RSA-PSS. But the signer processes blinded inputs, so client-side PSS encoding does not automatically eliminate the oracle exposure.
The useful questions are:
- Who controls the input to the private-key operation?
- Does trusted code enforce encoding, or accept arbitrary RSA representatives?
- How many operations can an attacker obtain under one key?
- Are blind issuance and ordinary signing sharing keys?
The paper identifies architectures involving Apple Private Access Tokens, Fastly, Persona, Cloudflare, and GNU Taler as relevant. That is not a list of compromised services.
Audit the verbs, not the vault
Here’s where I’d spend engineering time:
1. Inventory raw RSA operations in HSM and provider APIs.
2. Keep signature encoding inside the trusted boundary where feasible.
3. Separate keys by protocol and purpose.
4. Review query budgets and key lifetimes for blind-signature services.
Larger-key estimates matter too: the authors put oracle-assisted security at roughly 90 bits for 2048-bit RSA and 119 bits for 4096-bit RSA. Those are extrapolations, not demonstrated attacks.
Continue post-quantum planning, but remember that ML-DSA and SLH-DSA address signatures; ML-KEM addresses key establishment. None is automatically a drop-in replacement for a privacy-preserving blind-signature protocol.
My Bet
This won’t trigger a universal RSA emergency rewrite. It will make raw-operation APIs harder to defend in security reviews—and expose how often “the key is in an HSM” substitutes for examining what that key is allowed to do.
