diff --git a/doc/aesgcm.md b/doc/aesgcm.md index 1f4e19b..21bd5ae 100644 --- a/doc/aesgcm.md +++ b/doc/aesgcm.md @@ -1,12 +1,14 @@ # AES-GCM +[[AES-GCM]](bib.md#AES-GCM) + ## Nonce reuse One of the undesirable properties of AES-GCM is that reusing the same IV for the -same key leaks the authentication key. Typically, implementations can't enforce -that users don't repeat IVs unless they use restricted interfaces. However, -implementations should at least avoid features that increase the probability of -incorrect usages. +same key leaks the authentication key [[Joux-Gcm]](bib.md#Joux-Gcm). Typically, +implementations can't enforce that users don't repeat IVs unless they use +restricted interfaces. However, implementations should at least avoid features +that increase the probability of incorrect usages. One such dangerors featur in JCA is that the default behaviour of Cipher.doFinal is to reinitialize the cipher with the same parameters as the last encryption. @@ -39,8 +41,7 @@ them modulo $$2^{128}$$. E.g. if the counter value for a block is 0xffffffffffffffffffffffffffffffff ``` -then the counter for the next block in -AES-GCM is +then the counter for the next block in AES-GCM is ``` 0xffffffffffffffffffffffff00000000 @@ -132,14 +133,14 @@ tag : "5281efc7f13ac8e14ccf5dca7bfbfdd1", ``` ### Failing providers +The AES-GCM implementation in jdk9 handled CTR overflows incorrectly +[[CVE-2018-2972]](bib.md#CVE-2018-2972). -* CVE-2018-2972 The AES-GCM implementation in jdk9 handled CTR overflows - incorrectly. ## 0 size IV -AES-GCM allows IVs of bit length $$1 \ldots 2^{64}-1$$. (See [NIST SP 800 38d], -Section 5.2.1.1) +AES-GCM allows IVs of bit length $$1 \ldots 2^{64}-1$$. (See +[[NIST-SP800-38d]](bib.md#NIST-SP800-38d), Section 5.2.1.1) Disallowing IVs of length 0 is necessary. If an empty IV is used then the tag is an evaluation of a polynomial with the hash subkey as the value. Since the @@ -148,18 +149,3 @@ Therefore, any message encrypted with an empty IV leaks the hash subkey. In particular, encrypting an empty plaintext with an empty IV results in a ciphertext having a tag that is equal to the hash subkey used in AES-GCM. I.e. both are the same as encrypting an all zero block. - -## References - -[AES-GCM]: David A. McGrew and John Viega. "The Galois/Counter Mode of operation -(GCM)." http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf. - -[NIST SP 800 38d]: "Recommendation for block Cipher Modes of Operation: -Galois/Counter Mode (GCM) and GMAC", -http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf - -[Joux]: Joux, A. "Authentication failures in NIST version of GCM", -http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf. - -[Fer05]: Ferguson, N. "Authentication weaknesses in GCM", -https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/ferguson2.pdf diff --git a/doc/bib.md b/doc/bib.md new file mode 100644 index 0000000..bc43ac6 --- /dev/null +++ b/doc/bib.md @@ -0,0 +1,233 @@ +# References + + + + + + + +### AES-GCM {#AES-GCM} +D. A. McGrew and J. Viega, +"The Galois/Counter Mode of operation (GCM).", +http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf. + +### ABMSV03 {#ABMSV03} +A. Antipa, D. Brown, A. Menezes, R. Struik, S. Vanstone, +"Validation of Elliptic Curve Public Keys", +PKC 2003, +https://www.iacr.org/archive/pkc2003/25670211/25670211.pdf + +### AkiTak03 {#AkiTak03} +T. Akishita, T. Takagi, +"Zero-Value Point Attacks on Elliptic Curve Cryptosystem", +ISC 2003, pp. 218-233. +https://www-old.cdc.informatik.tu-darmstadt.de/reports/TR/TI-03-01.zvp.pdf + +### BeMeMu00 {#BeMeMu00} +I. Biehl, B. Meyer, V. Müller, +"Differential Fault Attacks on Elliptic Curve Cryptosystems", +Crypto '00, pp. 131-164 + +### FGHT16 {#FGHT16} +J. Fried, P. Gaudry, N. Heininger, E. Thome, +"A kilobit hidden SNFS discrete logarithm computation". +http://eprint.iacr.org/2016/961.pdf + +### Goubin03 {#Goubin03} +L. Goubin, +"A Refined Power-Analysis Attack on Elliptic Curve Cryptosystems", +PKC’03, pp. 199–210, +https://www.iacr.org/archive/pkc2003/25670199/25670199.pdf + +### Gordon92 {#Gordon92} +D. M. Gordon. +"Designing and detecting trapdoors for discrete log cryptosystems." +CRYPTO’92, pp. 66–75. + +### GPPT16 {#GPPT16} +D. Genkin, L. Pachmanov, I. Pipman, E. Tromer, +"ECDH Key-Extraction via Low-Bandwidth Electromagnetic Attacks on PCs", +http://cs.tau.ac.il/~tromer/papers/ecdh.pdf + +### LimLee98 {#LimLee98} +C.H. Lim and P.J. Lee, +"A key recovery attack on discrete log-based schemes using a prime order subgroup", +CRYPTO' 98, pp 249--263. + +### Joux-Gcm {#Joux-Gcm} +A. Joux, +"Authentication failures in NIST version of GCM", +http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf. + +### Ferguson05 {#Fergus05} +N. Ferguson, +"Authentication weaknesses in GCM", +https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/ferguson2.pdf + +### HowSma99 {#HowSma99} +N.A. Howgrave-Graham, N.P. Smart, +“Lattice Attacks on Digital Signature Schemes” +http://www.hpl.hp.com/techreports/1999/HPL-1999-90.pdf + +### Nguyen04 {#Nguyen04} +P. Nguyen, +“Can we trust cryptographic software? Cryptographic flaws in Gnu privacy guard 1.2.3”, +Eurocrypt 2004, +https://www.iacr.org/archive/eurocrypt2004/30270550/ProcEC04.pdf + +### Odlyzko90 {#Odlyzko90} +A. M. Odlyzko, +"The rise and fall of knapsack cryptosystems", +Cryptology and Computational Number Theory, pp.75-88, 1990 + +### OorWie96 {#OorWie96} +P. C. van Oorschot, M. J. Wiener, +"On Diffie-Hellman key agreement with short exponents", +Eurocrypt 96, pp 332--343. + +### WeakDh {#Weakdh} +D. Adrian et al. +"Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" +CCS '15 pp 5--17. +https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf + +A good analysis of various DH implementations. Some misconfigurations pointed +out in the paper are: p is composite, p-1 contains no large prime factor, q is +used instead of the generator g. + +### Eurocrypt92 panel {#Eucrocrypt92-panel} +"The Eurocrypt'92 Controversial Issue Trapdoor Primes and Moduli", +EUROCRYPT '92, LNCS 658, pp. 194-199. + +### Bleich98 {#Bleich98} +D. Bleichenbacher, +"Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1", +Crypto 98. + +### Manger01 {#Manger01} +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. + +### Smart10 {#Smart10} +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. + +### KlPoRo03 {#KlPoRo03} +V. Klima, O. Pokorny, and T. Rosa, +"Attacking RSA-based Sessions in SSL/TLS", +https://eprint.iacr.org/2003/052/ + +### BFKLSST12 {#BFKLSST12} +R. Bardou, R. Focardi, Y. Kawamoto, L. Simionato, G. Steel, J.K. Tsay, +"Efficient padding oracle attacks on cryptographic hardware" +Crypto 2012 + +### ECRYPT-II {ECRYPT-II}: +Yearly Report on Algorithms and Keysizes (2011-2012), +http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf + + +### NIST-SP800-38d {#NIST-SP800-38d} +"Recommendation for block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", +http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf + +### NIST-SP800-56A {#NIST-SP800-56A} +NIST SP 800-56A, revision 2, May 2013. +http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf + +### NIST-SP800-57 {#NIST-SP800-57} +http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf + + +### EnisaKeySize14 {#EnisaKeySize14} +Enisa, +"Algorithms, key size and parameters report – 2014" +https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014 + + +### FIPS-186-4 {#FIPS-186-4}{#NIST-DSS} +National Institute of Standards and Technology, +"Digital Signature Standard (DSS)", +July 2013. +http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf + +### PKCS-3 {#PKCS-3} +"PKCS #3, Diffie–Hellman Key Agreement". +http://uk.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-3-diffie-hellman-key-agreement-standar.htm + + +### CVE-1999-1444 {#CVE-199-1444} +Alibaba 2.0 generated RSA key pairs with an exponent 1 + +### CVE-2012-5081 {#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-2015-6924 {#CVE-2015-6924} +Utimaco HSMs vulnerable to invalid curve attacks. + +### CVE-2015-7940 {#CVE-2015-7940} +The Bouncy Castle Java library before 1.51 does not validate a point is on the +elliptic curve, allowing an "invalid curve attack". + +### CVE-2015-7827 {#CVE-2015-7827} + +### CVE-2016-9121 {#CVE-2016-9121} +go-jose before 1.0.4 suffers from an invalid curve attack for the ECDH-ES algorithm. + +### CVE-2017-7781 {#CVE-2017-7781} +Issue with elliptic curve addition in mixed Jacobian-affine +coordinates. Firefox and Java suffered from a bug where adding +a point to itself resulted in the point at infinity. + +### CVE-2017-16007 {#CVE-2017-16007} +node-jose earlier than version 0.9.3 is vulnerable to an +invalid curve attack. + +### CVE-2018-2972 {#CVE-2018-2972} +The AES-GCM implementation in jdk9 handled CTR overflows +incorrectly. + +### CVE-2018-5383 {#CVE-2018-5383} +Bluetooth implementations may not sufficiently validate +elliptic curve parameters during Diffie-Hellman key exchange +http://www.cs.technion.ac.il/~biham/BT/ + +### CVE-2019-6486 {#CVE-2019-6486} +golang/elliptic ECDH has an arithmetic error that allows to find private key +with an adaptive chosen message attack. + + + diff --git a/doc/dh.md b/doc/dh.md index ca8c410..7512ec8 100644 --- a/doc/dh.md +++ b/doc/dh.md @@ -2,43 +2,47 @@ ## Subgroup confinement attacks -The papers by van Oorshot and Wiener [OW96] rsp. Lim and Lee [LL98] show that -Diffie-Hellman keys can be found much faster if the short exponents are used and -if the multiplicative group modulo p contains small subgroups. In particular an -attacker can try to send a public key that is an element of a small subgroup. If -the receiver does not check for such elements then may be possible to find the -private key modulo the order of the small subgroup. Several countermeasures -against such attacks have been proposed: For example IKE uses fields of order p -where p is a safe prime (i.e. $$q=(p-1)/2),$$ hence the only elements of small -order are 1 and p-1. +The papers by van Oorshot and Wiener [[OorWie96]](bib.md#OorWie96) rsp. Lim and +Lee [[LimLee98]](bib.md#LimLee98) show that Diffie-Hellman keys can be found +much faster if the short exponents are used and if the multiplicative group +modulo p contains small subgroups. In particular an attacker can try to send a +public key that is an element of a small subgroup. If the receiver does not +check for such elements then may be possible to find the private key modulo the +order of the small subgroup. Several countermeasures against such attacks have +been proposed: For example IKE uses fields of order p where p is a safe prime +(i.e. $$q=(p-1)/2),$$ hence the only elements of small order are 1 and p-1. -[NIST SP 800-56A] rev. 2, Section 5.5.1.1 only requires that the size of the -subgroup generated by the generator g is big enough to prevent the baby-step -giant-step algorithm. I.e. for 80-bit security p must be at least 1024 bits long -and the prime q must be at least 160 bits long. A 2048 bit prime p and a 224 bit -prime q are sufficient for 112 bit security. To avoid subgroup confinment -attacks NIST requires that public keys are validated, i.e. by checking that a -public key y satisfies the conditions $$2 \leq y \leq p-2$$ and $$y^q \mod p = -1$$ (Section 5.6.2.3.1). Further, after generating the shared secret $$z = -y_a^{x_b} \mod p$$ each party should check that $$z \neq 1.$$ RFC 2785 contains -similar recommendations. The public key validation described by NIST requires -that the order q of the generator g is known to the verifier. Unfortunately, the -order q is missing in [PKCS #3]. [PKCS #3] describes the Diffie-Hellman -parameters only by the values p, g and optionally the key size in bits. +[[NIST-SP800-56A]](bib.md#NIST-SP800-56A) rev. 2, Section 5.5.1.1 only requires +that the size of the subgroup generated by the generator g is big enough to +prevent the baby-step giant-step algorithm. I.e. for 80-bit security p must be +at least 1024 bits long and the prime q must be at least 160 bits long. A 2048 +bit prime p and a 224 bit prime q are sufficient for 112 bit security. To avoid +subgroup confinment attacks NIST requires that public keys are validated, i.e. +by checking that a public key y satisfies the conditions $$2 \leq y \leq p-2$$ +and $$y^q \mod p = 1$$ (Section 5.6.2.3.1). Further, after generating the shared +secret $$z = y_a^{x_b} \mod p$$ each party should check that $$z \neq 1.$$ RFC +2785 contains similar recommendations. The public key validation described by +NIST requires that the order q of the generator g is known to the verifier. +Unfortunately, the order q is missing in [[PKCS #3]](bib.md#PKCS-3). +[[PKCS #3]](bib.md#PKCS-3) describes the Diffie-Hellman parameters only by the +values p, g and optionally the key size in bits. The class DHParameterSpec that defines the Diffie-Hellman parameters in JCE -contains the same values as [PKCS #3]. In particular, it does not contain the -order of the subgroup q. Moreover, the SUN provider uses the minimal sizes -specified by NIST for q. Essentially the provider reuses the parameters for DSA. +contains the same values as [[PKCS #3]](bib.md#PKCS-3). In particular, it does +not contain the order of the subgroup q. Moreover, the SUN provider uses the +minimal sizes specified by NIST for q. Essentially the provider reuses the +parameters for DSA. -Therefore, there is no guarantee that an implementation of Diffie-Hellman is secure against -subgroup confinement attacks. Without a key validation it is insecure to use the key-pair -generation from [NIST SP 800-56A] Section 5.6.1.1 (The key-pair generation there only requires that -static and ephemeral private keys are randomly chosen in the range \\(1..q-1)\\). +Therefore, there is no guarantee that an implementation of Diffie-Hellman is +secure against subgroup confinement attacks. Without a key validation it is +insecure to use the key-pair generation from +[[NIST-SP800-56A]](bib.md#NIST-SP800-56A) Section 5.6.1.1 (The key-pair +generation there only requires that static and ephemeral private keys are +randomly chosen in the range $$1..q-1)$$. -To avoid big disasters the tests below require that key sizes are not minimal. I.e., currently -the tests require at least 512 bit keys for 1024 bit fields. We use this lower limit because that -is what the SUN provider is currently doing. +To avoid big disasters the tests below require that key sizes are not minimal. +I.e., currently the tests require at least 512 bit keys for 1024 bit fields. We +use this lower limit because that is what the SUN provider is currently doing. TODO(bleichen): Find a reference supporting or disproving that decision. @@ -46,57 +50,24 @@ TODO(bleichen): Find a reference supporting or disproving that decision. The DH parameters must be carefully chosen to avoid security issues. A panel at Eurocrypt'92 discussed the possiblity of trapdoors in DL based primitives -[Eurocrypt92 panel]. A. Lenstra pointed out that the primes chould be chosen -such that the special number field sieve can be used to compute discrete -logarithms. Gordon has analyzed methods to generate and detect weak parameters -[G92]. Section 4 of Gordons paper describes a method that can detect some -special cases, but no general method was given. Recently Fried et al. showed -that 1024 bit discrete logarithms with the special number field sieve are -feasible [FGHT16]. Moreover some libraries use primes that are susceptible to -this attack [FGHT16]. +[[Eurocrypt92-panel]](bib.md#Ecurocrypt-panel). A. Lenstra pointed out that the +primes chould be chosen such that the special number field sieve can be used to +compute discrete logarithms. Gordon has analyzed methods to generate and detect +weak parameters [[Gordon92]](bib.md#Gordon92). Section 4 of Gordons paper +describes a method that can detect some special cases, but no general method was +given. Recently Fried et al. showed that 1024 bit discrete logarithms with the +special number field sieve are feasible [[FGHT16]](bib.md#FGHT16). Moreover some +libraries use primes that are susceptible to this attack +[[FGHT16]](bib.md#FGHT16). TODO(bleichen): So far not test for weak DH parameters has been implemented. -Possibly we should at least implement a test that detects special cases, so -that weak primes (such as the one used in libtomcrypt) are detected. +Possibly we should at least implement a test that detects special cases, so that +weak primes (such as the one used in libtomcrypt) are detected. -DH implementations are sometimes misconfigured. Adrian et al. [WeakDh] analyzed -various implementations and found for example the following problems in the -parameters: p is sometimes composite, p-1 contains no large prime factor, q is -used instead of the generator g. - -## References -[Eurocrypt92 panel]: "The Eurocrypt'92 Controversial Issue Trapdoor Primes and Moduli", -EUROCRYPT '92, LNCS 658, pp. 194-199. - -[G92]: D. M. Gordon. "Designing and detecting trapdoors for discrete log -cryptosystems." CRYPTO’92, pp. 66–75. - -\[FGHT16]: J. Fried, P. Gaudry, N. Heininger, E. Thome. "A kilobit hidden SNFS -discrete logarithm computation". http://eprint.iacr.org/2016/961.pdf - -[OW96]: P. C. van Oorschot, M. J. Wiener, "On Diffie-Hellman key agreement with short exponents", -Eurocrypt 96, pp 332–343. - -[LL98]: C.H. Lim and P.J. Lee, -"A key recovery attack on discrete log-based schemes using a prime order subgroup", -CRYPTO' 98, pp 249–263. - -[WeakDh]: D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, -J. A. Halderman, N. Heninger, D. Springall, E. Thomé, Luke Valenta, -B. VanderSloot, E. Wustrow, S. Zanella-Béguelink, P. Zimmermann, -"Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" -https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf - -[NIST SP 800-56A], revision 2, May 2013 -http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf - -[PKCS #3]: "Diffie–Hellman Key Agreement", -http://uk.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-3-diffie-hellman-key-agreement-standar.htm - -[RFC 2785]: R. Zuccherato, -"Methods for Avoiding 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", -March 2000 -https://www.ietf.org/rfc/rfc2785.txt +DH implementations are sometimes misconfigured. Adrian et al. The authors of +[[WeakDh]](bib.md#WeakDh) analyzed various implementations and found for example +the following problems in the parameters: p is sometimes composite, p-1 contains +no large prime factor, q is used instead of the generator g. @@ -61,19 +61,21 @@ 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. +ciphertexts are used. For example Klima et al. [[KlPoRo03]](bib.md#KlPoRo03) +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. +information (e.g. [[CVE-2015-7827]](bib.md#CVE-2015-1827)). 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 +[[Manger01]](bib.md#Manger01). There are implementations that were susceptible +to Mangers attack, e.g. [[CVE-2012-5081]](bib.md#CVE-2012-5081). ## RSA PKCS #1 v1.5 signatures + **Potential problems:** * Some libraries parse PKCS #1 v1.5 padding during signature verification @@ -95,16 +97,16 @@ small public exponents and prefer for example e=65537 . ## RSA PSS -RSA-PSS is an RSA based signature scheme using probabilistic padding. -The tests are based on [RFC 8017]. +RSA-PSS is an RSA based signature scheme using probabilistic padding. The tests +are based on RFC 8017. **Potential problems:** * The verification of an RSA-PSS signature contains a number of steps, where the correctness of the padding has to be verified. Skipping such checks can - lead to similar attacks as with RSA PKCS #1 v1.5 signatures. The necessary steps - of the verification are detailed in Section 9.1.2 of [RFC 8017]. Possibly, - this detailed description is preventing similar problems as with + lead to similar attacks as with RSA PKCS #1 v1.5 signatures. The necessary + steps of the verification are detailed in Section 9.1.2 of RFC 8017. + Possibly, this detailed description is preventing similar problems as with RSA PKCS #1 v1.5. **Compatibility and weak defaults:** @@ -112,7 +114,7 @@ The tests are based on [RFC 8017]. RSA PSS requires to specify a list of parameters. In particular this is a hash function for hashing the message, a mask generation function, which typically requires to specify a second hash function, salt length and a trailer field. -The ASN representation is specified in Appendix C of [RFC 8017]. +The ASN representation is specified in Appendix C of RFC 8017. 
    RSASSA-PSS-params ::= SEQUENCE {
        hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
@@ -121,7 +123,7 @@ The ASN representation is specified in Appendix C of [RFC 8017].
        trailerField       [3] TrailerField       DEFAULT trailerFieldBC
    }
-[RFC 4055] defines a number of identifiers for RSA-PSS in Section 6. The +RFC 4055 defines a number of identifiers for RSA-PSS in Section 6. The proposed identifiers use the same hash function for the message and the mask generation. The salt length is always 20. @@ -130,57 +132,15 @@ always require that all parameters are specified and hence some default values are chosen by the implementation, which of course affects compatibility. The tests in Wycheproof do not follow the defaults and parameter sets proposed -in [RFC 8017] or [RFC4055], rather the tests expect what appears to be common -behaviour in current implementations: the default mask generation algorithm -is MGF1 using the same hash as the hash algorithm used for hashing the message. -If the salt length is not specified then the salt length is equal to the -size of the hash function. +in RFC 8017 or RFC 4055, rather the tests expect what appears to be common +behaviour in current implementations: the default mask generation algorithm is +MGF1 using the same hash as the hash algorithm used for hashing the message. If +the salt length is not specified then the salt length is equal to the size of +the hash function. The ASN encoding of a key contains an algorithm identifier. The algorithm -identifier composed of either the OID rsaEncryption with a NULL parameter -or an OID id-RSASSA-PSS with a specification of the PSS parameters. -ASN encodings with an OID rsaEncryption is most commonly used in cryptographic -libraries. The second option will be an alternative supported by jdk11. -Because of this the test vectors in Wycheproof use the OID rsaEncryption. - -## 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 - -[RFC 4055]: Additional Algorithms and Identifiers for RSA Cryptography for use -in the Internet X.509 Public Key Infrastructure Certificate and Certificate -Revocation List (CRL) Profile - -[RFC 8017]: PKCS #1: RSA Cryptography Specifications Version 2.2 - -[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 +identifier composed of either the OID rsaEncryption with a NULL parameter or an +OID id-RSASSA-PSS with a specification of the PSS parameters. ASN encodings with +an OID rsaEncryption is most commonly used in cryptographic libraries. The +second option will be an alternative supported by jdk11. Because of this the +test vectors in Wycheproof use the OID rsaEncryption.