Security teams are buzzing about the "new RSA attack" making headlines. With your encrypted communications, API authentication, and certificate infrastructure relying on RSA, you need to know what's truly at risk when such vulnerabilities are reported.
Here's what you need to understand about this attack and how it affects your cryptographic implementations.
Understanding the RSA Forgery Attack
The attack in question involves forging RSA signatures without accessing private keys. Originating from research in 2007, it's now feasible with modern computing power. The attack requires 1380 CPU core-years to forge messages for 1024-bit RSA, completed in five months by researchers.
However, this attack only targets unformatted, unpadded signatures, which aren't typically used in production systems. Despite this, questions arise because cryptographic vulnerabilities can evolve from theoretical to practical threats quickly.
Do You Need to Rotate Your RSA Keys?
No, this isn't a key compromise scenario.
The attack forges signatures for specific messages without extracting your private key. If you're using RSA with PKCS#1 v1.5 padding or PSS (Probabilistic Signature Scheme), you're protected. Instead, audit your systems to ensure:
- No custom signature implementations skip formatting
- Legacy systems have adopted PKCS#1 v1.5
- API endpoints don't accept raw RSA operations without padding verification
If you find unformatted signature schemes, that's your cue to rotate keys, not the attack itself.
Are 1024-bit RSA Keys a Target?
Your concern should be broader than this attack.
NIST deprecated 1024-bit RSA in 2013. The risk of factoring alone justifies moving to 2048-bit or 3072-bit keys. While this forgery attack requires significant resources, 1024-bit keys are already vulnerable to well-funded adversaries.
Treat this as a prompt to modernize your cryptographic practices. You're not just defending against this attack; you're addressing a long-standing vulnerability.
Comparing to Other Cryptographic Vulnerabilities
This attack is slower and more limited than many others.
It takes months and substantial resources, unlike a padding oracle that yields results in seconds. The attack targets unformatted signatures, meaning RSA must be incorrectly implemented to be vulnerable.
Contrast this with Bleichenbacher's padding oracle attack, which affects correctly implemented systems, or hash collision attacks against MD5 and SHA-1, which compromised the entire PKI ecosystem.
This forgery attack is significant for cryptographic research and systems using raw RSA signatures but doesn't alter your threat model if you're following current standards.
Implementing RSA Signatures Correctly
Use PKCS#1 v1.5 or PSS formatting. Avoid raw RSA operations.
PKCS#1 v1.5 has been standard since 1998, and PSS, specified in PKCS#1 v2.1, offers better security proofs. Both add structured padding that prevents this forgery attack. For new systems, prefer PSS.
In your validation logic, reject signatures that don't match the expected format. For APIs, require explicit format parameters. Don't let clients specify "RSA" without declaring the padding scheme.
Rethinking Cryptographic Agility
This attack highlights the need for cryptographic agility.
Cryptographic agility means you can swap algorithms without overhauling your systems. Build your signature validation to accept multiple algorithms. Support RSA with proper formatting today, but prepare for future migrations to EdDSA or ECDSA.
The computational cost of this attack will decrease over time. Your cryptographic strategy should anticipate this trend.
Are RSA TLS Certificates at Risk?
No, TLS certificates use formatted RSA with proper padding.
TLS certificates are signed using PKCS#1 v1.5 or PSS, following the X.509 standard. Even if an attacker could forge a signature, they'd need to match the certificate structure and chain to a trusted root.
The risk lies with certificate authorities using non-standard signature implementations, violating CA/Browser Forum requirements. If you're a CA, audit your infrastructure. For consumers, this attack doesn't change your validation logic.
Next Steps
Review the original research paper for detailed insights. If you're implementing cryptographic systems, consult PKCS#1 v2.2 for current RSA signature standards.
For compliance, this isn't a reportable incident, but note it in your next cryptographic review. Ensure all RSA signature implementations use proper formatting, and plan to phase out 1024-bit keys if you haven't already.
