A private key stayed inside its hardware security module, yet researchers gained the lasting ability to impersonate it after 1,380 CPU core-years of work. That is the unsettling part of a new RSA result: an attacker with temporary access to raw signing operations can eventually create arbitrary signatures offline, without extracting the key or factoring its modulus. The paper's 1024-bit experiment cuts the estimated computation from 500,000 to 1 million core-years for factoring to 1,380. That comparison needs a boundary. The method needs raw, unpadded RSA, so the padded RSA signatures used in mainstream TLS deployments are not exposed by this attack.
Ars Technica reported the result as a new way to break RSA faster than previous methods. More precisely, the researchers forged signatures under a specific oracle model. Laura Shea, Miro Haller, Adam Suhl and Nadia Heninger of UC San Diego, with Emmanuel Thome of Inria Nancy, implemented a method proposed in 2007 and ran it at 1024-bit scale for the first time. Their computation finished on August 31 after five calendar months.
The attack front-loads the expensive work
The attack begins with the public RSA modulus. The team spent about 1,200 core-years on precomputation, then made 2^32 raw RSA queries to a hardware security module. That is roughly 4.3 billion signing operations. Once those answers were collected, forging one chosen signature took another 180 core-years and no further access to the HSM. The project repository describes the outcome as stealing abilities equivalent to the private key while leaving the key itself undiscovered.
That split changes the incident-response problem. Revoking an attacker's server access can stop fresh HSM calls, but it does not erase a completed precomputation or the raw signatures already collected. In the paper's delayed-target scenario, the attacker can return to the computation later and forge signatures for the same public key. Rotation ends that window because the precomputation is tied to the modulus. A long-lived raw-RSA key gives an attacker more time to finish both sides of the job.
The underlying math is a variant of the number field sieve from Antoine Joux, David Naccache and Thome's 2007 work. Factoring a normal RSA modulus uses the general number field sieve. This forgery runs close to the faster special number field sieve, normally associated with integers that have a helpful mathematical form. The UC San Diego and Inria team built its implementation on CADO-NFS, published the source and run data, and says its measured cost should be treated as an upper bound because the code and parameter choices can still improve.
Where the bit-security estimates fall
Only the 1024-bit result was demonstrated at full scale. The measured attack lands near 2^65 operations, compared with the conventional 80-bit estimate for factoring a 1024-bit RSA modulus. The authors extrapolate the method to 2^90 work and 2^43 oracle queries for 2048-bit RSA, down from the usual 112-bit factoring estimate. Their projected figures for 3072-bit and 4096-bit RSA are 105 and 119 bits of security. Those larger-key numbers are estimates from the algorithm and the measured run, not completed forgeries.
The 2048-bit projection remains far beyond a routine intrusion. The researchers note that 2^90 is about a thousand times more work than the 2^80 estimate for factoring a 1024-bit modulus, which has not been factored publicly. Their claim is about the security margin. Under this oracle model, even 4096-bit RSA misses the 128-bit level many modern deployments target. A future GPU implementation could lower the engineering cost, but the team did not use GPUs or AI for its run.
The experiment also supplies a reality check for the 1024-bit figure. The authors scanned 421 million domain names drawn from certificate transparency logs and completed 208 million TLS handshakes. RSA signed the transcript for 55.6% of the host certificates. Among those RSA certificates, 85.7% used 2048-bit keys and 17,455 used 1024-bit moduli. Yet the paper says these protocols use PKCS#1 v1.5 or RSA-PSS padding and do not present the raw signing oracle that this attack needs. Counting RSA certificates alone will therefore overstate exposure.
Raw RSA is the line to audit
The relevant inventory is narrower than every service with an RSA certificate. Teams need to find interfaces that perform raw private-key operations, especially HSM endpoints exposed through PKCS #11, plus protocols based on blind RSA signatures. The researchers used a real HSM as their oracle and interacted with it through its ordinary API. That black-box result matters for systems whose trust model assumes a compromised application server still cannot acquire the signing capability protected by the module.
PKCS #11 supports padded RSA signatures, and those modes are outside this attack as tested. Raw operations can remain enabled to support padding implemented by an application or older formats missing from the HSM API. The paper names electronic passports, digital tachographs and RSA full-domain-hash systems among the places where unusual modes may appear. An audit should ask which mechanisms a key permits, whether raw RSA is enabled, who can request operations, how many requests are possible during a key epoch and whether the logs would make billions of calls visible.
Blind signatures create the other direct fit. A client deliberately blinds a message, receives the server's RSA operation and later unblinds the result. The paper identifies the publicly verifiable form of Privacy Pass, used by Apple Private Access Tokens and services from Cloudflare, Fastly and Persona, as a deployed example. For 2048-bit blind RSA, the projected 2^43 queries are a stiff practical barrier. They are still part of the protocol rather than an accidental padding failure, so an attacker may be able to distribute collection across clients if issuance controls allow it.
The authors suggest shorter key epochs as an immediate defense for blind-RSA deployments, followed by larger keys and protocol changes such as proofs that a blinded message is well formed. Post-quantum replacements for blind signatures are still an open deployment problem. Ordinary RSA signature users do not need an emergency swap because of this paper, and ECDSA or Ed25519 signatures are not affected by this attack. Those elliptic-curve schemes remain vulnerable to a sufficiently capable quantum computer, so they are not a final post-quantum destination.
The next audit belongs in the migration plan
RSA was already on a retirement path because of quantum computing. NIST's transition plan says quantum-vulnerable algorithms will be deprecated and removed from its standards by 2035, with high-risk systems moving earlier. This result adds a classical reason to treat that migration as an inventory and protocol job instead of a future key-length change. RSA can be weaker than its factoring estimate when an application exposes the right oracle, even if the device holding the secret works as designed.
For developers, the useful response is specific. Keep PKCS#1 v1.5 and PSS deployments separate from raw or blind RSA in the inventory. Retire 1024-bit keys regardless of this result. Restrict HSM mechanisms to the operations the application uses, rate-limit signing access and rotate keys on a schedule short enough to break modulus-specific precomputation. A migration plan should also record where RSA semantics are baked into a protocol, since those sites cannot be fixed by replacing a certificate alone.
The paper has not yet turned a 2048-bit production key into a practical target. Watch for independent review of the extrapolation and any GPU port that lowers the measured cost. Privacy Pass and HSM vendors may then need to revisit their raw-RSA guidance. If an incident grants raw signing access, closing the server session should trigger a second containment step: rotate the modulus before an attacker can turn collected responses into an offline signing capability.