The conventional wisdom
Ask any security team how to protect against cryptographic vulnerabilities, and you'll hear the same advice: implement regular key rotation schedules, use longer key lengths, and deploy hardware security modules. The assumption is that managing the key lifecycle will prevent cryptographic failures.
This approach is embedded in every compliance framework. ISO/IEC 27001 Annex A.8.24 addresses cryptographic key management. NIST SP 800-57 provides detailed guidance on key rotation periods. Your auditors check whether you've documented rotation schedules and whether you're enforcing them.
The problem? None of this matters if your keys are fundamentally broken from the moment they're generated.
Why we disagree
The badkeys project recently uncovered RSA keys in the wild containing patterns of regularly spaced blocks of zeros interleaved with seemingly random data. These weren't keys that degraded over time. They were defective at creation.
The vulnerable keys appeared in Certificate Transparency logs for certificates issued to Yahoo and Verizon. They showed up on devices running NetApp software. They were found on SSH hosts running CompleteFTP software versions 10.0.0-12.0.0 (covering December 2016 through March 2019) and in DSA keys from versions 10.0.0-23.0.4 (December 2016 through December 2023).
Your key rotation schedule doesn't address this. You can rotate a fundamentally weak key every 90 days, and you'll just have four weak keys per year instead of one. The procedural control operates perfectly while providing zero security value.
The more concerning pattern: multiple independent cryptographic implementations failed in similar ways. This suggests either a common design flaw that different development teams independently reproduced, or something more deliberate. When different vendors produce cryptographic libraries with the same structural weakness, you're facing a supply chain integrity problem, not a key management problem.
The evidence
The badkeys project identified these vulnerabilities by analyzing massive datasets of real-world keys from Certificate Transparency logs, internet-wide TLS and SSH scans, and PGP key repositories. The researchers weren't looking for expired keys or keys that had been in use too long. They were searching for unexpectedly sparse RSA moduli, which revealed the zero-block patterns.
These keys are mathematically weak in ways that make them susceptible to factoring attacks. The regular spacing of zero blocks creates structure that attackers can exploit. If you know what to look for, these keys become significantly easier to break than properly generated RSA keys of the same length.
The fact that these keys appeared in certificates for large organizations tells you something important: enterprise procurement processes, vendor security questionnaires, and third-party risk assessments all failed to catch this. The organizations using these keys likely had mature security programs with documented key management procedures. Those procedures were irrelevant.
What to do instead
Start with key validation at generation time. Before you deploy any cryptographic key, test it for known weakness patterns. The badkeys project provides open-source tools specifically for this purpose. You're not just checking key length or algorithm; you're validating the mathematical properties of the key itself.
This means adding a validation step to your certificate issuance process, your SSH key deployment workflow, and anywhere else you generate or import cryptographic material. If you're using a Hardware Security Module, validate the keys it generates. If you're accepting certificates from third-party software, validate those too.
Second, inventory your deployed keys and test them retroactively. The CompleteFTP vulnerability affected keys generated over a seven-year period. If you deployed that software anytime between December 2016 and December 2023, you need to identify which keys it generated and replace them, regardless of when they were last rotated.
Build this into your vendor risk management program. When you're evaluating cryptographic libraries or products that generate keys, ask specific questions: How is entropy collected? What randomness testing is performed? Can you provide evidence that generated keys have been validated against known weakness patterns? Request access to source code for key generation functions if you're dealing with critical applications.
For your SOC 2 or ISO/IEC 27001 auditors, document your key validation process as part of your cryptographic controls. Don't just show rotation schedules; demonstrate that you're testing keys for mathematical weaknesses before deployment and that you have a process for identifying and replacing vulnerable keys when new weakness patterns are discovered.
Third, assume some of your keys are already compromised and architect accordingly. Perfect Forward Secrecy in TLS means that even if a server's private key is compromised, past session keys remain protected. This doesn't prevent all attacks, but it limits the damage from a weak key.
When the conventional wisdom is right
Key rotation remains important for limiting exposure windows and supporting crypto-agility. If you discover a weakness in your key generation process, you need the operational capability to replace keys quickly across your infrastructure. Regular rotation builds that muscle memory.
Rotation also matters for compliance with specific requirements. PCI DSS 4.0 requires cryptographic key management procedures including defined cryptoperiods. You can't simply skip rotation because you're validating keys at generation.
The conventional wisdom is also right about key length and algorithm selection. Using RSA-2048 or RSA-4096 instead of RSA-1024 makes these attacks harder, even if the key has structural weaknesses. Moving to elliptic curve cryptography eliminates this entire class of RSA-specific vulnerabilities.
Where the conventional wisdom fails is in treating key lifecycle management as sufficient protection. You need both procedural controls and mathematical validation. Your rotation schedule should work in concert with generation-time testing, not replace it.
The uncomfortable reality is that some cryptographic failures look deliberate. Regular patterns of zeros in RSA keys could result from flawed random number generation, or they could be engineered backdoors. Either way, your controls need to catch them before deployment, not just rotate them on schedule.
