RSA#

RSA is a public-key cryptosystem whose security relies on the factorization problem.

Summary of ANSSI rules and recommendations#

Rule/recommendation

Comments

RegleFactorisation

  • Before 2031: modulus \(\ge 2048\) bits long.

  • From 2031: modulus \(\ge 3072\) bits long.

  • size(secret exponents) = size(modulus).

  • For encryption, public exponents $> 65536.

RecommandationFactorisation

  • Modulus \(\ge 3072\) bits long.

  • Public exponents \(> 65536\).

  • size(\(p\)) = size(\(q\)), and must be chosen uniformly at random.

RecommandationChiffAsym

RecommandationSignAsym

  • Compliant: RSA-SSA-PSS as defined in PKCS#1 v2.1 is compliant as long as RegleFactorisation is followed.

  • Not compliant: RSASSA as defined in PKCS#1 v1.5 is not compliant when the public exponent \(e\) is small, and for a poor choice of implementation of the signature verification linked to the padding (see Ble06).

Signature schemes#

RFC 8017 defines two signature schemes: RSASSA-PSS and RSASSA-PKCS1-v1_5. It states that “Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is REQUIRED in new applications. RSASSA-PKCS1-v1_5 is included only for compatibility with existing applications”. SSA stands for Signature Scheme with Appendix.

Since the signatures are computed on the output of hash functions, there is virtually no limit to the size of the message to sign depending on the underlying hash function.

In both schemes:

  • The signature generation function takes as input the private key and the message to sign. It returns the resulting signature.

  • The signature verification function takes as input the public key, the signed message, and the signature. It returns either “valid signature” or “invalid signature”.

  • The choice of a hash function parametrizes the operations.

RSASSA-PSS#

RSASSA-PSS gets its name from the EMSA-PSS encoding method, which is based on Bellare’s and Rogaway’s Probabilistic Signature Scheme. As the name indicates, there is a probabilistic component: a randomly generated salt is used. As RSAES-OAEP, it is also parametrized by the choice of a hash function to use with the mask generating function and the choice of a salt length.

When verifying a signature, the operation extracts both the salt and the hash output of the encoded message. These must be consistent with the given message for the signature to be considered valid.

RSASSA-PKCS1-v1_5#

RSASSA-PKCS1-v1_5 uses a deterministic encoding operation, unlike RSASSA-PSS. This means that for verifying signatures, the operation applies the encoding operation to the given message, and compares this with the encoded message recovered from the signature. The signature is considered valid if they are equal.

Encryption schemes#

Plain RSA encryption should not be used, as there are a number of attacks against it. Instead, RFC 8017#7 defines two encryption schemes: the modern and recommended RSAES-OAEP and the deprecated RSAES-PKCS1-v1_5.

RSAES-OAEP#

RSAES-OAEP uses Bellare’s and Rogaway’s Optimal Asymmetric Encryption Padding.

According to RFC 8017 “RSAES-OAEP is parameterized by the choice of hash function and mask generation function”. The mask generation function commonly used is called MGF1, which is itself parametrized by the choice of a hash function and the length of the salt used.

The encryption function takes as input the public key \((n,e)\), the message to encrypt, and an optional label, which is an empty string by default. The message must be at most \(k-2hLen-2\) bytes long, where \(k\) is the size of the modulus \(n\) and \(hLen\) is the length of the output of the underlying hash function. It returns the resulting ciphertext.

The decryption function takes as input the secret key, the ciphertext to decrypt, and the optional label. It returns the resulting plaintext.

RSAES-PKCS1-v1_5#

RSAES-PKCS1-v1_5 uses the encoding method defined in version 1.5 of PKCS#1. RFC 8017 states that “the use of this scheme for encrypting an arbitrary message, as opposed to a randomly generated key, is NOT RECOMMENDED”.

Considering the numerous attacks to which an implementation of this scheme may be vulnerable, such as Bleichenbacher’s, an attack on a low-exponent RSA, and more, the use of this scheme is not recommended.

The encryption function takes as input the public key \((n, e)\) and the message to encrypt, whose length must be less than \(k - 1\), where \(k\) is the size of the modulus \(n\). It returns the resulting ciphertext.

The decryption function takes as input the private key and the ciphertext to decrypt, whose length is at most \(k\). It returns the resulting plaintext.

ANSSI rules and recommendations#

Factorisation#

RègleFactorisation

  1. The minimum size of the modulus is 2048 bits, for use no later than the end of 2023.

  2. For use beyond 2031, the minimum size of the modulus is 3072 bits.

  3. The secret exponents must be the same size as the modulus.

  4. For encryption, the public exponents must be greater than \(2^{16} = 65536\).

RecommandationFactorisation

  1. It is recommended to use modulus of at least 3072 bits, even for use no later than 2030.

  2. It is recommended, for all applications, the use of public exponents greater than \(2^{16} = 65536\).

  3. It is recommended that the two prime numbers \(p\) and \(q\) that make up the modulus are of the same size and are chosen uniformly at random.

Asymmetric encryption#

RecommandationChiffAsym

  1. It is recommended to use provably secure asymmetric encryption mechanisms.

RecommandationSignAsym

  1. It is recommended to use provably secure asymmetric signature schemes.

RegleGestAsym

  1. The same asymmetric key pair may not be used for more than one purpose.

  2. Hierarchically important keys, such as root keys, must be generated and used by compliant mechanisms.