A preprint posted to the IACR ePrint Archive last week forges RSA signatures at 1024 bits. It does not factor the key, and it does not work against a system that simply uses RSA. It needs one specific thing first: temporary access to a raw RSA signing or decryption oracle — something that will sign or decrypt attacker-chosen bytes on request.
Both conditions have to hold. A 1024-bit key on its own is not enough, and a signing oracle in front of a larger key is a different calculation, which we will come back to. That "both" is why this is an audit question for most teams rather than an emergency — and it is also why the question is worth actually asking.
What the paper reports
Forging 1024-bit RSA signatures in nearly SNFS time is by Laura Shea, Miro Haller, Adam Suhl and Nadia Heninger of UC San Diego, with Emmanuel Thomé of INRIA Nancy. It was received by ePrint on 20 September 2026. It is a preprint — ePrint's "approved" status is an editorial screen, not peer review.
The work implements an algorithm published in 2007 by Joux, Naccache and Thomé, which the authors describe as under-appreciated. Given a raw signing oracle, it forges signatures in time close to the special number field sieve, rather than the general number field sieve that key-size guidance is normally extrapolated from. The distinction matters: the key is never factored, and it is never extracted.
The costs are the honest part of the result, and worth quoting plainly:
- 1380 CPU core-years of work, spread over five calendar months.
- 232 oracle queries — roughly four billion signing requests.
- Most of that is precomputation. Afterwards, forging any signature of choice takes 180 core-years, offline.
This is expensive and targeted. Nobody does it by accident, and nobody does it to a target they do not care about. But note what the precomputation buys: it is paid once per key, and every forgery after that is cheaper and needs no further access.
What a "raw signing oracle" actually means
The phrase sounds exotic. In practice it means any interface that will apply a private key to input it was handed, without checking what that input is.
The researchers used a hardware security module as their oracle. An HSM is designed so the key cannot leave it, and in this attack the key never does — the authors describe impersonating the HSM through black-box API interactions without exfiltrating the key. The security property the HSM guarantees held perfectly. It just turned out not to be the property that mattered.
The paper also names blind RSA schemes as providing such an oracle, which is inherent to how blind signing works: the signer, by design, does not see what it is signing.
In older systems the same shape tends to appear as an internal signing service that was built for one caller and later reused; a licence or token signer reachable from more of the network than anyone remembers; an internal PKI still on 1024-bit keys because nothing forced a rotation.
The part that complicates the obvious fix
The instinctive remediation is to increase the key size, and for factoring-based risk that reasoning is sound. In this attack model it does less than you would expect.
Extrapolating their measured running times, the authors conclude that the concrete security of RSA with a signing oracle is 15 to 30 bits lower than factoring-based estimates across the 1024-bit to 4096-bit range in common use. Their stated conclusion goes further: even 4096-bit RSA does not appear to reach a 128-bit security level in this model.
So "we are on 2048, we are fine" is the wrong shape of answer here. The durable mitigation is the other condition — not handing out a raw primitive. A signing interface that enforces a padding or message format, and refuses attacker-chosen inputs, is not the oracle this attack requires. That is unglamorous, and it is the part that keeps working as key sizes change.
The authors themselves read the result as classical cryptanalytic evidence for moving away from RSA during the current post-quantum transition — a direction plenty of teams are already being pushed in for unrelated reasons.
The question worth asking
We have not audited anyone's systems against this, and nothing here is a statement about any particular product or deployment. It is one question, and it has a concrete answer:
Does anything you run apply a private key to bytes a caller supplied, without checking what those bytes are?
If the answer is no, this paper is interesting and not urgent. If the answer is "probably not, but nobody has looked," that is the finding — and it is the kind of thing that tends to surface in legacy integrations, where a component was built for one trusted caller years ago and quietly acquired more of them.
The reassuring reading and the uncomfortable one are the same sentence: two independent things have to be true at once. Most systems will fail that test in the safe direction. It is worth knowing which way yours fails, rather than assuming.
Source: IACR ePrint 2026/2131, preprint, received 20 September 2026.