Skip to content

Weak cryptography keys↑

Cryptographic keys are fundamental to securing digital communications, ensuring data confidentiality, integrity, and authentication. However, weaknesses in key generation, key management, or their implementations can lead to vulnerabilities that compromise the security of entire systems. In this discussion, we examine critical risks posed by weak cryptographic keys, including:

  • Weak RSA keys
  • ECDSA vulnerabilities
  • Small subgroup attacks
  • Precomputed attacks on common Diffie-Hellman primes
  • Predictable pseudorandom number generator (PRNG) issues in key generation
  • Side-channel attacks leading to key leakage

Business risk↑

Weak cryptographic keys pose significant business risks, including:

  • Data breaches - Attackers can decrypt sensitive information, leading to intellectual property theft or exposure of personal data.
  • Unauthorized system access - Compromised keys enable adversaries to impersonate legitimate users or systems, facilitating unauthorized transactions or data manipulation.
  • Compliance violations - The use of weak keys can result in non-compliance with regulatory standards such as NIST SP 800-57, ISO/IEC 19790, and FIPS 140-3.

What breaks?↑

Data confidentiality is at risk when weak keys are used in encryption algorithms, making it easier for attackers to decrypt ciphertext and access plaintext data. Data integrity can also be compromised, as weak keys used in digital signatures or message authentication codes (MACs) may allow attackers to forge valid signatures or MACs, leading to undetected data alterations. Furthermore, authentication mechanisms that rely on weak keys (e.g., in digital certificates or key exchange protocols) may fail, allowing unauthorized entities to impersonate legitimate users or systems, or to forge digital signatures on transactions.

Consequences↑

The consequences of weak cryptographic keys can be severe and far-reaching, including:

  • Intellectual property theft, exposing proprietary information and diminishing competitive advantage.
  • Financial losses, in direct monetary costs, legal liabilities, and incident response expenses.
  • Reputational damage, which can have long-term effects on organizations, such as reducing customer trust and harming brand value.

Cryptographic context↑

This section examines various vulnerabilities and risks posed by weak cryptographic keys and provides guidance on mitigation strategies to help strengthen your cryptographic systems to protect against these threats.

Weak RSA keys↑

Small RSA keys↑

RSA security relies on the difficulty of factoring large numbers. 512-bit RSA keys are trivially breakable, and 1024-bit keys are considered weak as they may be within the reach of state-level attackers. The FREAK attack (CVE-2015-0204) demonstrated how some RSA implementations could be downgraded to 512-bit keys, allowing attackers to break encryption. Advances in factoring algorithms and increasing computational power continue to weaken smaller RSA key sizes, making them unsuitable for secure applications.

To mitigate these risks, RSA keys must be at least 2048 bits, with 3072 bits or higher recommended for long-term security. Refer to Cryptographic keylengths and RSA algorithm for more information.

ROCA vulnerability↑

The ROCA vulnerability (CVE-2017-15361) exposed a critical flaw in Infineon’s cryptographic library, affecting RSA key generation in smart cards, TPMs, and hardware security modules. The issue stemmed from a deterministic key generation process that produced RSA keys susceptible to efficient factoring attacks. This affected keys up to 4096 bits, demonstrating that even large key sizes provide no security if the key generation process is flawed. The vulnerability impacted widely used security tokens, enterprise hardware, and governmental authentication systems.

To mitigate ROCA, affected devices required firmware updates or complete key replacement, as all generated RSA keys were permanently compromised. This attack highlights the necessity of cryptographically strong PRNGs and proper key generation techniques, even in hardware implementations.

Small public exponent↑

A small public exponent, such as e = 3, does not inherently weaken an RSA key. However, e is a key generation parameter that can introduce vulnerabilities in certain implementations. For example, when PKCS#1 v1.5 padding checks are incomplete, an attacker can exploit e = 3 to forge RSA signatures without knowing the private key.

To minimize the risk of signature forgery attacks, it is recommended to use a public exponent of e = 65537, which strikes a balance between efficiency and security. This helps to ensure the integrity of digital signatures, even if the implementation has incomplete padding validation.

Recommendations↑

  • Key size - Use at least a 2048-bit modulus for general security; 3072 bits or higher is recommended for long-term protection.
  • Public exponent - Avoid small public exponents such as e = 3; instead, use e = 65537 to reduce the risk of signature forgery attacks.
  • Key management - Don’t use static or hardcoded RSA keys in software or firmware, as this increases the risk of key compromise.
  • Padding validation - Ensure proper padding validation for RSA signatures, especially when using PKCS#1 v1.5; consider using RSA-PSS instead.
  • Key generation - Avoid key generation implementations with deterministic prime selection flaws, such as Infineon’s ROCA vulnerability (CVE-2017-15361), which made RSA keys factorable despite large key sizes.
  • Library usage - Use well-established libraries for generating and handling RSA keys, as these should address the issues and pitfalls mentioned above.

Weak ECC keys↑

Small ECC keys↑

The security of Elliptic Curve Cryptography (ECC) depends on the choice of the curve, as different curves offer varying levels of security. The key size in ECC is inherently determined by the curve parameters, where smaller curves correspond to shorter keys and provide lower security margins.

160-bit curves, such as secp160r1, have private keys of 160 bits and public keys that range from 161 to 320 bits depending on encoding (compressed or uncompressed). Such small curves are not considered secure, as they provide around 80 bits of security, falling below modern cryptographic standards. 224-bit curves1 are the minimum recommended by NIST, which correspond to 112 bits of security.
However, for long-term security, 256-bit curves or larger are preferred, as they provide at least 128-bit security.

Refer to Cryptographic keylengths and Elliptic-Curve Cryptography for more information.

Deprecated ECC curves↑

The curves K-233, B-233, K-283, B-283, K-409, B-409, K-571, and B-571 were deprecated in NIST SP 800-186 (February 2023, Table 2). Although these curves remain mathematically sound, they have seen limited adoption due to implementation challenges and performance limitations. Their arithmetic differs from prime field curves (such as P-256), necessitating specialized optimizations that increase implementation complexity and introduce potential security risks. Additionally, modern hardware and cryptographic libraries predominantly optimize for prime field curves, further diminishing the adoption of binary field alternatives.

ECDSA signature generation and ‘k‘↑

While not directly related to weak keys, ECDSA relies on a per-signature random value k; if k is reused, predictable, or generated with a biased RNG, it can compromise the private key, as demonstrated by the PlayStation 3 (PS3) compromise (CVE-2008-5161).

Recommendations↑

  • Preferred curves - Use ECC curves with at least a 256-bit field size such as P-256 to achieve 128-bit security.
  • Avoid deprecated curves - Don’t use deprecated curves, such as K-233, B-233, K-283, B-283, K-409, B-409, K-571, and B-571, as they have been deprecated in NIST SP 800-186.
  • Legacy use - If the use of deprecated curves is unavoidable—such as for signature verification—ensure that cryptographic libraries are up-to-date and adequately maintained to mitigate potential security risks.

Note that while 224-bit curves such as P-224 provide 112-bit security, they offer a reduced security margin and are generally not recommended for long-term use.

Weak Diffie-Hellman (DH) keys↑

Small DH keys↑

The security of Finite-Field Diffie-Hellman (DH) key exchange protocol relies heavily on the size of the prime modulus p used in the key agreement process. To ensure strong security, it’s essential to use sufficiently large moduli, which means having large enough key sizes.

Finite-field DH keys smaller than 2048 bits are no longer considered secure due to advances in discrete logarithm attacks. 512-bit DH keys were demonstrated to be breakable in real-time with the Logjam attack (CVE-2015-4000), and 1024-bit DH keys are now within reach of well-resourced adversaries. To ensure strong security, 2048-bit DH keys should be the absolute minimum, with 3072-bit keys recommended for long-term security. Refer to Cryptographic keylengths for more information.

Secure group parameters↑

In addition to using sufficiently large key sizes, it is crucial to carefully choose and validate the group parameters used in the DH key exchange. Weak or improperly validated group parameters can allow attackers to recover partial private key information through repeated key exchanges. For example, CVE-2016-0701 exposed how improper DH parameter validation in OpenSSL enabled small subgroup attacks, weakening the security of established session keys.

Use of common DH groups↑

Diffie-Hellman key exchange often relies on predefined prime groups, such as those from RFC 3526, to simplify implementation. However, if widely used DH primes are reused across multiple systems, it can compromise security.

  • Precomputed discrete logarithm attacks - Attackers can precompute solutions to the discrete logarithm problem for a known DH prime. This significantly reduces the security of key exchanges relying on static DH parameters with that prime.
  • Logjam attack - The Logjam attack demonstrated that precomputing discrete logarithms for common DH groups (particularly 512-bit and 1024-bit) enables passive decryption of TLS connections.
  • Weak standardized groups - Certain standardized groups, such as Oakley Group 1 (768-bit) and Group 2 (1024-bit) from RFC 2409, are unsafe and should not be used, as any well-known DH group smaller than 2048 bits is vulnerable to precomputed attacks.

Recommendations↑

  • Minimum key size - Use at least 2048-bit DH keys, as 512-bit and 1024-bit keys are breakable due to precomputed discrete logarithm attacks such as Logjam CVE-2015-4000.
  • Avoid common DH groups - Avoid using common, predefined DH groups smaller than 2048 bits, including Oakley Group 1 (768-bit) and Group 2 (1024-bit), as they are vulnerable to precomputed attacks.
  • Long-term security - For long-term security, use 3072-bit DH keys or higher, following NIST SP 800-57 recommendations.

Weak DSA keys↑

The Digital Signature Algorithm (DSA) is no longer approved by NIST for signature generation.

Note

DSA is no longer specified in FIPS 186-5 (February 2023) and is no longer approved for use. Its previous specification, FIPS 186-4, was withdrawn in February 2024. NIST SP 800-131A Rev 2 does currently allow for DSA signature generation using DSA-2048 or DSA-3072, but in NIST SP 800-131A Rev 3 it is expected that this will be disallowed entirely.

Small DSA Keys↑

Like RSA, the security of the DSA depends on key size. 1024-bit DSA keys, once considered secure, are becoming susceptible to practical discrete logarithm attacks, making them unsafe.

Structural weaknesses↑

The security of a DSA signature depends not only on the modulus size but also on the size of the subgroup q and the randomness of the nonce k.

  • Small subgroups - DSA operates in a group of prime order p, but signatures are computed in a smaller subgroup of order q. If q is too small, the security of DSA is significantly reduced. Previous, withdrawn versions of FIPS 186 recommended a 224-bit q for 2048-bit DSA keys.
  • Weak or reused nonces - Each DSA signature requires a unique, unpredictable nonce k. If the same k is used twice, the private key can be fully recovered. Such attacks have been demonstrated in practical settings where poor random number generation compromised DSA signatures.

Recommendations↑

Whenever possible, use EdDSA (e.g., Ed25519) or ECDSA instead of DSA, as they provide better security and efficiency.

If DSA must be used, choose a minimum of 2048-bit keys with a 224-bit or 256-bit q, though 3072-bit keys are strongly preferred. For more details on key length recommendations for EdDSA or ECDSA, refer to Cryptographic keylengths and Elliptic-Curve Cryptography.

Predictable PRNG issues in key generation↑

Weak cryptographic keys can result from predictable or low-entropy pseudo-random number generators (PRNGs) used during key generation. If a PRNG lacks sufficient entropy or follows a deterministic pattern, attackers may predict or reconstruct private keys, compromising the entire cryptographic system. This issue is classified under CWE-338 (Use of Cryptographically Weak PRNG) and CWE-332 (Insufficient Entropy in PRNG).

Real-world examples of predictable PRNG failures↑

Several notable vulnerabilities have been caused by predictable PRNG failures, including:

  • CVE-2008-0166 (Debian OpenSSL PRNG Vulnerability) – A critical flaw in Debian’s OpenSSL package caused the PRNG to generate weak cryptographic keys due to an accidental removal of entropy-gathering code. This resulted in millions of weak and easily guessable SSH and TLS keys.
  • CVE-2017-15361 (ROCA Vulnerability) – A flaw in Infineon’s RSA key generation algorithm produced factorable RSA keys, allowing attackers to efficiently compute private keys. Although not a direct PRNG failure, this vulnerability demonstrated the risks of deterministic key generation.
  • Dual_EC_DRBG (CVE-2007-6755, CVE-2013-4670) – A compromised elliptic curve PRNG, suspected of containing a backdoor, allowed attackers with special knowledge to predict its output.
  • CVE-2023-32549 – A cryptographic system used a weak PRNG for key generation, leading to insecure key material.
  • CVE-2022-45782 – A cryptographically insecure PRNG in dotCMS led to predictable password-reset tokens, increasing the risk of account takeover.
  • CVE-2021-0131 – Intel Security Library before version 3.3 used a weak PRNG in an API, exposing cryptographic material to potential attackers.

Mitigation and secure recommendations↑

  • Use a cryptographically secure PRNG (CSPRNG) - Recommendations by NIST SP 800-90A include Hash_DRBG and HMAC_DRBG (using SHA-2 or SHA-3 using 128-bit parameters or above), or CTR_DRBG (only using AES).
  • Avoid weak PRNGs - Steer clear of PRNGs with known weaknesses, such as Dual_EC_DRBG (CVE-2007-6755, CVE-2013-4670).
  • Ensure proper entropy collection - During key generation, following best practices from NIST SP 800-90B, to prevent issues like CVE-2008-0166.
  • Regularly update cryptographic libraries - Keep your libraries up to date to patch PRNG vulnerabilities and prevent weak key generation, as seen in CVE-2023-32549 and CVE-2021-0131.

Key validation↑

Key validation ensures that cryptographic keys are correctly structured, adhere to security standards, and resist known attacks. Proper validation reduces risks such as private key exposure, signature forgery, weak key exchanges, and authentication bypass vulnerabilities. Validation requirements follow NIST, FIPS, ISO/IEC, and other cryptographic standards to ensure compliance and security.

RSA key validation issues↑

RSA key validation ensures that key parameters conform to cryptographic standards such as NIST SP 800-57, FIPS 186-5, and ISO/IEC 18033-2. This includes verifying that key components are correctly structured, of sufficient size, and resistant to known cryptographic attacks. Proper validation prevents the use of weak or improperly generated RSA keys, reducing risks such as factorization vulnerabilities, weak exponents, and private key compromise.

ECC key validation issues↑

ECC key validation ensures that public keys and parameters conform to modern security standards such as NIST SP 800-186, FIPS 186-5, and ISO/IEC 15946-5. This includes verifying that keys are valid points on the expected curve, of appropriate strength, and resistant to attacks that exploit invalid curve choices or subgroup vulnerabilities. Proper validation protects against private key leakage and unauthorized access.

  • CVE-2015-7511 – Invalid curve attack against Libgcrypt, allowing private key extraction in ECDH.
  • CWE-754 – Improper curve parameter validation, leading to cryptographic attacks.

Diffie-Hellman (DH) key validation issues↑

DH key validation ensures that key exchange parameters follow NIST SP 800-56A, FIPS 186-5, and ISO/IEC 18033-2 standards. This includes verifying that public key inputs are correctly formed, belong to the correct group, and are resistant to known attacks such as small subgroup attacks and precomputed discrete logarithm attacks. Proper validation helps maintain key secrecy and secure key agreement.

  • CVE-2016-1000346 – Bouncy Castle DH public key validation failure, allowing attackers to force key reuse and partial key exposure.
  • CVE-2015-4000 – Logjam attack exploiting weak DH groups to break encryption.

DSA key validation issues↑

DSA key validation ensures that parameters such as p, q, and the signing nonce follow NIST SP 800-57 and FIPS 186-5 guidelines. This includes verifying that keys are correctly structured, nonces are randomly generated, and q is appropriately sized to maintain security. Proper validation helps prevent private key leakage and signature forgery.

  • CVE-2016-1000343 – Weak q parameter selection in Bouncy Castle DSA, leading to weaker cryptographic strength.
  • CVE-2016-0695 – Oracle Java DSA vulnerability due to biased or reused nonces, enabling private key recovery.

Recent example of key validation failure↑

CVE-2025-26465 (OpenSSH Key Validation Flaw) is a vulnerability in OpenSSH which causes improper key validation during session establishment, allowing an attacker to bypass authentication mechanisms. This highlights how weak or absent key validation can lead to man-in-the-middle (MITM) attacks and unauthorized access.

Mitigation and recommendations↑

Follow these best practices to mitigate attacks that exploit weak or improperly structured cryptographic keys.

  • Ensure key parameters conform to NIST, FIPS, and ISO/IEC standards to prevent weak or improperly structured keys.
  • Enforce validation of RSA, ECC, DH, and DSA key components to prevent attacks that exploit misconfigured or unchecked values.
  • Use only well-reviewed cryptographic libraries that enforce strict key validation rules, such as OpenSSL, BoringSSL, or libsodium.
  • Regularly patch cryptographic implementations to prevent validation-related vulnerabilities like CVE-2025-26465, which demonstrated how improper key validation in OpenSSH enabled authentication bypass.

Sources↑

  1. It should be noted that when NIST SP 800-131A Revision 3 is published (as of writing it is in the Initial Public Draft stage) that the use of 112-bit security strength for the classical digital signature and key-establishment mechanisms will be deprecated after December 31, 2030. ↩