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

Alternative format for md links.

Browse Source 
Maybe this one is more compatible with github.

NOKEYCHECK=True
PiperOrigin-RevId: 282920749
GitOrigin-RevId: 3b0342b7798be79eebdd9b8b11b65872674263a6
This commit is contained in:
bleichen
2019-11-28 04:04:48 -08:00
committed by Tink Team
parent 91ee28e1c4
commit c1cbf80387
9 changed files with 133 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/aesgcm.md
+4 -4
View File
@@ -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
doc/bib.md
+48 -43
View File
@@ -31,96 +31,101 @@ Additional information is added as a separate paragraph.
<!-- papers -->
### 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
<!-- standards -->
### 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
<!-- use first label for refs depending on the version -->
### 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
<!-- CVEs -->
### 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.
doc/dh.md
+13 -13
View File
@@ -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.
doc/dsa.md
+9 -8
View File
@@ -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$$.
<!-- Some libraries don't check that r and s are integers.-->
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
doc/ecdh.md
+11 -11
View File
@@ -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
doc/hkdf.md
+31
View File
@@ -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
doc/key_wrap.md
+4 -7
View File
@@ -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.
doc/rsa.md
+12 -12
View File
@@ -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
doc/types.md
+1 -1
View File
@@ -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 | | |