Please note that this was created with g4 rollback, but the version number in the Wycheproof file regresses. I'm unsure whether that's desired. The BoringSSL change works for both the old and new files so can be landed without touching Wycheproof if that's better.
*** Reason for rollback ***
Fix to BoringSSL scripts now included.
*** Original change description ***
Adding the curve back to the test cases to avoid failing BoringSSL tests.
***
PiperOrigin-RevId: 205957468
GitOrigin-RevId: c0afaa191d5509050bbea307265b07bca61b4714
Tests using the new test vectors will be added in another CL.
Changes:
AES-GCM has test vectors for modified tags, which were previously missing.
ECDSA has more test vectors for potential arithmetic errors.
There are no more random test vectors.
Webcrypto has a few test vectors with the bitcoin curve (since some libraries
want to add this).
DSA and ECDSA have more invalid test vectors with r,s = ((q-1)/2 or q-1).
This is motivated by some weak ElGamal implementation in beecrypt.
ECDH test vectors have some new files where the public key is just a point
using SEC 1 / X9.62 format.
All tests for ASN modifications are removed from ecdh_test.json, so that
this file has a more resonable size. These test vectors are included in
the files ecdh_curve_test.json.
EDDSA has a few more invalid test vectors for malformed signatures.
(I.e. the python implementation in the RFC has a small bug).
Adding test vectors for AES-CCM. (tested against BouncyCastle, which sort of
abuses the JCE interface)
There are some test vectors for RSA-PSS (so far tested with BouncyCastle and boringSSL)
More tests will be added when we have an idea what is actually being used.
PiperOrigin-RevId: 205802874
GitOrigin-RevId: 250ab89370a0dcfc56e887fb185a494f45f9a3f5
First, background and history:
In Java, an ECDH public key can be encoded as a SubjectPublicKeyInfo spec [1]. This spec contains the public point, and a named curve or curve parameters [2]. To test ECDH libraries, Wycheproof generates public key specs with modified curve parameters, and checks that the libraries must reject them [3].
Android M and N (and possibly other versions) do not reject said public keys specs. Given a spec Android just takes the field ID, and derives the rest of the parameters. This leads to a somewhat interesting situation: not only Android accepts Wycheproof's modified public key specs, but it also computes the shared secrets correctly and securely. So we changed Wycheproof to accept Android's behavior, and added to each test case the expected shared secret, had the public key spec not been modified.
What went wrong:
The expected shared secrets for "modified prime" and "public key of order 3" test are incorrect. I found that the public key specs (the "public" field in the ecdh_test.json) don't contain the same public point as in other tests. I'm not sure this is intentional, but because the public point is different the expected shared secret must be different too.
Let's look at test case #336. Its expected shared secret is the same as test case #335. Yet two test cases contain two different public points, as shown below (
the public point is the last BIT STRING, it starts with 04):
# Test case 335
0 304: SEQUENCE {
4 233: SEQUENCE {
7 7: OBJECT IDENTIFIER '1 2 840 10045 2 1'
16 221: SEQUENCE {
19 1: INTEGER 1
22 44: SEQUENCE {
24 7: OBJECT IDENTIFIER '1 2 840 10045 1 1'
33 33: INTEGER
: 00 FF FF FF FF 00 00 00 01 00 00 00 00 00 00 00
: 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF
: FF
: }
68 68: SEQUENCE {
70 32: OCTET STRING
: FF FF FF FF 00 00 00 01 00 00 00 00 00 00 00 00
: 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FC
104 32: OCTET STRING
: 5A C6 35 D8 AA 3A 93 E7 B3 EB BD 55 76 98 86 BC
: 65 1D 06 B0 CC 53 B0 F6 3B CE 3C 3E 27 D2 60 4B
: }
138 65: OCTET STRING
: 04 6B 17 D1 F2 E1 2C 42 47 F8 BC E6 E5 63 A4 40
: F2 77 03 7D 81 2D EB 33 A0 F4 A1 39 45 D8 98 C2
: 96 4F E3 42 E2 FE 1A 7F 9B 8E E7 EB 4A 7C 0F 9E
: 16 2B CE 33 57 6B 31 5E CE CB B6 40 68 37 BF 51
: F5
205 33: INTEGER
: 00 FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF
: FF BC E6 FA AD A7 17 9E 84 F3 B9 CA C2 FC 63 25
: 51
: }
: }
240 66: BIT STRING
: 04 15 10 26 4C 18 9C 3D 52 3F F9 91 6A BD 70 69
: EF A6 96 8D 8D C7 DD B6 45 7D 78 69 B5 3E A6 0C
: DC FA FB 7E D4 78 6D A1 5D 29 EE 59 25 6F 53 6D
: A3 57 5A 48 88 C1 BB 0A 95 B2 56 F4 A7 E9 FD 76
: 4A
: }
# Test case 336:
0 307: SEQUENCE {
4 236: SEQUENCE {
7 7: OBJECT IDENTIFIER '1 2 840 10045 2 1'
16 224: SEQUENCE {
19 1: INTEGER 1
22 44: SEQUENCE {
24 7: OBJECT IDENTIFIER '1 2 840 10045 1 1'
33 33: INTEGER
: 00 FD 09 10 59 A6 89 36 35 F9 00 E9 44 9D 63 F5
: 72 B2 AE BC 4C FF 7B 4E 5E 33 F1 B2 00 E8 BB C1
: 45
: }
68 68: SEQUENCE {
70 32: OCTET STRING
: 02 F6 EF A5 59 76 C9 CB 06 FF 16 BB 62 9C 0A 8D
: 4D 51 43 B4 00 84 B1 A1 CC 0E 4D FF 17 44 3E B7
104 32: OCTET STRING
: 5A C6 35 D8 AA 3A 93 E7 B3 EB BD 55 76 98 86 BC
: 65 1D 06 B0 CC 53 B0 F6 3B CE 3C 3E 27 D2 60 4B
: }
138 65: OCTET STRING
: 04 00 00 00 00 00 00 00 00 00 00 06 59 7F A9 4B
: 1F D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
: 02 1B 8C 7D D7 7F 9A 95 62 79 22 EC EE FE A7 3F
: 02 8F 1E C9 5B A9 B8 FA 95 A3 AD 24 BD F9 FF F4
: 14
205 33: INTEGER
: 00 FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF
: FF BC E6 FA AD A7 17 9E 84 F3 B9 CA C2 FC 63 25
: 51
240 1: INTEGER 1
: }
: }
243 66: BIT STRING
: 04 00 00 00 00 00 00 00 00 00 00 06 59 7F A9 4B
: 1F D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
: 02 1B 8C 7D D7 7F 9A 95 62 79 22 EC EE FE A7 3F
: 02 8F 1E C9 5B A9 B8 FA 95 A3 AD 24 BD F9 FF F4
: 14
: }
[1] https://tools.ietf.org/html/rfc5280#section-4.1.2.7.
[2] https://tools.ietf.org/html/rfc3279#section-2.3.5
[3] Many libraries don't, and usually that leads to vulnerabilities that leak the private key.
PiperOrigin-RevId: 204515375
GitOrigin-RevId: 26b6eb30145d94209b9d828db7c6a0b0ed6be695
This is a part of a large-scale change: go/lsc-format-bzl-files . All .bzl files are being formatted with buildifier.
To format a file manually run `buildifier path/to/file.bzl`. Integration with `g4 fix` will be available later, but you can try using `g4 fix --format=bzl`.
Tested:
tap_presubmit
Some tests failed; test failures are believed to be unrelated to this CL
BEGIN_PUBLIC
Format .bzl files with buildifier
END_PUBLIC
PiperOrigin-RevId: 203461813
GitOrigin-RevId: 079b58e5340b57819c361af79e4b820f4c66e590
This CL only adds test vectors.
Changes using the new test vectors are in CL 199130745.
There are the following changes to version 0.4:
ECDSA test vectors with a valid signature but non-DER encoding
have "result":"invalid" and have the flag "BER".
Version 0.4.4 has some additional test vectors:
- Tests for invalid encoding of the INTEGER 0 (i.e. "0200" instead
of "020100")
- Truncation after the ASN tag.
- ECDH test vectors now include shared secrets in invalid test vectors.
This allows to check if an implementation is just sloppy at comparing
public keys (i.e. ignoring parameters) or vulnerable (i.e. using
modified parameters for ECDH computation)
- More tests vectors like the unexplained test vector in b/74209208
- ECDH now has tests vectors where public and private keys are
on different, but isomorphic curves. The result is invalid, since
the encoding of the shared secret is undefined.
- ECDH has test vectors with modified ASN. Again the shared secret
computed with the original public key is included so that it is
a bit easier to distinguish between serious and non-serious cases.
- Some third party test cases were added to all files. They are
removed.
Version 0.4.5:
- adds more test vectors for ECDSA.
- adds more test vectors for RSA signatures and splits the signatures
into more files, sorted by key size and hash.
Version 0.4.6:
- adds an uncompressed encoding to EC keys.
- rsa_signature_test.json now contains more keys for size 1024 to 4096.
Most keys only contain a small number of tests.
More extensive tests are done with a 2048 bit key only.
New bugs:
BouncyCastle and ConsCrypt both accepts some invalid keys (with
additional garbage) as valid. These bugs are currently silenced
by marking the test vectors as acceptable. I.e. the first goal is
to verify that invalid ECDH keys cannot be used to find the private
key.
PiperOrigin-RevId: 199611433
GitOrigin-RevId: f1f99cc52617e18224ec98f84dcaa55c42df9b46
* Add more information about the used Java Runtime and the tested provider version
* Added some recent information about SunEC and Utimaco HSM problems
This supports RFC 3394 and RFC 5649,
which is also described in NIST SP 800 38f.
I also have a mini analysis of the primitive:
If one cares about distinguishing attacks then
there is an attack with a somewhat smaller complexity
than what NIST claims in their standard:
https://docs.google.com/document/d/1oH36v6SNdff5tkydC75EnqRyqqgHbXR4hy_SMPzwqVU/edit?usp=sharing
But even if one cares about these attacks then the key
wrappings are nowhere comparable to the attacks possible against e.g.
AES-GCM.
PiperOrigin-RevId: 192747615
GitOrigin-RevId: 0bebc767022ba3053c1d0391378d5c0b32b7f5be
- Remove `extends TestCase` which triggered usage of the JUnit3 runner
- Replace `import static org.junit.Assert.assertArrayEquals;` with `import static org.junit.Assert.*;`
- Replace `import junit.framework.TestCase;` with `import org.junit.Test;`
- Annotate all existing test methods (that are prefixed with 'test' and have no args) with `@Test`
update/doFinal are required to be "copy-safe". From the javadoc:
Note: this method should be copy-safe, which means the input and output
buffers can reference the same block of memory and no unprocessed input
data is overwritten when the result is copied into the output buffer.
However many implementations of JCE methods do not implement this property in
all cases. Notably, BouncyCastle fails this test on arrays, and the built-in
OpenJDK providers fail when the input bytebuffer is either a read-only
array-backed byte buffer, or if the buffers are direct buffers. For SunJCE,
this has been acknowledged publicly by Oracle at
https://bugs.openjdk.java.net/browse/JDK-8181386 .
These new tests verify correct overlapping buffer handling for AES/GCM
specifically; as future work, it would be good to generalize these tests for
other ciphers and modes.
The current code fails to initialize the cipher c after a c.doFinal()
fails. According to JCE documentation, a cipher is in an undefined state
after throwing an exception.
- add maven entry for BC 1.56 and update the versions range
- DHIES weak crypto tests now pass if algs not even supported
- some ECIES entries moved to the invalid list
- ECIES decryption init calls fixed to pass the correct parameters
- EciesTest.testModifyPoint now expects GeneralSecurityException
* Removing duplicates from BigIntegerTest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142548323
* Remove @NoPresubmitCheck from testModifiedPublic() and testModifiedPublicSpec(). The corresponding bug was fixed in BC 1.55 or BC 1.56.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142561682
* minor typos
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142743772
* Regenerating the test vectors for ECDSA:
- this adds more comments for bugtypes and modifications or the signatures.
- fixes some ugly formatting.
- adds some additional test vectors.
There are no new bugs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144619819
* Regenerating DSA test vectors:
This adds a few more test vectors.
The test vectors are now divided between test vectors with valid BER encodings
and test vectors with invalid DER encodings.
The description of the test vector better describes what was modified.
Also fixing issue #17 on Github: testVectors in DsaTest not using the message parameter
There are no changes to the presubmit tests. Tests that can be enabled because of the
Oracles security update will be added in another CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144814889
* Regenerating test vectors for EcdhTest.java
Merging a test with small order into the test vectors.
Fixing ASN encoding of 0 (from 0200 to 020100, i.e. length must be > 0).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144815129
* Regenerating RSA signatures.
Adding test vectors that were removed because of b/31575502. Oracle fixes this with CVE-2016-5547.
Changing ASN tags with value 0x50 to 0x30 (0x50 would be something like sequence of sequence but does not exist), hence the old vectors are unlikely to cause problems.
Adding more modifications of OIDs. The new vectors unpack the OIDs and change the nodes.
(E.g. the OID for sha256 is the hexadecimal string "608648016503040201" which is an
ASN encoding of "2.16.840.1.101.3.4.2.1". The new test vectors include invalid encoding,
encodings with additional nodes, deleted nodes and nodes that are changed to large integers)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144846826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145060646
* Removing presubmit restrictions for tests that have been fixed internally and upstream.
Mainly these are tests with CVEs that were announced during the Jan 17 security update
by Oracle.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145397539
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145418516
* Adding the CVE numbers from Oracles Jan 17 security update to the documentation.
Minor changes to some test vectors: Some of the garbage added to the ASN encoding
was itself incorrect and has been replaced.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145650774
* ECDSA MODIFIED_SIGNATURES should be public now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146186539
Wycheproof Team