Researchers Forge RSA-1024 Signatures Without Factoring the Key
Security / analysis
Researchers Forge RSA-1024 Signatures Without Factoring the Key
A UC San Diego-led team spent 1,380 CPU core-years exploiting a 2007 algorithm to steal an HSM's signing ability while the private key never left the device.

A research team can now forge signatures from a 1024-bit RSA key without factoring it at all, provided an attacker gets temporary access to a raw, unpadded signing oracle and about 1,380 CPU core-years of computation. Researchers at UC San Diego and France's INRIA reported the result in a paper posted to the IACR ePrint archive on Sept. 20 and approved two days later.
The authors, Laura Shea, Miro Haller, Adam Suhl and Nadia Heninger of UCSD with Emmanuel Thomé of INRIA Nancy, implemented a 2007 algorithm by Antoine Joux, David Naccache and Thomé that had sat unrun at meaningful scale for nearly two decades, Hardware Busters reported. The team published its code publicly in a GitHub repository named NSNFSSSFSFN, short for "Nearly SNFS-Speed Signature Forgery Sans Factoring N."
What 1,380 core-years actually bought
An attacker who can extract raw signatures from a device for a while can turn those answers into a permanent ability to sign anything offline, exactly as if holding the private key, without ever factoring the modulus. The technique runs at the speed of the special number field sieve, or SNFS, a faster variant normally reserved for conveniently shaped numbers rather than the slower general sieve an RSA modulus demands.
For the 1024-bit demonstration, the team made 2^32 oracle queries, a little over 4.29 billion, over five calendar months, finishing on Aug. 31. Most of the 1,380 core-years went into one-time precomputation tied to the public key; after that, each additional forged signature costs about 180 core-years, computed entirely offline. The oracle in the demonstration was a hardware security module, so the attack amounts to impersonating the HSM through ordinary API calls, without extracting the key it guards.
Factoring the same 1024-bit modulus directly would take between 500,000 and 1 million core-years by the team's own estimate, Hardware Busters reported, putting the oracle-based route roughly 360 to 725 times cheaper.
- Factoring directly (low estimate)500K CPU core-years
- Oracle-based forgery (this paper)1380 CPU core-years
Source: Shea, Haller, Suhl, Heninger and Thome, IACR ePrint 2026/2131, via Hardware Busters, accessed 2026-09-24

Who actually needs to worry
The attack requires a raw, unpadded signing oracle, and ordinary TLS certificates do not expose one. The team's own FAQ in its GitHub repository is direct about this: asked whether a 2048-bit key using PKCS#1 v1.5 or PSS padding is at risk, the answer is "No, our attack does not seem to be feasible in this case." The FAQ also notes that TLS key exchange has largely moved to ECDH or ML-KEM, algorithms the attack does not touch, and that ECDSA and Ed25519 signatures are not vulnerable to this class of attack at all.
The exposure is narrower: blind RSA signature schemes, such as the ones behind Privacy Pass anonymous-token systems, and any HSM interface willing to perform raw RSA operations on request. Extrapolating their 1024-bit run, the researchers estimate a 2048-bit blind RSA key would take about 2^90 operations and 2^43 queries to break this way, against roughly 2^112 to factor the modulus outright, Hardware Busters reported. That gap is out of reach for all but the largest adversaries today, but it is a thinner safety margin than current standards assume.
Blind RSA matters here because the protocol's entire point is to hand a client a raw, unblinded signature it can later prove came from the server, which is exactly the kind of oracle access the 2007 algorithm needs. A content-delivery network or ad-fraud system relying on Privacy Pass tokens is trusting that no client can collect enough of those signatures to start forging its own. The paper's extrapolation says that trust now rests on a narrower margin than the 2048-bit key size implies, not that it has already failed.
The timing lines up with a separate GPU factoring surge
The paper landed in a month that already saw two RSA factoring records fall to GPU fleets: RSA-260 on Sept. 3 and RSA-896 on Sept. 19, both done by porting the open-source CADO-NFS factoring software to graphics cards with the help of AI agents, according to Hardware Busters. The UCSD and INRIA team ran its attack entirely on CPUs. Its FAQ answers plainly when asked whether it used AI or GPUs itself: "No." Asked whether GPUs could speed the forgery up further, the answer is "Almost certainly yes."
That combination, a slower classical technique running the month faster GPU-assisted factoring records are falling, is the detail that should worry standards bodies more than either result alone: the two approaches attack RSA from different directions, and both are getting cheaper at once.
The authors are not calling for an immediate RSA rip-out. Their recommendation is to treat the post-quantum migration already under way as the moment to leave RSA behind entirely rather than patch around it, a caution in the same spirit as AMD's own random-number generator defect, which sat unremarked in production chips for years before anyone measured it. In the meantime, the researchers give operators of blind-RSA systems specific homework: shorter key epochs and longer keys now, with zero-knowledge proofs added to the protocol later.
What would change this read is a working GPU port of the SNFS-oracle attack itself, the same kind of jump that just cut two factoring records down to size this month. Nobody has published one yet. Veeam's own privilege-escalation bug went from patched to publicly exploited in four months; how long this one takes is the number worth watching next.
Sources
More in Security
- 01CISA Gives Agencies 3 Days to Patch an Exploited SharePoint BugMicrosoft rated the flaw a low-risk spoofing issue for 16 days after patching it, and a honeypot logged the first attack four weeks after the correction upgraded it to an 8.8.
- 02CISA Adds a Fourth MikroTrick Bug to Its Exploited ListCVE-2026-67279 joins two other bugs from the same six-flaw MikroTik batch already on CISA's list, but Bishop Fox says it, not the pair flagged in September, is the one that actually opens the door.
- 03OpenClaw's New Scanners Agree on Just 0.69% of Risky SkillsFour audits since February have counted between 341 and 1,467 malicious or flawed skills on ClawHub, and NVIDIA's scanner disagrees with the other two on all but 468 of 67,453 skills checked.
- 04CISA Lists 14 Botslab Dashcam Flaws With No Fix in SightThe worst of the bugs lets a network attacker push firmware with no cryptographic signature onto the device, and Botslab has not told CISA whether it plans to fix any of the 14.