Splitting DSA test vectors into several files depending on key size and hash.
I'm only adding files for DSA parameters that are supported by libraries that are used in google3. Most projects now prefer ECDSA.
Tests with additional parameters (e.g. 4096-bit keys or other hash functions) can be added, if there is a reason for doing so.
Tested providers:
jdk8 supports DSA with ASN encoding.
jdk11 supports DSA with ASN and P1363 encoding.
BouncyCastle only supports DSA with ASN encoding.
(P1363 format is only supported for ECDSA).
ConsCrypt does not support DSA at all.
b/33446454: The tests ignore this issue to avoid missing bigger mistakes.
NOKEYCHECK=True
PiperOrigin-RevId: 281068296
GitOrigin-RevId: 7c4178527d940fccbcfcfdd88f1cb850a17746db
Adding more tests:
- the previous test did not include any primes. Hence arithmetic
errors in a primality test would likely remain undetected.
- some primes have been generated so that the multiplier for a
Montgomery reduction is an edge case (e.g. high or low Hamming weight).
- adding negatives of primes. Different libraries disagree, whether such
integers are prime or not. The corresponding test vectors have a flag
and result "acceptable".
The following libraries have been tested:
java.math.BigInteger: primality testing is not part of JCA and hence is
provider independent.
sympy: Old versions of sympy used a weak set of bases and was deterministic.
This is no longer the case.
NOKEYCHECK=True
PiperOrigin-RevId: 278337837
GitOrigin-RevId: 02debe45343e8da38b21a6e7a56a4a2b1c050bd8
The test vectors allow to check libraries that read PEM
files against bugs similar to:
https://bugs.openjdk.java.net/browse/JDK-8213363
Testing:
So far I'm testing against hazmat (i.e. a python wrapper
around openssl).
The version in google3
google3/third_party/py/cryptography/hazmat/
only supports x25519, hence the x448 test vectors are not tested.
The test vectors are essentially the same as in x448_asn_test.json,
which pass BouncyCastle (with some fixes for overflow).
NOKEYCHECK=True
PiperOrigin-RevId: 269317802
GitOrigin-RevId: f29c60bccd75d3a9a16f833e108bdf83e385fc87
The main purpose is to test / explore the robustness of the VMAC implementation
such as the one in security/util (e.g. CL 254384251) as well as finding potential weaknesses if VMAC is used in an unconventional way. VMAC is widely used in
Google, but so far there is no list of test vector that check corner cases,
such as carry propagation.
VMAC has a number of odd features, which are tested with these vectors:
- The nonce is at most 127-bit long. This is necessary, because VMAC uses
an AES-block cipher. Inputs with the most significant bit set are used
for the key derivation. The same inputs must not be used for encrypting
the nonce.
- VMAC requires 128-bit integer arithmetic for some of its temporary results.
This leaves a lot of opportunities for overflow and carry errors.
The test vectors contain a fairly large number of edge cases to check
for such problems.
- VMAC lacks "plaintext awareness". A valid VMAC does not prove that the
sender knows the plaintext. An example is this: if the VMAC is computed
over eg. tag = VMAC(msg || password) then it would be possible for the
sender to choose msg, such that is valid for any password.
NOKEYCHECK=True
PiperOrigin-RevId: 255599337
GitOrigin-RevId: 22d336b66c370dae251f1fa119cf952035f9c8d5
The test vectors replace the previous test for padding oracles, which
had to generate a new key. The test vectors add some new
test cases that are edge cases for the modular exponentiation.
NOKEYCHECK=True
PiperOrigin-RevId: 236813461
GitOrigin-RevId: a92ab2a6af48d3285735fbf5c8ecb66c0750f46b
Requires test vectors with version 0.7 or higher.
NOKEYCHECK=True
PiperOrigin-RevId: 228853889
GitOrigin-RevId: d669cb263964511c7c95cb32f83e1f07f4bf6b51
Wycheproof Team