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
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
Daniel Bleichenbacher