From c1cbf80387828fe142ba0270d0c2072acde8ece2 Mon Sep 17 00:00:00 2001 From: bleichen Date: Thu, 28 Nov 2019 04:04:48 -0800 Subject: [PATCH] Alternative format for md links. Maybe this one is more compatible with github. NOKEYCHECK=True PiperOrigin-RevId: 282920749 GitOrigin-RevId: 3b0342b7798be79eebdd9b8b11b65872674263a6 --- doc/aesgcm.md | 8 ++--- doc/bib.md | 91 ++++++++++++++++++++++++++----------------------- doc/dh.md | 26 +++++++------- doc/dsa.md | 17 ++++----- doc/ecdh.md | 22 ++++++------ doc/hkdf.md | 31 +++++++++++++++++ doc/key_wrap.md | 11 +++--- doc/rsa.md | 24 ++++++------- doc/types.md | 2 +- 9 files changed, 133 insertions(+), 99 deletions(-) create mode 100644 doc/hkdf.md diff --git a/doc/aesgcm.md b/doc/aesgcm.md index 21bd5ae..68bc5b0 100644 --- a/doc/aesgcm.md +++ b/doc/aesgcm.md @@ -1,11 +1,11 @@ # AES-GCM -[[AES-GCM]](bib.md#AES-GCM) +This encryption mode is described in [[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 [[Joux-Gcm]](bib.md#Joux-Gcm). Typically, +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. @@ -134,13 +134,13 @@ 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]](bib.md#cve-2018-2972). ## 0 size IV 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) +[[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 diff --git a/doc/bib.md b/doc/bib.md index 5b01c04..315a1f4 100644 --- a/doc/bib.md +++ b/doc/bib.md @@ -31,96 +31,101 @@ Additional information is added as a separate paragraph. -### AES-GCM {#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. -### AbVaLo19 {#AbVaLo19} +### AbVaLo19 R. Abarzúa, C. Valencia and J. López, "Survey for Performance & Security Problems of Passive Side-channel Attacks Countermeasures in ECC", https://eprint.iacr.org/2019/010.pdf -### ABMSV03 {#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} +### 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} +### BeMeMu00 I. Biehl, B. Meyer, V. Müller, "Differential Fault Attacks on Elliptic Curve Cryptosystems", Crypto '00, pp. 131-164 -### FGHT16 {#FGHT16} +### BelRog00 +Bellare, Rogaway, +"Encode-Then-Encipher Encryption: How to exploit nonces or redundancy in plaintexts for efficient cryptography", +Asiacrypt 2000, pp.317--330. + +### 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} +### 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} +### Gordon92 D. M. Gordon. "Designing and detecting trapdoors for discrete log cryptosystems." CRYPTO’92, pp. 66–75. -### GPPT16 {#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} +### 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} +### 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} +### Ferguson05 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} +### 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 -### Krawczyk10 {#Krawczyk10} +### Krawczyk10 H. Krawczyk, "Cryptographic extraction and key derivation: the HKDF scheme", https://eprint.iacr.org/2010/264.pdf -### Nguyen04 {#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} +### Odlyzko90 A. M. Odlyzko, "The rise and fall of knapsack cryptosystems", Cryptology and Computational Number Theory, pp.75-88, 1990 -### OorWie96 {#OorWie96} +### OorWie96 P. C. van Oorschot, M. J. Wiener, "On Diffie-Hellman key agreement with short exponents", Eurocrypt 96, pp 332--343. -### WeakDh {#Weakdh} +### WeakDh D. Adrian et al. "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" CCS '15 pp 5--17. @@ -130,16 +135,16 @@ 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} +### Eurocrypt92 panel "The Eurocrypt'92 Controversial Issue Trapdoor Primes and Moduli", EUROCRYPT '92, LNCS 658, pp. 194-199. -### Bleich98 {#Bleich98} +### Bleich98 D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1", Crypto 98. -### Manger01 {#Manger01} +### Manger01 J. Manger, "A chosen ciphertext attack on RSA optimal asymmetric encryption padding (OAEP) as standardized in PKCS# 1 v2.0", Crypto 2001. @@ -147,7 +152,7 @@ Crypto 2001. This paper shows that OAEP is susceptible to a chosen ciphertext attack if error messages distinguish between different failure condidtions. -### Smart10 {#Smart10} +### Smart10 N. Smart, "Errors matter: Breaking RSA-based PIN encryption with thirty ciphertext validity queries", RSA conference, 2010. @@ -155,95 +160,95 @@ RSA conference, 2010. This paper shows that padding oracle attacks can be successful with even a small number of queries. -### KlPoRo03 {#KlPoRo03} +### KlPoRo03 V. Klima, O. Pokorny, and T. Rosa, "Attacking RSA-based Sessions in SSL/TLS", https://eprint.iacr.org/2003/052/ -### BFKLSST12 {#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}: +### 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} +### 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-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} +### NIST-SP800-57 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf -### NIST SP800-131A Revision 2 {#NIST-SP800-131A} +### NIST SP800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf Some notable changes in revision 2: Keys with less than 112 bit security are now disallowed. EdDSA will be added with FIPS 186-5. TDES is disallowed after 2023. RSA PKCS 1 v.1.5 for encryption is disallowed after 2023. -### EnisaKeySize14 {#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} +### FIPS-186-4 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 "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} +### CVE-1999-1444 Alibaba 2.0 generated RSA key pairs with an exponent 1 -### CVE-2012-5081 {#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} +### CVE-2015-6924 Utimaco HSMs vulnerable to invalid curve attacks. -### CVE-2015-7940 {#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-2015-7827 -### CVE-2016-9121 {#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} +### 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} +### CVE-2017-16007 node-jose earlier than version 0.9.3 is vulnerable to an invalid curve attack. -### CVE-2018-2972 {#CVE-2018-2972} +### CVE-2018-2972 The AES-GCM implementation in jdk9 handled CTR overflows incorrectly. -### CVE-2018-5383 {#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} +### CVE-2019-6486 golang/elliptic ECDH has an arithmetic error that allows to find private keys with an adaptive chosen message attack. diff --git a/doc/dh.md b/doc/dh.md index 7512ec8..8132d68 100644 --- a/doc/dh.md +++ b/doc/dh.md @@ -2,8 +2,8 @@ ## Subgroup confinement attacks -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 +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 @@ -12,7 +12,7 @@ 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-SP800-56A]](bib.md#NIST-SP800-56A) rev. 2, Section 5.5.1.1 only requires +[[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 @@ -23,12 +23,12 @@ 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 +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]](bib.md#PKCS-3). In particular, it does +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. @@ -36,7 +36,7 @@ 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-SP800-56A]](bib.md#NIST-SP800-56A) Section 5.6.1.1 (The key-pair +[[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)$$. @@ -50,22 +50,22 @@ 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]](bib.md#Ecurocrypt-panel). A. Lenstra pointed out that the +[[Eurocrypt92-panel]](bib.md#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 [[Gordon92]](bib.md#Gordon92). Section 4 of Gordons paper +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 +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). +[[FGHT16]](bib.md#fght16). -TODO(bleichen): So far not test for weak DH parameters has been implemented. +TODO(bleichen): So far no 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. DH implementations are sometimes misconfigured. Adrian et al. The authors of -[[WeakDh]](bib.md#WeakDh) analyzed various implementations and found for example +[[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. diff --git a/doc/dsa.md b/doc/dsa.md index a6f71cb..7941c44 100644 --- a/doc/dsa.md +++ b/doc/dsa.md @@ -3,7 +3,7 @@ [TOC] The digital signature algorithm (DSA) is one of three signature schemes -descripted in the digital signature standard [[NIST-DSS]](bib.md#NIST-DSS). +descripted in the digital signature standard [[FIPS-186-4]](bib.md#fips-186-4). ## Key generation @@ -22,7 +22,7 @@ The tests expect the following properties of the parameters used during key generation: * If only the parameter L is specified by the caller then N should be one of - the options proposed in [[NIST-DSS]](bib.md#NIST-DSS). + the options proposed in [[FIPS-186-4]](bib.md#fips-186-4). * If no size is specified then L should be at least 2048. This is the minimal key size recommended by NIST for the period up to the year 2030. @@ -33,15 +33,16 @@ one-time secret k. This secret value should be close to uniformly distributed. If that is not the case then DSA signatures can leak the private key that was used to generate the signature. Two methods for generating the one-time secrets are described in FIPS PUB 186-4, Section B.5.1 or B.5.2 -[[FIPS-186-4]](bib.md#FIPS-186-4). There is also the possibility that the use of +[[FIPS-186-4]](bib.md#fips-186-4). There is also the possibility that the use of mismatched implementations for key generation and signature generation are leaking the private keys. ## Signature verification A DSA signature is a DER encoded tuple of two integers (r,s). To verify a -signature the verifier first checks $$0 < r < q$$ and $$0 < s < q$$. The -verifier then computes: +signature the verifier first checks $$0 < r < q$$ and $$0 < s < q$$. + +The verifier then computes: $$ \begin{array}{l} @@ -151,13 +152,13 @@ and used this assumption to generate a random 160-bit k when generating a signature instead of choosing it uniformly in the range (1,q-1). Hence, k severely biased. Attacks against DSA with biased k are well known. Howgrave-Graham and Smart analyzed such a situation -[[HowSma99]](bib.md#HowSma99). Their results show that about 4 signatrues leak +[[HowSma99]](bib.md#howsma99). Their results show that about 4 signatrues leak enough information to determine the private key in a few milliseconds. Nguyen -analyzed a similar flaw in GPG [[Nguyen04]](bib.md#Nguyen04). I.e., Section 3.2 +analyzed a similar flaw in GPG [[Nguyen04]](bib.md#nguyen04). I.e., Section 3.2 of Nguyens paper describes essentially the same attack as used here. More generally, attacks based on lattice reduction were developed to break a variety of cryptosystems such as the knapsack cryptosystem -[[Odlyzko90]](bib.md#Odlyzko90). +[[Odlyzko90]](bib.md#odlyzko90). ## Further notes diff --git a/doc/ecdh.md b/doc/ecdh.md index 3b0fcb6..47e6742 100644 --- a/doc/ecdh.md +++ b/doc/ecdh.md @@ -10,17 +10,17 @@ See https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman Some libraries do not check if the elliptic curve points received from another party are points on the curve. This can often be exploited to find private keys -[[BeMeMu00]](bib.md#BeMeMu00)), [[ABMSV03]](bib.md#ABMSV03). Encodings of public +[[BeMeMu00]](bib.md#bememu00)), [[ABMSV03]](bib.md#abmsv03). Encodings of public keys typically contain the curve for the public key point. If such an encoding is used in the key exchange then it is important to check that the public and secret key used to compute the shared ECDH secret are using the same curve. Failing to check for these problems is a frequent problem: -[[CVE-2015-6924]](bib.md#CVE-2015-6924), -[[CVE-2015-7940]](bib.md#CVE-2015-7940), -[[CVE-2016-9121]](bib.md#CVE-2016-9121), -[[CVE-2017-16007]](bib.md#CVE-2017-16007), -[[CVE-2018-5383]](bib.md#CVE-2018-5383). +[[CVE-2015-6924]](bib.md#cve-2015-6924), +[[CVE-2015-7940]](bib.md#cve-2015-7940), +[[CVE-2016-9121]](bib.md#cve-2016-9121), +[[CVE-2017-16007]](bib.md#cve-2017-16007), +[[CVE-2018-5383]](bib.md#cve-2018-5383). The test vectors check for the following problems: @@ -57,23 +57,23 @@ In a typical attack scenario the malicious party is able to choose the ephemeral key, and has means to detect if the computation of the other party triggers a special case. -One particular attack has been proposed in [[Goubin03]](bib.md#Goubin03). The +One particular attack has been proposed in [[Goubin03]](bib.md#goubin03). The author pointed out that points with a coordinate 0 keeps this property even if the projective or Jacobian coordinates are randomized. If a point multiplication that encounters such a point can be distinguished from other point multiplication (e.g. because the integer arithmetic is not constant time) then an attack is possible. The attack has been extended by Akishita and Takagi -[[AkiTak03]](bib.md#AkiTak03). The authors showed that other places in a point +[[AkiTak03]](bib.md#akitak03). The authors showed that other places in a point multiplication have similar properties and hence that additional attacks are possible. The golang library was susceptible to this attack, since doubling a point with x-coordinate 1 typically resulted in an virtually endless loop -[[CVE-2019-6486]](bib.md#CVE-2019-6486). A recent survey about timing and side -channel attaks is [[AbVaLo19]](bib.md#AbVaLo19)). +[[CVE-2019-6486]](bib.md#cve-2019-6486). A recent survey about timing and side +channel attaks is [[AbVaLo19]](bib.md#abvalo19)). ## Side channel attacks that are not detectable by Wycheproof Physical side channel attacks e.g. based on power analsis or electromagnetic -emanation have been demonstrated [[GPPT16]](bib.md#GPPT16). Testing for such +emanation have been demonstrated [[GPPT16]](bib.md#gppt16). Testing for such side channels is not possible in Wycheproof. ### Countermeasures diff --git a/doc/hkdf.md b/doc/hkdf.md new file mode 100644 index 0000000..3be4532 --- /dev/null +++ b/doc/hkdf.md @@ -0,0 +1,31 @@ +# HKDF + +[[HKDF]](bib.md#krawczyk10) is a key derivation function proposed by H. Krawczyk. +A format description of HKDF is in RFC 5869. + +## Collisions + +* Section 3.4 of RFC 5869 specifies that the salt value is not chosen by an + attacker. If this conditions is violated then the attacker may cause + unexpected repetitions of pseudorandom streams. Because of properties of the + underlying HMAC there are distinct salts that lead to the same pseudorandom + streams. One such equivalence happens because salts of small size are simply + padded with 0's, so that the result has the same size as the block size of the + message digest. + + TODO: add example + + Another equivalence of salts happens because salts, longer than the block size + of the message digest are hashed, hence a long salt and its hash value lead to + equivalent pseudorandom streams. + + TODO: add example + +## Maximal output size + +* there is a maxmal output size for HKDF. Generating longer streams can lead to + collisions. RFC 5869 mentions the limit, without explanation and also defines + HKDF so that it could be used for longer outputs. + + TODO: add example + diff --git a/doc/key_wrap.md b/doc/key_wrap.md index fe4877d..897d977 100644 --- a/doc/key_wrap.md +++ b/doc/key_wrap.md @@ -8,8 +8,8 @@ strong pseudorandom permutation. KW and KWP use AES, TKW uses DES. The input size of KW and TKW are limited to a multiple of 8 (rsp 4) bytes, KWP adds a padding so that arbitrary length inputs can be processed. -KW is also defined by [RFC 3394](https://tools.ietf.org/html/rfc3394). KWP is -also defined by [RFC 5649](https://tools.ietf.org/html/rfc5649). TKW is a key +KW is also defined by [[RFC 3394]](https://tools.ietf.org/html/rfc3394). KWP is +also defined by [[RFC 5649]](https://tools.ietf.org/html/rfc5649). TKW is a key wrap primitive that uses TripleDES instead of AES. All the key wrap primitives use an underlying permutation (called W by NIST), @@ -56,7 +56,8 @@ padding oracles are present. So one question is whether this is the case here too. An analysis of cryptographic primitives based on strong pseudorandom -permutations is [BR00]. Theorem 2 implies that checking redundancy in the +permutations is [[BelRog00]](bib.md#belrog00). +Theorem 2 implies that checking redundancy in the plaintext gives an integrity check is correct, i.e. any constant part in the plaintext is useful as integrity check. @@ -166,8 +167,4 @@ overflow. Implementations are expected to implement this correctly or reject longer inputs. Currently the tests do not fail when a padding oracle is present, since such oracles are likely harmless. -## Reference list -[BR00]: Bellare, Rogaway, "Encode-Then-Encipher Encryption: How to exploit -nonces or redundancy in plaintexts for efficient cryptography", Asiacrypt 2000, -pp.317--330. diff --git a/doc/rsa.md b/doc/rsa.md index 11ea8c8..a6f5244 100644 --- a/doc/rsa.md +++ b/doc/rsa.md @@ -6,14 +6,14 @@ **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-SP800-57]](bib.md#NIST-SP800-57) part1 revision 4, +recommendation of [[NIST-SP800-57]](bib.md#nist-sp800-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: -[[EnisaKeySize14]](bib.md#EnisaKeySize14), Section 3.6 also suggests that +[[EnisaKeySize14]](bib.md#enisakeysize14), 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]](bib.md#ECRYPT-II), Section 13.3 suggests at least 2432 bits for +[[ECRYPT-II]](bib.md#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 @@ -45,22 +45,22 @@ that factoring the modulus is typically easy. 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]](bib.md#CVE-1999-1444) +[[CVE-1999-1444]](bib.md#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 [[Bleich98]](bib.md#Bleiche98). The difficulty of +hence should be avoided [[Bleich98]](bib.md#bleich98). 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]](bib.md#BFKLSST12) analyze the difficult +attackers. Bardou et al. [[BFKLSST12]](bib.md#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 -[[Smart10]](bib.md#Smart10), though in this case the encryption did not use +[[Smart10]](bib.md#smart10), though in this case the encryption did not use PKCS #1 padding. NIST disallows the use of RSA PKCS #1 v1.5 for key-agreement -and key-transport after 2023 [[NIST-SP800-131A]](bib.md#NIST-SP800-131A). +and key-transport after 2023 [[NIST-SP800-131A]](bib.md#nist-sp800-131a). **Bugs** @@ -76,18 +76,18 @@ 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. [[KlPoRo03]](bib.md#KlPoRo03) +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]](bib.md#CVE-2015-1827)). Such differences are +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 -[[Manger01]](bib.md#Manger01). There are implementations that were susceptible -to Mangers attack, e.g. [[CVE-2012-5081]](bib.md#CVE-2012-5081). +[[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 diff --git a/doc/types.md b/doc/types.md index a83a4f9..c3b0a0c 100644 --- a/doc/types.md +++ b/doc/types.md @@ -785,7 +785,7 @@ Used in [RsaesPkcs1TestGroup](#RsaesPkcs1TestGroup). Fields in RsassaPkcs1GenTestGroup are\: -**name** | **type** | **desc** | **ref** | **since** | **enum** +**name** | **type** | **desc** |g4 **ref** | **since** | **enum** ------------- | ----------------------------------------------------------- | -------------------------------------- | -------- | --------- | -------- d | [BigInt](formats.md#DataTypes) | The private exponent | | | e | [BigInt](formats.md#DataTypes) | The public exponent | | |