This vulnerability exposes encrypted data to attacks whose goal is to recover the plaintext.

## Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used
for several important reasons:

- Confidentiality, privacy, and intellectual property protection
- Security during transmission or on storage devices
- Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

- No encryption is unbreakable.
- The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In today’s cryptography, the length of the **key** directly affects the security level of cryptographic algorithms.

Note that depending on the algorithm, the term **key** refers to a different mathematical property. For example:

- For RSA, the key is the product of two large prime numbers, also called the
**modulus**.
- For AES and Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
- In some cases, AES keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key
Derivation Function 2)

If an application uses a key that is considered short and **insecure**, the encrypted data is exposed to attacks aimed at getting at
the plaintext.

In general, it is best practice to expect a breach: that a user or organization with malicious intent will perform cryptographic attacks on this
data after obtaining it by other means.

### What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that
encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

#### Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can
further exploit a system to obtain more information.

Encrypted values are often considered trustworthy because it would not be possible for a
third party to modify them under normal circumstances.

#### Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft,
financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and
stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

#### Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the
plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

## How to fix it in Botan

### Code examples

The following code examples either explicitly or implicitly generate keys. Note that there are differences in the size of the keys depending on the
algorithm.

Due to the mathematical properties of the algorithms, the security requirements for the key size vary depending on the algorithm.

For example,
a 256-bit ECC key provides about the same level of security as a 3072-bit RSA key and a 128-bit symmetric key.

#### Noncompliant code example

Here is an example of a private key generation with RSA:

#include <botan/pubkey.h>
#include <botan/rng.h>
#include <botan/rsa.h>
void encrypt() {
std::unique_ptr<Botan::RandomNumberGenerator> rng(new Botan::System_RNG);
Botan::RSA_PrivateKey rsaKey(*rng, 1024); // Noncompliant
}

Here is an example with the generation of a key as part of a Discrete Logarithmic (DL) group, a Digital Signature Algorithm (DSA) parameter:

#include <botan/dl_group.h>
void encrypt() {
Botan::DL_Group("dsa/botan/1024"); // Noncompliant
}

Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the algorithm
name:

#include <botan/ec_group.h>
void encrypt() {
Botan::EC_Group("secp160k1"); // Noncompliant
}

#### Compliant solution

#include <botan/pubkey.h>
#include <botan/rng.h>
#include <botan/rsa.h>
void encrypt() {
std::unique_ptr<Botan::RandomNumberGenerator> rng(new Botan::System_RNG);
Botan::RSA_PrivateKey rsaKey(*rng, 2048);
}

#include <botan/dl_group.h>
void encrypt() {
Botan::DL_Group("dsa/botan/2048");
}

#include <botan/ec_group.h>
void encrypt() {
Botan::EC_Group("secp224k1");
}

### How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The appropriate choices are the following.

#### RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of **2048** bits is recommended for both.

#### AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
all possible keys.

A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of **128 bits** is recommended for AES.

#### Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
algorithms are mentioned directly in their names. For example, `secp256k1`

generates a 256-bits long private key.

Currently, a minimum key size of **224 bits** is recommended for EC algorithms.

### Going the extra mile

#### Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.

It is important to keep
in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or
"post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

## How to fix it in CryptoPP

### Code examples

#### Noncompliant code example

Here is an example of a private key generation with RSA:

#include <cryptopp/rsa.h>
#include <cryptopp/rng.h>
void encrypt() {
CryptoPP::AutoSeededRandomPool rng;
CryptoPP::InvertibleRSAFunction rsa_trapdoor;
rsa_trapdoor.GenerateRandomWithKeySize(rng, 1024); // Noncompliant
}

Here is an example of a key generation with the Digital Signature Algorithm (DSA):

#include <cryptopp/dsa.h>
#include <cryptopp/rng.h>
cryptopp::autoseededrandompool rng;
cryptopp::dsa::privatekey dsa_private_key;
dsa_private_key.GenerateRandomWithKeySize(rng, 1024); // Noncompliant

Here is an example of a key generation with Diffie-Hellman:

#include <cryptopp/dh.h>
#include <cryptopp/rng.h>
cryptopp::autoseededrandompool rng;
CryptoPP::DH dh;
dh.AccessGroupParameters().GenerateRandomWithKeySize(rng, 1024); // Noncompliant

Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the algorithm
name:

#include <cryptopp/osrng.h>
void ecnrypt() {
CryptoPP::ASN1::secp112r1(); // Noncompliant
}

#### Compliant solution

#include <cryptopp/rsa.h>
#include <cryptopp/rng.h>
void encrypt() {
CryptoPP::AutoSeededRandomPool rng;
CryptoPP::InvertibleRSAFunction rsa_trapdoor;
rsa_trapdoor.GenerateRandomWithKeySize(rng, 2048);
}

#include <cryptopp/dsa.h>
#include <cryptopp/rng.h>
cryptopp::autoseededrandompool rng;
cryptopp::dsa::privatekey dsa_private_key;
dsa_private_key.GenerateRandomWithKeySize(rng, 2048);

#include <cryptopp/dh.h>
#include <cryptopp/rng.h>
cryptopp::autoseededrandompool rng;
CryptoPP::DH dh;
dh.AccessGroupParameters().GenerateRandomWithKeySize(rng, 2048);

#include <cryptopp/osrng.h>
void ecnrypt() {
CryptoPP::ASN1::secp256r1();
}

### How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The appropriate choices are the following.

#### RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of **2048** bits is recommended for both.

#### AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
all possible keys.

A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of **128 bits** is recommended for AES.

#### Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
algorithms are mentioned directly in their names. For example, `secp256k1`

generates a 256-bits long private key.

Currently, a minimum key size of **224 bits** is recommended for EC algorithms.

### Going the extra mile

#### Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.

It is important to keep
in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or
"post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

## How to fix it in OpenSSL

### Code examples

The following code examples either explicitly or implicitly generate keys. Note that there are differences in the size of the keys depending on the
algorithm.

Due to the mathematical properties of the algorithms, the security requirements for the key size vary depending on the algorithm.

For example,
a 256-bit ECC key provides about the same level of security as a 3072-bit RSA key and a 128-bit symmetric key.

#### Noncompliant code example

Here is an example of a private key generation with RSA:

#include <openssl/rsa.h>
void encrypt() {
RSA* rsa_key_pair = RSA_new();
BIGNUM* exponent = BSA_new();
BN_set_word(exponent, RSA_F4);
RSA_generate_key_ex(rsa_key_pair, 1024, exponent, NULL); // Noncompliant
}

Here is an example of a key generation with the Digital Signature Algorithm (DSA):

#include <openssl/dsa.h>
void encrypt() {
DSA* dsa_params = DSA_new();
DSA_generate_parameters_ex(dsa_params, 1024, NULL, 0, NULL, NULL, NULL); // Noncompliant
}

Here is an example of a key generation with Diffie-Hellman:

#include <openssl/dh.h>
void encrypt() {
DH* dh_params = DH_new();
DH_generate_parameters_ex(dh_params, 1024, DH_GENERATOR_2, NULL); // Noncompliant
}

Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the algorithm
name:

#include <botan/ec_group.h>
void encrypt() {
EC_KEY* ec_key = EC_KEY_new_by_curve_name(NID_secp112r1); // Noncompliant
}

#### Compliant solution

#include <openssl/rsa.h>
void encrypt() {
RSA* rsa_key_pair = RSA_new();
BIGNUM* exponent = BSA_new();
BN_set_word(exponent, RSA_F4);
RSA_generate_key_ex(rsa_key_pair, 2048, exponent, NULL);
}

#include <openssl/dsa.h>
void encrypt() {
DSA* dsa_params = DSA_new();
DSA_generate_parameters_ex(dsa_params, 2048, NULL, 0, NULL, NULL, NULL);
}

#include <openssl/dh.h>
void encrypt() {
DH* dh_params = DH_new();
DH_generate_parameters_ex(dh_params, 2048, DH_GENERATOR_2, NULL);
}

#include <botan/ec_group.h>
void encrypt() {
EC_KEY* ec_key = EC_KEY_new_by_curve_name(NID_secp224r1);
}

### How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The appropriate choices are the following.

#### RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of **2048** bits is recommended for both.

#### AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
all possible keys.

A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of **128 bits** is recommended for AES.

#### Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
algorithms are mentioned directly in their names. For example, `secp256k1`

generates a 256-bits long private key.

Currently, a minimum key size of **224 bits** is recommended for EC algorithms.

### Going the extra mile

#### Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.

It is important to keep
in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or
"post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

## Resources

### Articles & blog posts

### Standards