diff options
Diffstat (limited to 'doc/rsa.md')
-rw-r--r-- | doc/rsa.md | 105 |
1 files changed, 53 insertions, 52 deletions
@@ -22,8 +22,9 @@ 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. +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 @@ -53,78 +54,78 @@ padding. <!-- 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. +**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. +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. +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]. + +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 +* 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 . +* 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. +\[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/ +\[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 +\[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 +\[NIST SP 800-57]: +http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf -[Enisa]: "Algorithms, key size and parameters report – 2014" +\[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-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 +\[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 |