How IACR ePrint 2026/2131 Forged 1024-Bit RSA Signatures Through a Hardware Security Module Without Factoring the Key, and What It Means for Blind RSA in Privacy Pass
Locksmiths have an old technique called impressioning. A blank key goes into the lock, the locksmith turns it against the pins, pulls it out and files away the faint marks the pins have left. After enough rounds the blank opens the lock. The locksmith never sees the original key and never takes the lock apart. The lock itself, answering one question at a time, supplies everything needed to copy it.
A paper submitted to the IACR Cryptology ePrint Archive on 20 September 2026 and approved on 22 September does something similar to RSA. ePrint 2026/2131, "Forging 1024-bit RSA signatures in nearly SNFS time", by Laura Shea, Miro Haller, Adam Suhl and Nadia Heninger of UC San Diego and Emmanuel Thomé of Inria Nancy, shows that an attacker who can ask a device for raw RSA signatures for a while can afterwards sign anything with that key, without ever holding it. The algorithm was published in 2007 by Joux, Naccache and Thomé. This is its first public implementation at a real key size, and the preprint has not yet been peer reviewed.
Practical takeaway. The attack needs a raw, unpadded RSA signing or decryption oracle on the target key. An interface that only signs with PKCS#1 v1.5 or PSS padding, which is how TLS, DKIM, DNSSEC and most OAuth tokens use RSA, does not provide one. Padding protects a key only while no other interface exposes raw operations on that same key. HSMs with raw RSA enabled and blind RSA schemes such as publicly verifiable Privacy Pass do expose them, even when the final signature is PSS-encoded. For 2048-bit blind RSA the authors estimate 290 work, well below the 112 bits usually assigned to that key size and still far beyond any public computation. The practical inventory question is where raw RSA is switched on, and for how long a blind-signing key stays in service.
What the UC San Diego and Inria team computed, and how long the 1,380 core-years took
The attack has three phases. First comes a large precomputation that depends only on the public key. Then the attacker sends about 232, roughly 4.3 billion, carefully chosen messages to the signing device and keeps the answers. Finally, with those answers in hand, the attacker can compute a valid signature on any new message offline. According to the ePrint abstract, the whole run took 1,380 CPU core-years over five calendar months, and once the precomputation is done, forging a chosen signature takes about 180 core-years. The authors' code repository, built on the open-source CADO-NFS toolkit, says the computation finished on 31 August 2026 and that no GPUs or AI tools were used, while adding that both could "almost certainly" speed it up.
For scale, the same notes put the cost of factoring a 1024-bit modulus at 500,000 to 1,000,000 core-years, and no 1024-bit RSA key has been factored in public. The forgery costs a few thousandths of that. The name of the paper explains why. Factoring an ordinary RSA modulus needs the general number field sieve. The 2007 algorithm runs in roughly the time of the special number field sieve, the faster variant used for numbers with a convenient shape, because the oracle queries let the attacker choose the numbers the sieve works on. Earlier this month we looked at Stephen Weis's claim to have factored RSA-896 with Claude on idle GPUs. That claim concerns factoring. This paper takes a different route to the same practical result for anyone who can query the key.
How a Thales Luna HSM became the signing oracle once FIPS-approved mode was switched off
Hardware security modules exist so that a private key never leaves tamper-resistant hardware. Certificate authorities, payment networks and code-signing pipelines rely on them. The researchers used two: a Thales Luna K6 card in their own server and a network-attached Luna S750, located on another continent, which a third party let them query remotely. In the paper's account of the setup, they disabled the module's FIPS 140-2 approved mode to enable raw RSA, the PKCS#11 mechanism CKM_RSA_X_509, imported a 1024-bit key and sent their queries through ordinary API sessions.
The HSM did exactly what it was built to do. The key never left the hardware. The authors' point is that black-box access to a raw signing interface can be enough to acquire the key's power, which is the one outcome the hardware was supposed to prevent. They also explain why raw mode gets switched on in real deployments: to support padding schemes the HSM API does not offer. The examples they give are ISO 9796-2, used for active authentication in e-passports and in the digital tachographs of commercial trucks, ANSI X9.31, and RSA-FDH, used in GNU Taler and in the verifiable random function of RFC 9381. Software keystores can expose the same thing; the paper notes that Android KeyMint allows unpadded RSA decryption.
Why blind RSA in Privacy Pass, Apple Private Access Tokens and GNU Taler is exposed by design
Blind signatures let a server sign a message it cannot see. That property protects privacy: a website can learn that a visitor passed a human check earlier without learning who the visitor is. It also means the signer answers queries it cannot inspect, which is the oracle the attack needs. RSABSSA encodes the message with PSS on the client side, and the finished signature verifies as an ordinary PSS signature. The server still applies the raw private-key operation to whatever blinded value it receives, so the PSS encoding gives it no protection against chosen queries. The IRTF's Crypto Forum Research Group specified the scheme as RSABSSA in the informational RFC 9474 (October 2023), and the publicly verifiable token type in RFC 9578 (June 2024) uses it. The paper names Apple Private Access Tokens, Fastly, Persona and Cloudflare as production users.
The authors work through the numbers for 2048-bit keys. The attack would need about 243 signing queries, which the paper compares with Cloudflare's own figure of more than 7 trillion HTTP requests a day. Apple appears to limit token issuance to one per minute per device, so the paper estimates that 2.3 billion devices would need 2.3 days to supply that many queries. For GNU Taler, a privacy-preserving payment system whose coins are minted with blind RSA-FDH signatures, the estimate is that an attacker would have to mint about $88 billion in one-cent coins before forging at will; Taler also supports a Schnorr-based blind scheme that the attack does not reach. The suggested mitigations follow the same time horizon: rotate blind-signing keys often now, move to longer keys next, and in the long run add zero-knowledge proofs or adopt post-quantum blind signatures once acceptable ones exist.
The civic stake is easy to miss. Privacy Pass and e-cash designs exist to let people prove something about themselves without being followed from site to site. A forged token undermines the trust those systems give to anonymous users, and the usual fix, identifying users more closely, would defeat their purpose.
Which RSA uses fall outside the attack: PKCS#1 v1.5 and PSS signatures in TLS, DNSSEC, DKIM and OAuth
The authors are careful here and deserve to be quoted carefully. Their code notes say the work "likely does not pose an immediate operational threat to most deployed RSA in the real world," and that for a 2048-bit key used with PKCS#1 v1.5 or PSS padding the attack does not seem feasible. Elliptic-curve signatures such as ECDSA and Ed25519 are outside the attack, as is key exchange with ECDH or ML-KEM.
Section 7.4 of the paper still shows how much 1024-bit RSA remains in service, all of it with padded signatures and no obvious oracle. A scan of 421 million domain names found 17,455 TLS host certificates with 1024-bit moduli. Of the 1,361 top-level domains that answered on 8 September 2026, 1,212, or 89 percent, used 1024-bit RSA zone-signing keys in DNSSEC. A third of the RSA DKIM keys on a sample of 1,048 mail domains were 1,024 bits, and Atlassian documentation updated in September 2026 still told users to generate 1024-bit keys for OAuth. None of these is directly exposed today. They show how slowly a deprecated key size leaves the infrastructure, and a raw oracle can also be manufactured from a Bleichenbacher-style padding flaw, a case the paper discusses in its section 7.3.
What 290 for RSA-2048 and 2119 for RSA-4096 mean for NIST's 2030 and 2035 dates
The paper extrapolates its running times to larger keys. In the oracle setting, 1024-bit RSA drops from the customary 80 bits of security to about 65, 2048-bit RSA from 112 to about 90, and 4096-bit RSA reaches about 119 bits with 257 queries, short of the 128-bit level. The abstract puts the general gap at 15 to 30 bits below factoring-based estimates. The authors call these projections an upper bound, since their implementation is far from optimal. They are extrapolations, and none has been demonstrated above 1,024 bits.
NIST disallowed 1024-bit RSA for new signatures after 2013 under SP 800-131A, while still allowing legacy verification. Its draft transition plan, IR 8547 of November 2024, would deprecate 112-bit RSA after 2030 and disallow it after 2035 because of the quantum threat. ePrint 2026/2131 supplies a second, classical argument for the same dates in the places where RSA answers raw queries. It does not move either date. The authors' own reading is that the post-quantum transition is a good moment to leave RSA entirely.
How Quentir Reads It
Most post-quantum planning sorts cryptography by algorithm and key size. This paper shows that the signing interface matters as much. A 2048-bit key used only through a PSS signing interface keeps its usual margin. The same key falls to about 90 bits in this model once any interface, a blind-signing endpoint or an HSM partition with raw RSA enabled, answers raw queries on it. An inventory that lists "RSA-2048" without the mechanism, the padding and the query exposure misses that difference, and the difference is visible in configuration files today, years before any quantum computer matters.
There is also a lesson about certification. The Luna modules were certified hardware; the attack ran after approved mode was switched off for a legitimate-sounding reason. That makes the mode setting of every HSM partition a governance fact worth checking, alongside the FIPS certificate number. The privacy-token case is harder, because blind RSA was chosen for good reasons and the post-quantum replacements the authors hope for are not yet standardized. Operators running those services will have to decide on key lifetimes before the standards arrive. Our Signature Report, The PQC Migration Roadmap for Boards, treats the transition as a phased decision: which obligations bind and on whom, and the milestones that can be commissioned. Raw RSA mechanisms and blind-signing key lifetimes belong in the inventory it describes. The open question worth watching is whether NIST or the IRTF responds with guidance on raw RSA mechanisms and blind-signature key lifetimes before the 2030 deprecation arrives.
Sources: Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger and Emmanuel Thomé, "Forging 1024-bit RSA signatures in nearly SNFS time", IACR Cryptology ePrint Archive, Paper 2026/2131 (received 20 September 2026, approved 22 September 2026; preprint, PDF), sections 1, 4.5, 6, 7 and 8; the authors' repository ucsd-hacc/NSNFSSSFSFN (README and FAQ, accessed 29 September 2026); Antoine Joux, David Naccache and Emmanuel Thomé, "When e-th Roots Become Easier Than Factoring", IACR ePrint 2007/424; IRTF, RFC 9474, RSA Blind Signatures (October 2023); IETF, RFC 9578, Privacy Pass Issuance Protocols (June 2024); NIST, IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards (November 2024); NIST SP 800-131A (January 2011) and SP 800-131A Rev. 3 (initial public draft, October 2024) as cited in the paper; Quentir, Stephen Weis and RSA-896 (September 2026).
Published intelligence, built to inform your own decisions. Published: September 29, 2026.