Main changes:
BigInteger encoding is now always a multiple of 2.
Comments try to be a bit more precise. This leads to a different
grouping of the test vectors.
All test vectors with result="acceptable" have at least one
flag.
New vectors:
AEGIS: adding test vectors with the same tag (basically just
answers the question: is AEGIS a hash?)
Test vectors from old versions of the cipher now have ciphertext.
I.e. both encrypting or decrypting should tell testers that they
are using old versions.
AES-CMAC: more test vectors with 128-bit tag.
DSA, ECDSA: better description of the ASN modifications (this reorders
the test vectors) and a few more ASN modifications
KWP: adding modified paddings
XDH: adding more edge cases, no longer using the same private key for multiple
test vectors.
RSA-PSS: adding more valid test vectors. The new test vectors have an edge case
message digest.
NOKEYCHECK=True
PiperOrigin-RevId: 264817632
GitOrigin-RevId: 0c8e6eec11db1ca7088f89d0c1de48c5af892e47
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
bleichen