In September 2026, researchers at UC San Diego and Inria Nancy published Forging 1024-bit RSA signatures in nearly SNFS time. The headlines called it a new way to break RSA. The real finding is narrower, and for most organizations far less urgent, but it matters for a few specific systems and it is a good reason to retire old keys.

What the researchers did

The team, Laura Shea, Miro Haller, Adam Suhl, and Nadia Heninger at UC San Diego and Emmanuel Thomé at Inria, built the first full implementation of an algorithm Joux, Naccache, and Thomé described in 2007, and ran it at scale.

The attacker needs temporary access to a system that will sign or decrypt any number the attacker chooses with the victim's RSA key. For a 1024-bit key, the researchers sent about four billion such requests (232) to a hardware security module, then spent 1,380 CPU core-years of computation, which took five months. After that, they could forge signatures with that key offline, whenever they liked, without ever learning the private key. After that precomputation, forging a signature took about 180 core-years more.

That is a lot of computing, but it is far less than breaking the key outright. The researchers put factoring the same 1024-bit key at 500,000 to 1,000,000 core-years. Their wider conclusion is that wherever such an oracle exists, RSA is 15 to 30 bits weaker than factoring estimates suggest for 1024-bit to 4096-bit keys, and even 4096-bit RSA falls short of the 128-bit security level modern systems aim for.

Why "textbook RSA" is the weak point

RSA signing is a calculation performed on a number. Textbook RSA, also called raw or unpadded RSA, performs that calculation on whatever number it is given.

The signature standards used in practice work differently. PKCS#1 v1.5 and RSA-PSS first hash the message, then wrap the hash in a fixed structure, called padding, before the calculation. The signer only ever signs numbers with that structure. This attack depends on choosing the exact numbers to be signed, billions of specially chosen ones, and padding takes that choice away from the attacker.

The authors are clear about this. Most real-world RSA uses PKCS#1 v1.5 or PSS padding and does not expose a raw signing oracle, "and thus this attack does not pose a practical risk." Asked about 2048-bit keys with PKCS or PSS padding, their answer is that the attack "does not seem to be feasible."

Who is exposed

  • Blind RSA signatures. Privacy-preserving token systems such as Privacy Pass, used by Apple and Cloudflare, have the signer sign a number it cannot see. That is a raw signing oracle by design. For 2048-bit keys the researchers estimate about 290 operations and 243 requests, which is out of reach for all but the largest adversaries, but below the margin these systems want.
  • Hardware security modules, smart cards, and key management services that offer raw RSA. Many expose a raw RSA mechanism to applications (in the PKCS#11 interface it is called CKM_RSA_X_509). Anyone who can call it can feed it chosen numbers.
  • Anything still using 1024-bit RSA. Even where this attack does not apply, 1024-bit keys are past their time. The researchers' advice for 1024-bit keys is short: change your key.

TLS key exchange is not affected, because modern TLS uses elliptic-curve or post-quantum key exchange rather than RSA. Ordinary certificates, tokens, and code signatures that use PKCS#1 v1.5 or PSS with 2048-bit or larger keys are not practically exposed.

What to do

  1. Find and replace 1024-bit RSA keys. Look at certificates on internal devices and appliances, SSH keys, code-signing keys, and DKIM email-signing keys, where 1024-bit keys are still common on older domains.
  2. Check your HSMs and key management services. Turn off raw RSA mechanisms unless an application needs them, limit which applications can request signatures, and alert on unusual signing volumes. This attack needs billions of requests, so it is noisy.
  3. If you run blind signatures, rotate keys more often, consider larger keys, and follow the protocol's updates.
  4. Plan the move away from RSA. There is no need to rip RSA out today. The authors do recommend moving away from it over time, and note that elliptic-curve signatures such as ECDSA and Ed25519 do not appear vulnerable to this kind of attack. The coming post-quantum transition is the natural time to do it.

How Lavawall® uses RSA

After the paper was published, ThreeShield reviewed every place Lavawall uses RSA: the console, the agents on your computers, the network scanners, the remote support relay, and the background services. Here is what we found.

  • No raw RSA anywhere. Every RSA signature Lavawall creates or checks uses standard PKCS#1 v1.5 or PSS padding over a SHA-256 hash, and every RSA encryption uses standard padding too. No part of Lavawall will sign or decrypt a number that someone else supplies, so there is no oracle for this attack to use.
  • No blind signatures. Lavawall does not use them.
  • No 1024-bit keys. The RSA keys Lavawall generates are 2048 or 4096 bits.
  • Newer protections do not use RSA at all. End-to-end encrypted remote support sessions use elliptic-curve cryptography for key agreement and signatures, and the tamper-evident activity log is signed with Ed25519.

The review found nothing to change for this attack. We agree with the researchers that RSA should be retired over time, and new Lavawall security features are built on elliptic-curve cryptography.

Not sure where your organization still relies on 1024-bit RSA keys, or whether your HSM or key management service allows raw RSA? ThreeShield can review your keys, certificates, and signing systems with you.

Book a Consultation

Figures are from the researchers' paper and published FAQ as of October 2026. The paper was a preprint, not yet peer reviewed, when this was written.