Estimated reading time: 5 minutes · Last updated:
A paper co-authored by researchers at UC San Diego and Inria Nancy describes a new attack that reduces the computing work needed to break textbook RSA keys. The authors report drops in the reported operation counts — for example, from 280 down to 265 for 1024-bit keys and from 2112 down to 290 for 2048-bit keys — if the paper’s assumptions and oracle conditions are met. The attack targets the textbook (raw) RSA variant and depends on an attacker performing very large numbers of oracle queries. The paper was posted to the IACR ePrint archive and is awaiting peer review; its core claim is that, under the stated conditions, the barrier to exploiting RSA ciphertexts could fall into reach of well-resourced adversaries.
Key takeaways
- Source: A paper by researchers at UC San Diego and Inria Nancy, posted to IACR ePrint, describes the attack.
- Work reduction: Reported operation counts drop from 280 to 265 for 1024-bit keys and from 2112 to 290 for 2048-bit keys, per the paper.
- Targets: The attack applies to textbook (raw) RSA implementations used in services such as Cloudflare Privacy Pass, iCloud Private Relay and Private Cloud Compute, and to PKCS #11-based devices.
- Practical bar: The attack requires repeated oracle queries — typically billions of probes against a live key or device — which raises the operational cost and detection risk.
Table of contents
What the paper claims and the numbers it reports
The team from UC San Diego and Inria Nancy published their methods and results on the IACR ePrint server. They describe an algorithmic approach that, under the paper’s oracle model and other technical assumptions, reduces the asymptotic and practical work the attacker must do to recover a private RSA key in textbook form. The paper gives concrete comparative figures: it reports cutting the operation count for 1024-bit keys from 280 to 265, for 2048-bit keys from 2112 to 290, for 3072-bit keys from 2128 to 2105, and for 4096-bit keys from 2144 to 2119.
Those strings of figures are the paper’s headline numbers and reflect the attack model the authors analysed. The paper also notes that the implementations used were not optimised and that the described algorithms could be sped up by further engineering work, including parallelisation on GPUs or assistance from AI-driven optimisation passes. Peer review remains pending, so the community has not yet validated real-world performance beyond the authors’ write-up.
Where the attack can apply and practical barriers to exploitation
The researchers emphasise the attack applies to the textbook (raw) variant of RSA, not to every RSA deployment. Textbook RSA lets an oracle be queried with arbitrary inputs and returns the corresponding RSA computation without protocol-level protections. That pattern appears in some deployed systems and in hardware where PKCS #11 interfaces or similar APIs accept wide ranges of inputs.
In practice, turning the paper’s algorithm into a working compromise requires the attacker to collect very large volumes of oracle outputs — the team describes scenarios that often imply billions of queries to the target key or device. That scale raises two deterrents: high computational cost and the chance of detection by network or device operators. The paper reports experiments against Thales Luna HSMs in both hardware and online service form, showing the authors could exercise the required oracle interactions in at least those lab settings.
Why services and hardware vendors should care now
Even though textbook RSA is not the dominant form of RSA used for web TLS certificates, the paper calls attention to real-world products and services that do use unpadded RSA or expose wide-ranging PKCS #11-like operations. The authors list Cloudflare Privacy Pass, iCloud Private Relay and Private Cloud Compute as examples of services where textbook RSA variants can appear, and they flag smart cards, USB security tokens, code-signing pipelines, HSMs and TPM modules as potential risk surfaces.
The other important concern the paper raises is deferred decryption: oracle data collected today could allow an attacker to decrypt archived traffic months later if the computational cost falls as the paper states or if implementations are optimised. The paper says the attack’s practicality depends on several factors and explicitly notes that its algorithms were far from optimised, meaning both attack techniques and the defences required could change as implementations are improved.
| Key length | Operations before | Operations after |
|---|---|---|
| 1024-bit | 280 | 265 |
| 2048-bit | 2112 | 290 |
| 3072-bit | 2128 | 2105 |
| 4096-bit | 2144 | 2119 |
How this could play out
The case for
- If peer review validates the paper and independent teams reproduce the work, vendors will gain a clear technical blueprint to test and harden PKCS #11 interfaces and HSM configurations.
- Optimisations that the authors say are possible could be matched by defensive engineering: tighter input filtering, rate-limiting of oracle operations, and protocol-level padding can materially raise the cost or block the attack.
The case against
- If further work reduces the constants the paper reports, the attack could move from a theoretical result into a tool usable by well-resourced adversaries, since the authors already suggest GPU and AI optimisations could speed it up.
- Unmonitored key management services or embedded devices with exposed raw-RSA operations may remain vulnerable for long periods, allowing archive breaches if collected oracle data is stored.
What to be careful about
- Archive decryption: stored ciphertexts that relied on textbook RSA variants could be decrypted later if attackers gather oracle data now and apply faster attacks later.
- Targeted compromise of PKCS #11-enabled devices, smart cards, or HSM instances that lack strict query limits or logging.
- State-capable adversaries with high compute capacity can plausibly exploit reduced-operation attacks if they can access an oracle or a poorly defended device.
The bottom line
The UC San Diego and Inria Nancy paper proposes a method that, if validated and reproduced, lowers the reported work to attack textbook RSA implementations and highlights real products where raw-RSA operations still appear. The practical impact hinges on two things: whether peer review and independent reproductions confirm the result, and whether adversaries can amass the large volumes of oracle data the authors describe. Vendors and operators who expose PKCS #11-like interfaces, smart cards, or HSM services should prioritise reviewing configurations and enforcing query limits or protocol-level padding to mitigate the risk.
What to watch
- watch for the paper’s peer-review outcome and any published responses from the cryptographic community; no date has been set.
- watch for replication efforts or optimised implementations that target HSMs such as Thales Luna HSMs; no date has been set.
Frequently asked questions
Does this attack break modern TLS certificates?
No. The paper targets textbook (raw) RSA, not the padded RSA variants used by modern TLS certificates. The authors specifically say the attack applies where raw-RSA or similar unpadded operations are exposed, such as certain PKCS #11 interfaces and some privacy services.
How much work does the paper say is required for common key sizes?
The paper gives comparative operation counts: for 1024-bit keys it reports a drop from 280 to 265, for 2048-bit keys from 2112 to 290, for 3072-bit keys from 2128 to 2105, and for 4096-bit keys from 2144 to 2119.
Who is most likely able to exploit this now?
The authors note the remaining bar is high: exploitation requires very large numbers of oracle queries, often billions, and substantial compute. That places practical risk primarily on well-resourced actors and on systems that expose unmonitored oracle access.
Related reading
