For roughly two decades, one assumption held firm: the only way to forge an RSA signature was to factor the modulus first, and factoring a 1024-bit key was a job for a nation-state budget. A team at UC San Diego and INRIA just knocked that assumption over. They forged a valid 1024-bit RSA signature without ever factoring the key, at a total cost of 1,380 CPU core-years spread over five months on an academic cluster. Factoring the same key is estimated at 500,000 to 1 million core-years. The difference is not a rounding error; it is three orders of magnitude.
The work is described in a preprint on the IACR ePrint archive (paper 2026/2131), and Ars Technica’s coverage of the RSA signature forgery attack is the best plain-language writeup you will find. Dan Goodin’s reporting includes comments from the authors and from cryptographer Karsten Nohl, who called it a potential conceptual breakthrough: “RSA is as difficult to break as it is to factor large integers, at least so we thought.”
How you forge a signature without the key
The attack needs one thing: temporary access to a raw, unpadded RSA signing or decryption oracle. This is the classic “lunchtime” threat model. The attacker gets to feed chosen inputs to the oracle for a while, walks away, and keeps the ability to forge any signature of their choice offline, forever. Nothing about the private key ever leaves the machine, yet the attacker ends up with power equivalent to having stolen it.
The engine underneath is a 2007 algorithm by Joux, Naccache, and Thome that has sat largely unappreciated for nineteen years. It is a variant of the number field sieve that runs close to “special” number field sieve speed, which is substantially cheaper than the general number field sieve used for full factoring. The San Diego team, led by Laura Shea with Miro Haller, Adam Suhl, Nadia Heninger, and Emmanuel Thome of INRIA, built the first complete implementation and ran it for real at 1024-bit scale.
The oracle in their demonstration was a hardware security module with FIPS mode switched off, running a test key. The attacker never extracted anything; they impersonated the HSM purely through black-box API calls. That detail matters because the PKCS#11 standard, which HSMs use, exposes a raw RSA mechanism that matches exactly the oracle this attack wants.
The economics work like this. About 2^32 queries against the raw oracle, and 1,380 core-years of compute, most of it precomputation. Once that precomputation is done, forging any chosen signature costs around 180 core-years, offline, per key. Compared with factoring, which needs hundreds of thousands of core-years before you even have the key, the forgery route is dramatically cheaper.
What this does to RSA’s security estimates
Extrapolating their measured runtimes, the authors put the concrete security of RSA under this oracle model at about 2^65 for 1024-bit keys, 2^90 for 2048-bit, and 2^119 for 4096-bit. NSA, NIST, and ENISA guidance all treat 2^128 as the minimum acceptable level. Even 4096-bit RSA fails that bar in this model, which is the finding that made cryptographers sit up. The paper frames it as RSA’s real security being 15 to 30 bits lower than the factoring-based estimates that key-size tables have always assumed.
Two honest caveats before anyone rewrites their threat model. First, 1024-bit RSA has been barred for new signature generation under NIST SP 800-131A for years, so the demonstration key size is already deprecated. Second, this is an unreviewed preprint. There is no independent reproduction yet, and the Hacker News discussion of the result was split between people impressed by the implementation and people pointing out how narrow the threat model is. Both camps have a point.
Who is actually exposed
The overwhelming majority of RSA in the wild is not. RSA used with PKCS#1 v1.5 or PSS padding, which is what TLS, SSH, code signing, and virtually every mainstream library do, does not provide the kind of oracle this attack needs. If your RSA goes through a standard library with padding enabled, the authors themselves say this result should not cause alarm.
The exposure is raw or textbook RSA, and the best-known example is blind-signature schemes. Privacy Pass is the headline case: it lets clients authenticate without revealing identity, it is used by Apple and Cloudflare among others, and it hands the signer exactly the oracle the attack wants. Pulling it off against Privacy Pass would require requesting roughly 2^43 tokens from the provider, which Heninger notes is on the same order of magnitude as the traffic Cloudflare says it handles in a day. Regular key rotation shrinks the window considerably but does not close it.
What to do this week
If you operate HSMs or token-issuance services, the audit list is short and concrete:
- Check whether any PKCS#11 configuration exposes raw RSA mechanisms, and disable or restrict them if so.
- Rate-limit and monitor signing oracles. The attack requires volume, and volume is visible.
- Retire any remaining 1024-bit RSA keys. This was overdue anyway; now it is overdue with interest.
- If you run a blind-signature protocol, rotate keys aggressively and watch the follow-up literature.
The bigger takeaway is the one the authors draw themselves: this is classical cryptanalytic evidence for moving off RSA entirely during the post-quantum transition, not just for growing key sizes. ML-DSA and the other NIST post-quantum signature schemes do not carry RSA’s factoring baggage at all. For years the advice has been “migrate eventually.” Results like this turn “eventually” into a schedule item.
I find it genuinely interesting that the breakthrough came from dusting off a 2007 algorithm rather than from anything new. The team wrote all the code by hand, no GPUs, no AI assistance, and they say those tools will almost certainly push the cost lower. Treat the published numbers as upper bounds and expect them to fall.