This content was generated with the help of AI and published without prior human review. It may contain errors and is not professional advice. Report a problem: info@delionsoft.com.
A team at the University of California at San Diego has described an attack that produces valid RSA signatures without ever recovering the private key. According to the original report, the method is practical today against 1024-bit keys and lowers the estimated security of 2048- and 4096-bit keys below the levels standards bodies accept. The work applies only to a narrow class of RSA deployments, and it still has to survive peer review.
What happened
Until now, the working assumption was that breaking RSA meant factoring the modulus. The paper, with Laura Shea as lead author and Nadia Heninger among the co-authors, uses a variant of the special number field sieve from 2007 combined with an oracle — a protocol that answers attacker-chosen queries — to forge signatures directly.
The numbers in the report are the interesting part. Factoring a 1024-bit key is estimated at around 2^80 operations and 500,000 to 1 million CPU core-years. The forgery took roughly 2^65 operations and 1,380 core-years, a few months on an academic cluster. Effective security drops to about 2^65, 2^90 and 2^119 for 1024-, 2048- and 4096-bit keys, against a requirement of at least 2^128 from NSA, NIST and the EU agency. The authors note they wrote everything by hand without GPUs, so the figures may fall further.
The important limitation: the attack targets blind-signature, or "textbook", RSA — no PKCS or PSS padding. The overwhelming majority of RSA in production uses padding and does not appear to be practically threatened. The best-known exception cited is Privacy Pass, the anonymous authentication protocol used by Apple, Cloudflare and others. There, an attacker would need on the order of 2^43 token requests, which the researchers compare to about a day of Cloudflare's traffic. Regular key rotation reduces the risk considerably without removing it.
Why it matters
For most SMB systems this changes nothing operationally today. TLS, code signing, JWT signatures and SSH keys with standard padding are not affected by what has been published. What changes is the assumption underneath your planning: the security margin of an RSA key is no longer defined solely by factoring difficulty, and a new class of attack has appeared in a cryptosystem thought to be well understood.
That matters for two practical reasons. First, teams that implemented unpadded RSA for blind signatures or anonymous tokens — usually in privacy or rate-limiting features — are now in a different position than last week. Second, if you were treating post-quantum migration as a problem for the 2030s, this is a reminder that classical attacks can also move.
What to do
- Inventory where RSA is used and how. Flag anything doing raw or blind RSA signatures without PKCS#1 v1.5 or PSS padding, including in-house token schemes and older integrations.
- Retire any remaining 1024-bit keys. They were already deprecated; the report makes forgery against them a matter of a modest compute budget.
- If you operate a blind-signature or anonymous-token service, shorten key rotation intervals and add rate limiting on token issuance per client.
- Treat crypto agility as a design requirement in the next roadmap cycle: pin algorithms in configuration, not code, so swapping signature schemes is a deployment, not a rewrite.