@@ -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 Mang ers attack,
e.g. [CVE-2012-5081].
Manger describes an chosen ciphertext attack against RSA in [M01]. Th ere 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.
* 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 .
**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 . Mang er, "A c hosen 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 . Bleichenbach er, "C hosen ciphertext attacks against protocols based on
the RSA encryption standard PKCS# 1" Crypto 98
[KPR03 ]: V . Klima, O. Pokorny, and T. Rosa, "A ttacking RSA-based Sessions in SSL/TLS"
https://eprint.iacr.org/2003/052/
\[M01 ]: J . Manger, "A chosen ciphertext a ttack 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.
[BFKLSST12]: "Efficient padding oracle attacks on cryptographic hardware"
R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, Crypto 2012
\[KPR03]: V. Klima, O. Pokorny, and T. Rosa, "Attacking RSA-based Sessions in
SSL/TLS" https://eprint.iacr.org/2003/052/
[NIST SP 800-57]: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
\[BFKLSST12]: "Efficient padding oracle attacks on cryptographic hardware" R.
Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, Crypto 2012
[Enisa]: "Algorithms, key size and parameters report –
\[NIST SP 800-57]:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
\[Enisa]: "Algorithms, key size and parameters report –
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
Thai Duong