yuqei/wycheproof
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refactoring ecdh.md.

Browse Source 
Adding some references to dh.md and dsa.md
Adding a bibliography.
There does not seem to be any simple support for references in g3doc.

NOKEYCHECK=True
PiperOrigin-RevId: 231400389
GitOrigin-RevId: db928a9f57d11ee736348c468412a320e03698d4
This commit is contained in:
bleichen
2019-01-29 07:21:36 -08:00
committed by Tink Team
parent 1025b43dd7
commit 30c04bdbda
6 changed files with 476 additions and 300 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/aesgcm.md
+11 -25
View File
@@ -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
doc/bib.md
+233
View File
@@ -0,0 +1,233 @@
# References
<!-- Format for references:
Unfortunately there seems to be no simple way to manage references in markdown.
This file is an attempt to add a bibliography. Because of the lack of tools it
is necessary to define some simple formats, with the idea that reformatting at
a later point becomes easy.
RFCs: RFCs are supported. A text like RFC 2785 automatically generates a link.
Hence RFCs are not listed in this bibliography.
CVEs: CVEs use a label CVE-xxxx-yyyy. The description of CVEs is often short
and sometimes misleading. Additional information is often difficult to find.
Hence the CVE entry here will often contain some additional descriptions.
Papers:
Because of the restrictions of markdown Papers use a section header to allow
references. To allow future reformatting paper references use the following
lines:
line 1: authors (comma separated)
line 2: "title"
line 3: publication, pages
line 4: link
Additional information is added as a separate paragraph.
-->
<!-- mdformat off see above -->
<!-- papers -->
### 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
<!-- standards -->
### 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
<!-- use first label for refs depending on the version -->
### 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
<!-- CVEs -->
### 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.
<!-- mdformat on -->
doc/dh.md
+51 -80
View File
@@ -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.
<!--
## Sources that might be used for additional tests:
doc/dsa.md
+48 -61
View File
@@ -3,28 +3,28 @@
[TOC]
The digital signature algorithm (DSA) is one of three signature schemes
descripted in the digital signature standard [DSS].
descripted in the digital signature standard [[NIST-DSS]]{bib.md#NIST-DSS}.
## Key generation
4.2 Selection of Parameter Sizes and Hash Functions for DSA
The DSS specifies the following choices for the pair (L,N),
where L is the size of p in bits and N is the size of q in bits:
4.2 Selection of Parameter Sizes and Hash Functions for DSA The DSS specifies
the following choices for the pair (L,N), where L is the size of p in bits and N
is the size of q in bits:
L | N
---:|----:
1024| 160
2048| 224
2048| 256
3072| 256
L | N
---: | --:
1024 | 160
2048 | 224
2048 | 256
3072 | 256
The tests expect the following properties of the parameters used during
key generation:
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 [DSS].
* 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.
* 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}.
* 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.
## Signature generation
@@ -32,9 +32,10 @@ The DSA signature algorithm requires that each signature is computed with a new
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 [DSS]. There is also the
possibility that the use of mismatched implementations for key generation and
signature generation are leaking the private keys.
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
mismatched implementations for key generation and signature generation are
leaking the private keys.
## Signature verification
@@ -50,19 +51,18 @@ u2 = w \cdot r \bmod q\\
\end{array}
$$
and then verifies that \\(r = (g^{u1}y^{u2} \bmod p) \bmod q\\)
and then verifies that $$r = (g^{u1}y^{u2} \bmod p) \bmod q$$
## Incorrect computations and range checks.
Some libraries return 0 as the modular inverse of 0 or q.
This can happen if the library computes the modular
inverse of s as \\(w=s^{q-2} \mod q\\) (gpg4browsers) of simply
if the implementations is buggy (pycrypto). if additionally to such
a bug the range of r,s is not or incorrectly tested then it might
be feasible to forge signatures with the values (r=1, s=0) or (r=1, s=q).
In particular, if a library can be forced to compute \\(s^{-1} \mod q = 0\\)
then the verification would compute \\( w = u1 = u2 = 0 \\) and hence
\\( (g^{u1}y^{u2} \mod p) \mod q = 1 .\\)
Some libraries return 0 as the modular inverse of 0 or q. This can happen if the
library computes the modular inverse of s as $$w=s^{q-2} \mod q$$ (gpg4browsers)
of simply if the implementations is buggy (pycrypto). if additionally to such a
bug the range of r,s is not or incorrectly tested then it might be feasible to
forge signatures with the values (r=1, s=0) or (r=1, s=q). In particular, if a
library can be forced to compute $$s^{-1} \mod q = 0$$ then the verification
would compute $$ w = u1 = u2 = 0 $$ and hence $$ (g^{u1}y^{u2} \mod p) \mod q =
1 .$$
## Timing attacks
@@ -72,7 +72,8 @@ TBD
## JDK
The jdk8 implementation of SHA1withDSA previously checked the key size as follows:
The jdk8 implementation of SHA1withDSA previously checked the key size as
follows:
```java
@Override
@@ -134,26 +135,29 @@ The next line contains a default in the initialization
```java
   Signature s = Signature.getInstance("DSA");
```
This line is equivalent to
```java
   Signature s = Signature.getInstance("SHA1withDSA");
```
Hence the code above uses SHA1 but with DSA parameters generated for SHA-224
or SHA-256 hashes. Allowing this combination by itself is already a mistake,
but a flawed implementaion made the situation even worse.
The implementation of SHA1withDSA assumeed that the parameter q is 160 bits
long 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 [HS99]. 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 [N04].
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 [O90].
Hence the code above uses SHA1 but with DSA parameters generated for SHA-224 or
SHA-256 hashes. Allowing this combination by itself is already a mistake, but a
flawed implementation made the situation even worse.
The implementation of SHA1withDSA assumeed that the parameter q is 160 bits long
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
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
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).
## Further notes
@@ -173,20 +177,3 @@ use one would call one of:
A possible way to push such a change are code analysis tools. "DSA" is in good
company with other algorithm names “RSA”, “AES”, “DES”, all of which default to
weak algorithms.
## References
[HS99]: N.A. Howgrave-Graham, N.P. Smart,
“Lattice Attacks on Digital Signature Schemes”
http://www.hpl.hp.com/techreports/1999/HPL-1999-90.pdf
[N04]: Phong 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
[O90]: A. M. Odlyzko, "The rise and fall of knapsack cryptosystems", Cryptology
and Computational Number Theory, pp.75-88, 1990
[DSS]: FIPS PUB 186-4, "Digital Signature Standard (DSS)", National Institute
of Standards and Technology, July 2013
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
doc/ecdh.md
+83 -44
View File
@@ -1,58 +1,97 @@
# ECDH
[TOC]
##ECDH description:
## ECDH description:
See https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman
##Bugs
## Invalid key attack
Some libraries do not check if the elliptic curve points received from another
party are points on the curve. 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.
Some libraries fail to do this check.
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
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.
**Potential exploits:**
The damage done depends on the protocol that uses ECDH. E.g. if ECDH is used
with ephemeral keys then the damage is typically limited. If the EC keys are
static, i.e. used for multiple key exchanges then a failure to verify a public
point can disclose the private key used in the same protocol.
(To do: add papers describing the attack).
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).
##Libraries
**Sun JCE provider:**
ECDH does not check if the points are on the curve.
The implementer must do this.
The test vectors check for the following problems:
**Bouncycastle:**
The ECDH implementation does not check if the point is on the curve.
Furthermore, Bouncycastle does not even check if the public and private key are
on the same curve. It performs a point multiplication \\(x \cdot Y\\) over the
curve specified by the public key.
* point is not on curve
* point is on twist
* curve of public key is used for ECDH
* parameters of public key are used for ECDH
**OpenSSL:**
Point verification is done in OpenSSL if the right functions are used.
Since OpenSSL is not well documented it is a bit tricky to find the right
functions.
(To do: maybe add an example).
### Countermeasures
##Countermeasures
TODO:
* use point compression. Formats such as X509EncodedKeySpec
in Java include bits that indicate whether the point is compressed or not.
Hence an attacker can always choose to use uncompressed points as long as this
option is incorrectly implemented.
* check that public and private key use the same curve
* restrict the protocol to named curves
* reconstruct the public key explicitly using the parameters of the private
key.
* use point compression. Formats such as X509EncodedKeySpec in Java include
bits that indicate whether the point is compressed or not. Hence an attacker
can always choose to use uncompressed points as long as this option is
incorrectly implemented.
* check that public and private key use the same curve
* restrict the protocol to named curves
* reconstruct the public key explicitly using the parameters of the private
key.
**Further recommendations:**
If possible I also check if the points are on the curve after point
multiplications on an elliptic curve in the hope to catch implementation
and hardware faults.
## Side channel attacks that may be detectable by Wycheproof
## Some notable bugs:
* ECDHC in bouncy castle could be broken by modifying the order of the public key.
### Arithmetic errors
Arithmetic errors in the implementation of the elliptic curve point
multiplication can lead to attacks.
### Timing differences
Large enough timing differences can give a signal that is exploitable.
### Typical attacks
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
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
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).
## 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
side channels is not possible in Wycheproof.
### Countermeasures
* constant time implementation (does not cover arithmetic errors)
* randomization (harder than it looks)
* Checking that points are on the curve after point multiplication. (Detects a
potential problem, but does not prevent it).
## Invalid encodings
Another type of bugs is the handling of invalid encodings. The damage of these
kind of bugs depends on the exception handling. A frequent consequence of not
testing encoding properly are denial of service attacks.
The test vectors contain a number of invalid encoded ephemeral keys. Some of the
test vectors contain a shared secret key. This is done so that a ECDH
computation done after importing an invalid key can be evaluate. I.e. If
importing a key is somewhat forgiving, but the ECDH compuatation is nevertheless
correct then this is less likely to lead to an attack than if the ECDH
compuation after importing an invalid key leads to an incorrect point
multiplication.
doc/rsa.md
+50 -90
View File
@@ -6,14 +6,15 @@
**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.
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
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
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
@@ -26,31 +27,30 @@ 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.
**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]
**Other bugs:** The public exponent e should be larger than 1
[[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 [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.
hence should be avoided [[Bleich98]](bib.md#Bleiche98). 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
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
PKCS #1 padding.
**Bugs**
* Bouncycastle throws detailed exceptions:
InvalidCipherTextException("unknown block type") or
InvalidCipherTextException("block padding incorrect").
* Bouncycastle throws detailed exceptions: InvalidCipherTextException("unknown
block type") or InvalidCipherTextException("block padding incorrect").
<!-- the SUN provider used to include that block type -->
@@ -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.
<pre>
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
}
</pre>
[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.