New Attack Against RSA Forges Signatures Without Recovering the Private Key

RSA researchers have completed a 1024-bit signature forgery using 1,380 CPU core-years, without factoring the public modulus or recovering its private key.

That result gives the New Attack Against RSA a striking headline, but the underlying algorithm dates to 2007. The actual advance is an implementation that carried the theoretical method through a full-scale computation.

The distinction matters because the attack does not defeat every RSA deployment. It targets systems that temporarily provide access to raw, unpadded RSA operations. Modern signatures using standardized encoding remain outside the demonstrated attack model.

Bruce Schneier’s attack assessment captures the central reversal. This is a real cryptanalytic result, but it is not a universal technique for extracting RSA private keys.

What Actually Changed in the New Attack Against RSA

Researchers turned an overlooked 2007 algorithm into a completed 1024-bit signature forgery against a real signing target.

Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger, and Emmanuel Thomé implemented the attack through a collaboration involving UC San Diego and Inria. Their 1024-bit computation finished on August 31, 2026.

The team released its paper and supporting code in September. The public materials describe the work as a signature forgery performed in nearly special number field sieve time.

That name refers to the attack’s asymptotic performance. A number field sieve is a family of algorithms for difficult number-theoretic computations, including factoring large integers.

The general number field sieve, or GNFS, is the fastest known classical method for factoring ordinary RSA moduli. The special number field sieve, or SNFS, performs better when an underlying problem has exploitable algebraic structure.

The new implementation effectively moves part of the attack into the faster category. It does so without turning RSA cryptanalysis into an easy or polynomial-time problem.

The researchers report that the computation consumed 1,380 CPU core-years. Parallel processing reduced that total work to several months of elapsed time on an academic computing cluster.

That remains a substantial undertaking. However, the team estimates that factoring the same 1024-bit modulus would require between 500,000 and one million CPU core-years.

These estimates are not directly interchangeable with a universal financial cost. Hardware, software, memory, networking, and implementation choices all affect real operating expenses.

They still establish the central technical result. Under the required oracle conditions, forging RSA signatures can demand far less computation than factoring the associated modulus.

An oracle is a system that performs a cryptographic operation on attacker-selected input and returns the result. Here, the attacker needs temporary access to raw RSA signing or decryption operations.

The access does not need to remain available forever. After completing a large precomputation tied to the public key, the attacker gains an offline ability to produce additional valid outputs.

That persistence makes the result more important than an ordinary misuse of a signing service. The attacker can retain forgery capability after losing access to the original oracle.

The team’s researchers’ explainer says this capability resembles stealing the secret key in its practical effects. It does not mean the actual private factors were recovered.

The researchers also published their implementation and intermediate data. That transparency lets other cryptographers reproduce assumptions, inspect engineering decisions, and test proposed countermeasures.

The completed run is therefore the news event. The mathematics that enabled it has been public for almost 19 years.

Why a 2007 Algorithm Matters Now

The implementation changes RSA’s security estimates under a specific attack model, even though it does not introduce a new mathematical shortcut.

Antoine Joux, David Naccache, and Emmanuel Thomé described the underlying technique in their 2007 paper. They studied when computing certain roots modulo an RSA number becomes easier than factoring that number.

In simplified terms, RSA applies exponentiation modulo a composite number. A private operation computes a root that should remain infeasible without knowledge of the secret key.

The 2007 work showed that selected oracle responses could reveal enough structure for a faster attack. Its authors described outcomes ranging from selective forgeries to universal forgery capabilities.

That result never implied that attackers could passively observe an ordinary RSA public key and immediately forge signatures. It required repeated access to carefully structured private-key operations.

Until 2026, nobody had publicly demonstrated the complete process at the 1024-bit scale. Large cryptanalytic computations require more than a complexity expression printed in a paper.

Researchers must build suitable polynomial selections, collect relations, process enormous datasets, perform sparse linear algebra, and complete the final reconstruction. Small inefficiencies can multiply across months of work.

The new team connected those stages and demonstrated the result against a 1024-bit target. Much of its implementation builds upon CADO-NFS, an established software suite for number field sieve computations.

This difference between theory and implementation is central to the New Attack Against RSA. The algorithm was known, but its practical constants and engineering requirements had remained uncertain.

A completed calculation turns those unknowns into evidence. It shows that the computational gap between forgery and factoring is not merely an asymptotic curiosity.

For the demonstrated target, the researchers estimate an attack cost near 2^65 operations. They contrast that figure with roughly 2^80 work for factoring a comparable 1024-bit RSA modulus.

For larger keys, they estimate approximately 2^90 work against 2048-bit RSA and 2^119 against 4096-bit RSA under the vulnerable oracle model.

Those larger attacks were not completed. They are projections derived from the algorithm, measured implementation performance, and expected scaling behavior.

The projections deserve attention because security strength measures the expected work needed to break a system. NIST defines an S-bit security strength as roughly 2^S basic operations.

However, those figures apply to the exposed construction, not every use of an RSA key. A protocol’s encoding, access controls, rate limits, and key lifetime remain part of its effective security.

The comparison also needs context. A 2^90 computation is vastly harder than the completed 1024-bit experiment, even if it falls below a desired theoretical margin.

The researchers say it would require about 1,000 times more work than a 2^80 computation. No public team has yet completed the corresponding 1024-bit factoring task.

The result therefore pressures security models more than current production systems. Designers can no longer assume that factoring always supplies the best attack estimate for raw RSA operations.

That correction matters for hardware security modules, blind-signature protocols, and specialized interfaces. These systems sometimes expose the private RSA operation while trying to restrict what it can authorize.

If the surrounding protocol provides the needed oracle, a key-length estimate based only on GNFS can overstate security. The implementation gives designers a concrete reason to revise that analysis.

The New Attack Against RSA Is Forgery, Not Key Recovery

The attack defeats a signing capability under chosen-input conditions, but it does not derive the RSA private key from public information.

RSA keys contain a public modulus and exponent, plus private values derived from the modulus’s secret prime factors. Conventional factoring attacks seek those factors.

Recovering them gives an attacker the actual private key. That key can support every operation authorized by the affected RSA construction, subject to protocol details.

This signature-forgery technique follows another path. It uses responses from a raw RSA oracle to prepare data that supports later root computations.

The attacker begins with temporary access to a device or protocol performing unpadded private-key operations. The attacker submits many specially selected values and records the responses.

The precomputation then searches for algebraic relationships using a number field sieve variant. Once enough relationships are collected, the attacker can combine them to forge chosen outputs.

Most of the expensive computation depends on the public key. After that stage, producing individual forgeries becomes substantially cheaper.

The result can resemble private-key theft from a defender’s perspective. An unauthorized party may generate signatures that verify under the genuine public key.

Still, the mechanism and scope remain different. The public modulus has not been factored, and the private exponent has not necessarily been reconstructed.

That distinction affects incident response. Replacing the affected key stops future verification under that public key, just as it would after an ordinary compromise.

It also affects vulnerability assessment. A system without the required raw signing interface does not become vulnerable merely because it uses an RSA certificate.

Calling the work a break of “RSA keys” can blur these boundaries. It may suggest a passive attack that starts with only a certificate or public key.

The demonstrated attack requires more. It needs an interactive source of chosen raw RSA results and enough queries before the source disappears or the key rotates.

The researchers’ full paper frames the contribution as forging signatures in nearly SNFS time. That wording accurately identifies both the result and the complexity improvement.

It also prevents another common misunderstanding. Subexponential does not mean polynomial, instantaneous, or inexpensive.

Polynomial-time algorithms scale with a fixed power of their input size. Subexponential algorithms grow faster than polynomial algorithms, although slower than fully exponential ones.

Both SNFS and GNFS belong to the subexponential category. The attack is faster because its constants and structure are more favorable, not because it eliminates hard computation.

The completed experiment used CPUs rather than GPUs. The researchers also say they did not use artificial intelligence to optimize their code.

They believe GPUs and additional implementation work can improve performance. That is a reasonable research direction, but it is not a measured result from this experiment.

Claims about dramatic GPU acceleration therefore remain speculative. Number field sieve workloads contain several stages, and each stage responds differently to specialized hardware.

The demonstrated benchmark is 1,380 CPU core-years across the team’s actual implementation. Any lower future figure should come from reproducible code and completed measurements.

This is the article’s main tension. The work is a meaningful break from factoring-based assumptions, yet it is not a general-purpose RSA key recovery method.

The Real Exposure Is Narrow but Not Zero

Ordinary padded RSA signatures are not the demonstrated target, while raw signing interfaces deserve immediate review.

Modern RSA signatures do not normally apply the private exponent directly to an unrestricted message. They first encode a message digest using a defined signature scheme.

RSASSA-PSS adds randomized formatting before the RSA operation. PKCS #1 v1.5 uses a structured deterministic encoding with identifiers and padding.

These encodings prevent an attacker from choosing arbitrary raw integers for signing. That restriction blocks the oracle behavior required by the new implementation.

The research team says its attack does not appear feasible against common RSA signatures using PSS or PKCS #1 v1.5. Schneier reaches the same practical conclusion.

This means conventional certificates, TLS authentication signatures, signed software, and tokens are not automatically exposed. Administrators should verify the actual algorithm and interface before drawing conclusions.

Key length alone does not answer the vulnerability question. A 2048-bit key behind a raw signing API has different exposure from the same key restricted to validated PSS signatures.

The clearest candidates for review are hardware security module interfaces that permit raw private-key operations. Applications sometimes request such access to implement custom protocols outside the module.

That flexibility can weaken the boundary the module was meant to provide. The private key never leaves the device, yet the available operation can become a signing oracle.

Blind signatures require closer analysis because their purpose involves signing content hidden from the signer. A client transforms its message, obtains a signature, and then removes the blinding factor.

This design supports privacy-preserving authentication and digital cash applications. It also creates an interface where the client influences the value processed by the private key.

Modern blind RSA protocols add encoding and verification requirements. The current blind-signature standard uses RSA-PSS encoding around the client’s prepared message.

However, the signing server still performs an RSA private operation on a blinded representative. The new paper analyzes how such interfaces can expose the raw oracle needed during issuance.

Privacy Pass is a frequently cited use case. It lets a client obtain anonymous tokens that services can verify without linking issuance to later redemption.

Apple and Cloudflare have used Privacy Pass-related technology in privacy services and challenge-bypass systems. That does not establish that every deployment is exploitable.

A successful attack against a live service would need the correct construction, a stable public key, and enough accepted oracle queries. Operational controls can change the calculation.

The researchers estimate that attacking a 2048-bit blind RSA key requires about 2^43 oracle queries, alongside the much larger offline computation.

That query count exceeds eight trillion. It is enormous for an individual user, although large distributed services process traffic on comparable aggregate scales.

Rate limiting can restrict requests tied to one account, device, network, or credential. Abuse detection can also identify unusually repetitive issuance patterns.

Key rotation reduces the available collection window. If a service replaces its RSA key before an attacker gathers enough responses, prior queries cannot simply transfer to the new key.

Short key epochs therefore raise operational costs for the attacker. They do not change the mathematics or fully replace a protocol-level defense.

The researchers suggest that zero-knowledge proofs could provide a stronger medium-term response. Such proofs can constrain client inputs without revealing the hidden message.

Longer RSA keys also increase attack costs, but the paper questions their security margins under this oracle model. The authors estimate less than 128-bit strength even at 4096 bits.

That does not mean attackers can now forge 4096-bit signatures. The 2^119 estimate remains far beyond the completed 1024-bit calculation.

It does mean protocol designers should not treat larger keys as the only long-term answer. A vulnerable interface can preserve the same structural problem at a higher cost.

For most organizations, the correct response is an inventory rather than an emergency shutdown. Security teams should locate RSA keys and identify every permitted private-key operation.

They should distinguish encryption, conventional signatures, blind signatures, certificate issuance, token signing, and custom HSM calls. Each path exposes a different attack surface.

Teams should confirm that applications request named signature mechanisms instead of generic modular exponentiation. They should also reject malformed encodings before accepting signed objects.

Current NIST key-management guidance already treats 1024-bit RSA as obsolete for modern protection requirements. This experiment adds another reason to remove lingering deployments.

A 1024-bit raw signing service deserves urgent remediation. A standard 2048-bit PSS deployment does not face the same immediate finding, although broader migration planning still matters.

What Defenders Should Watch Next

The next three signals are independent reproduction, protocol-specific analysis, and measurable changes to real implementations.

First, cryptographers should independently reproduce the 1024-bit computation and review the paper’s scaling estimates. Reproduction can test whether the reported cost includes every material stage.

It can also reveal implementation bottlenecks that either strengthen or weaken the projections. A lower reproducible cost would increase concern about exposed raw signing interfaces.

A materially higher cost would not erase the conceptual result. It would narrow the operational threat and make the larger-key estimates less urgent.

Second, standards groups and protocol designers should publish analyses for blind RSA constructions. Generic statements about “padding” are insufficient when blinding changes what the signer processes.

The important question is whether a concrete protocol gives attackers the oracle responses assumed by the paper. Query authentication and key rotation must enter that assessment.

Privacy Pass deployments deserve particular attention because they combine privacy goals, repeated token issuance, and widely distributed clients. Public design reviews can separate theoretical exposure from reachable attacks.

A protocol revision requiring stronger input proofs would reinforce the researchers’ warning. A convincing proof that common deployments deny the required oracle would narrow the result’s practical scope.

Third, defenders should watch HSM vendors and cryptographic libraries. Documentation, API defaults, audit rules, and deprecation notices reveal how the industry interprets the finding.

An HSM can protect key material while still exposing a dangerous operation. Vendors may restrict raw RSA calls, add query controls, or recommend mechanism-specific interfaces.

Library maintainers may also tighten low-level APIs. Deprecating raw private exponentiation would reduce the chance that developers accidentally construct an exposed signing oracle.

None of these signals requires abandoning every RSA certificate immediately. The demonstrated attack does not reach standardized padded signatures through passive observation.

RSA still faces a separate long-term problem from cryptographically relevant quantum computers. Post-quantum migration programs already give organizations an opportunity to reduce dependence on legacy algorithms.

NIST standardized its first post-quantum signature algorithms in 2024. Migration will still take years because certificates, hardware, protocols, and operational tooling must change together.

The new attack supports crypto-agility planning, meaning systems can replace algorithms without redesigning an entire product. It does not justify skipping compatibility tests or emergency-changing unaffected systems.

Security leaders should ask four concrete questions now. Do any services still use 1024-bit RSA, expose raw private-key operations, implement blind RSA, or retain one key for unusually long periods?

A “yes” should trigger protocol review, logging analysis, and a migration schedule. It should not trigger an unsupported claim that the private key has already been extracted.

The New Attack Against RSA is significant because it replaces an old theoretical warning with a completed computation. Its practical boundary is equally important.

Treat the result as a test of cryptographic assumptions and interface design. Verify which operations your systems expose, then track reproductions and protocol-specific findings before deciding the response.