Skip to content

Latest commit

 

History

History
131 lines (100 loc) · 5.98 KB

rsa.md

File metadata and controls

131 lines (100 loc) · 5.98 KB
Raw

RSA

[TOC]

RSA key generation

Default size: If a library supports a key default size for RSA keys then this key size should be at least 2048 bits. This limit is based on the minimum recommendation of [NIST SP 800-57] part1 revision 4, Table 2, page 53. NIST recommends a minimal security strength of 112 bits for keys used until 2030. 112 bit security strength translates to a minimal key size of 2048 bits. Other organizations recommend somewhat different sizes: [Enisa], Section 3.6 also suggests that 2048-bit RSA keys provide a security strength of about 112 bits, but recommends a security strength of 128 bits for near term systems, hence 3072 bit RSA keys. [ECRYPT II], Section 13.3 suggests at least 2432 bits for new keys.

All the references above clearly state that keys smaller than 2048 bits should only be used in legacy cases. Therefore, it seems wrong to use a default key size smaller than 2048 bits. If a user really wants a small RSA key then such a choice should be made by explicitly providing the desired key length during the initalization of a key pair generator.

According to https://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html every implementation of the Java platform is required to implement RSA with both 1024 and 2048 bit key sizes. Hence a 2048 bit default should not lead to compatibility problems.

Cryptographically strong random numbers: So far the tests check that java.util.Random is not used. This needs to be extended.

Other bugs: The public exponent e should be larger than 1 [CVE-1999-1444]

RSA PKCS #1 v1.5 encryption

PKCS #1 v1.5 padding is susceptible to adaptive chosen ciphertext attacks and hence should be avoided [B98]. The difficulty of exploiting protocols using PKCS #1 v1.5 encryption often depends on the amount of information leaked after decrypting corrupt ciphertexts. Implementations frequently leak information about the decrypted plaintext in form of error messages. The content of the error messages are extremely helpful to potential attackers. Bardou et al. [BFKLSST12] analyze the difficult of attacks based on different types of information leakage. Smart even describes an attack that only needs about 40 chosen ciphertexts [S10], though in this case the encryption did not use PKCS #1 padding.

Bugs

  • Bouncycastle throws detailed exceptions: InvalidCipherTextException("unknown block type") or InvalidCipherTextException("block padding incorrect").

Tests To test whether an implementation leaks more information than necessary a test decrypts some random ciphertexts and catches the exceptions. If the exceptions are distinguishable then the test assumes that unnecessary information about the padding is leaked.

Due to the nature of unit tests not every attack can be detected this way. Some attacks require a large number of ciphertexts to be detected if random ciphertexts are used. For example Klima et al. [KPR03] describe an implementation flaw that could not be detected with our test.

Timing leakages because of differences in parsing the padding can leak information (e.g. CVE-2015-7827). Such differences are too small to be reliably detectable in unit tests.

RSA OAEP

Manger describes an chosen ciphertext attack against RSA in [M01]. There are implementations that were susceptible to Mangers attack, e.g. [CVE-2012-5081].

RSA PKCS1 signatures

Potential problems:

  • Some libraries parse PKCS#1 padding during signature verification incorrectly.
  • Some libraries determine the hash function from the signature (rather than encoding this in the key) Effect:
  • If the verification is buggy then an attacker might be able to generate signatures for keys with a small (i.e. e=3) public exponent.
  • If the hash algorithm is not determined by in an authentic manner then preimage attacks against weak hashes are possible, even if the hashes are not used by the signer.

Countermeasures: A good way to implement RSA signature verification is described in the standard PKCS#1 v.2.2 Section 8.2.2. This standard proposes to reconstruct the padding during verification and compare the padded hash to the value $$s^e \bmod n$$ obtained from applying a public key exponentiation to the signature s. Since this is a recurring bug it makes also a lot of sense to avoid small public exponents and prefer for example e=65537 .

List of broken implementations This is a large list.

References

[B98]: D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1" Crypto 98

[M01]: J. Manger, "A chosen ciphertext attack on RSA optimal asymmetric encryption padding (OAEP) as standardized in PKCS# 1 v2.0", Crypto 2001 This paper shows that OAEP is susceptible to a chosen ciphertext attack if error messages distinguish between different failure condidtions. [S10]: N. Smart, "Errors matter: Breaking RSA-based PIN encryption with thirty ciphertext validity queries" RSA conference, 2010 This paper shows that padding oracle attacks can be successful with even a small number of queries.

[KPR03]: V. Klima, O. Pokorny, and T. Rosa, "Attacking RSA-based Sessions in SSL/TLS" https://eprint.iacr.org/2003/052/

[BFKLSST12]: "Efficient padding oracle attacks on cryptographic hardware" R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, Crypto 2012

[NIST SP 800-57]: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

[Enisa]: "Algorithms, key size and parameters report – 2014" https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014

[ECRYPT II]: Yearly Report on Algorithms and Keysizes (2011-2012), http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf

[CVE-1999-1444]: Alibaba 2.0 generated RSA key pairs with an exponent 1

[CVE-2012-5081]: Java JSSE provider leaked information through exceptions and timing. Both the PKCS #1 padding and the OAEP padding were broken: http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf