132 lines
6.0 KiB
Markdown
132 lines
6.0 KiB
Markdown
# 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").
|
||
|
||
<!-- the SUN provider used to include that block type -->
|
||
|
||
**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
|