The main focus are:
* incremental updates
* long inputs
* using ByteBuffers
Tested providers: jdk8, jdk11, BouncyCastle, Conscrypt, hazmat, pythons implementation of
hmac.
Resuts:
- all implementations are compatible.
- all implementations support HMAC with SHA-1 and SHA-2.
- BouncyCastle and python 3.7 support SHA-3
- jdk8 doesn't support SHA-3 and hence not HMAC with SHA-3
- jdk11 implements SHA-3, but not HMAC with SHA-3
- hazmat would support HMAC with SHA-3 if the backend were supporting the hashes,
but the defaultbackend does not.
NOKEYCHECK=True
PiperOrigin-RevId: 285161934
GitOrigin-RevId: 604eac41416d9dffc916c474a19ec7690401b22c
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
Motivation: tink implements this KDF.
Other libraries that support HKDF with SHA-384 and were tested:
(1) boringssl
(2) hazmat (which apparently uses a boringssl based backend)
References:
RFC 5869 defines HKDF generically, but does not mention SHA-384 as a potential
hash function.
RFC 6234 extends HMAC and KDF to other hash functions, but is unclear what should
be supported.
https://tools.ietf.org/html/draft-housley-hkdf-oids-01
appears to be the first RFC that concretely mentions HKDF with SHA-384
this is still a draft. This document does not mention SHA-224, hence
I'm not adding hkdf with SHA-224.
NOKEYCHECK=True
PiperOrigin-RevId: 278363773
GitOrigin-RevId: 79bd2681f0c3bb12ce5c9c555710fad6b20c6221
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 full list of failures is longer (~2800 cases).
They should be tested separately.
NOKEYCHECK=True
PiperOrigin-RevId: 276078119
GitOrigin-RevId: 06cbec6bed9413992b14a766134cbfc9bd826259
E.g., since HMAC simply pads the key with 0s, it does not matter
whether the salt is a empty byte array or any other array of size <= 64.
NOKEYCHECK=True
PiperOrigin-RevId: 275468663
GitOrigin-RevId: 9982a2f0675aee0035a78ea1889d2b23b9ede597
SHA-512/224 and SHA-512/256.
I don't expect these hashes to be heavily used. But there is
some potential for incompatibilities. E.g. BouncyCastle
previously used algorithm names such as "SHA512(224)WITHRSA"
while jdk uses "SHA512/224WithRSA".
RSA-OAEP would in principle allow the same hashes as RSA-PSS,
but the algorithm name in JCA is not well-defined,
using truncated hashes with OAEP doesn't make much sense,
and providers don't seem to implement it.
Test results:
jdk11 supports the truncated signatures.
BouncyCastle does not support the algorithm names
ConsCrypt does not support the algorithms.
Tested in a different CL:
boringSSL does not implement the algorithms.
Bugs: b/120406853 is about an alternative ASN encoding
of PSS-keys. This is an encoding that contains all the
parameters of signature scheme. This will be added by
jdk11. But so far, jdk11 fails to read its own key encodings.
I have test vectors for this encoding, but can't add them
without having at least one library accepting them.
NOKEYCHECK=True
PiperOrigin-RevId: 275018282
GitOrigin-RevId: 42c8b6d8e768858b6ec5a273d53f1e111268ecd7
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
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
BouncyCastle had an implementation for X25519 and X448 for some time.
But the JCA interface has been added only recently in version 1.61.
There is an overflow bug in this version that will be fixed
upstream in verion 1.63.
The tests ignore some minor bugs (Runtime exceptions instead of
checked exceptions) so that the test against BouncyCastle can be
added as a presubmit test.
Changing the ASN encoding of XDH keys.
Previously they used the jdk encoding.
This encoding was wrong.
NOKEYCHECK=True
PiperOrigin-RevId: 264348566
GitOrigin-RevId: 6564f188a3ed50f73c48cb8c41833d8c3798ab78
jdk11 did add ED25519 and ED448.
BC supports ED25519, but is slightly malleable.
Conscrypt supports none (rsp. uses different algorithm names).
This is related to
https://github.com/google/tink/issues/224
However, tests for signatures are still missing.
NOKEYCHECK=True
PiperOrigin-RevId: 260726100
GitOrigin-RevId: c4c5855aa3e86c0e47ad88f16e6496b98149364f
https://github.com/google/tink/issues/224
So far I haven't been able to reproduce the bug.
However, a lot of tests just check the signature verification.
NOKEYCHECK=True
PiperOrigin-RevId: 260466789
GitOrigin-RevId: bc252d53eaede4ec4eb89fef072dc5d19d17dbf5
AES-GMAC is equivalent to encrypting with AES-GCM an empty plaintext, using passing the
data to authenticate as additional data.
AES-GMAC is supported by keymaster and BouncyCastle.
keymaster has fixed nonce sizes and tag sizes (128-bits).
BouncyCastle has a fixed tag size (128-bit) when used through the JCE
interface.
NOKEYCHECK=True
PiperOrigin-RevId: 257385648
GitOrigin-RevId: d6947fd3604ca782078b7a02bab2a95160df2501
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
AEGIS256 is described here:
https://eprint.iacr.org/2013/695.pdfhttps://competitions.cr.yp.to/round3/aegisv11.pdf
Test vector generation:
I'm using a python version for the generation of the test vectors:
CL 252436459
The test vectors are then compared against a second implementation:
CL 252613429
Third party test vectors:
I don't have any third party test vectors.
https://eprint.iacr.org/2013/695.pdf contains some test vectors.
But, these test vectors can only be reproduced if the number of rounds
in finalize is reduced from 7 to 6.
Both papers describe AEGIS256 with 7 rounds in finalize.
All third party implementations I've found use 7 rounds, such as
this one:
https://github.com/torvalds/linux/blob/master/crypto/aegis256.c
NOKEYCHECK=True
PiperOrigin-RevId: 252811267
GitOrigin-RevId: 1de1fb2cb2c4e7d33a1ab8a23ddd63c79b143d3a
Versions:
Aegis128 and Aegis128L use
https://competitions.cr.yp.to/round3/aegisv11.pdf
The eprint version of Aegis128L in
https://eprint.iacr.org/2013/695.pdf
is slightly different, since the tag is computed differently.
To make this difference easier to spot, I'm including
the test vectors from the eprint version (the result is
of course invalid).
Generation:
The test vectors were generated with a 2nd implementation
(in python). This would hopefully allow to spot boundary
errors.
NOKEYCHECK=True
PiperOrigin-RevId: 251426918
GitOrigin-RevId: 3fc993aa9e84495cefd1f20bcc5a0fb3a3179883
Changes:
* Unused flags are no longer listed in "notes:"
* Added some new invalid encoding containing special values such as NaN.
* Adding jwk keys to RSA-OAEP test vectors if the jwk key is defined.
* Adding a flag InvalidOaepPadding to RSA-OAEP test vectors to test vectors
where leaking padding information might allow Manger's attack.
* Adding test vectors for invalid padding: PKCS-1 padding for PSS signatures
signatures without hashing.
* Adding test vectors from RFC 8037 to XDH. (There is not enough cross checking
otherwise, since most libraries don't implement XDH).
NOKEYCHECK=True
PiperOrigin-RevId: 237066566
GitOrigin-RevId: 44dd5c1fda5d152b6741824ad9d5400b4cffd6aa
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
Adding test vectors for AES-SIV-CMAC for AEAD.
I.e. these are test vectors for AES-SIV-CMAC where encryption takes
two AAD arguments: one argument acting as the nonce and one argument
acting as the additional data.
Adding test vectors for XDH where the keys use jwk encoding.
These are mostly the same test vectors as used for other XDH tests,
but the keys are enocded according to RFC 8037.
The test vectors include two test vectors from RFC 8037 section A.6 and
A.7 to ensure that the same encoding is used.
Fixing the algorithm name for AES-GCM-SIV.
NOKEYCHECK=True
PiperOrigin-RevId: 232840812
GitOrigin-RevId: cc0604472074630f0b00894c4234e06ac0bc4f0a
Changing incorrect documentation in the header:
The public keys are X509 encoded. Private keys are just integers.
Adding some more edge cases:
These are mostly cases where the y coordinate is a special case.
Such special cases can lead to overflows if the point is normalized
during the ECDH compuation. A normalization is sometimes done in
precomputations.
Somewhat better comments: I.e. explain what the edge case is.
Removing unnecessary notes: Sometimes test vectors with labels are generated,
but not used because encoding can't handle the test vectors. Previously the
label would still end up in the notes section. This has been removed.
NOKEYCHECK=True
PiperOrigin-RevId: 232640195
GitOrigin-RevId: b2bae8ea496a482297ea92f125d7762990015a33
There are format changes:
* All test vector files contain a new field schema,
which points to a JSON schema definition
in the directory wycheproof/schema.
* More consistent type definition:
E.g. the field "type" in a testGroup is now describing the
type of the test the vectors are intended for. The type of
the test defines formatting (e.g. whether signatures use
P1363 encoding or ASN encoding) and the tested operation
(e.g. whether the test vectors signatures are primarily
are meant for verification or signature generation)
The test types will also be included in the documentation.
* More unified test vectors:
RSA-PKCS#1 v1.5 signature no longer have a field "padding".
* Added public and private keys in jwk format.
This is done when the jwk format is defined and
where the key format is not part of the test.
Additional test vectors:
* Added vectors for edge cases that can occur
in ECDH computations with projective or Jacobian
coordinates. In particular this implements a detection for the
attack in "Zero-Value Point Attacks on Elliptic Curve Cryptosystem"
by T.Akishita and T Takagi, ISC 2003
* Added more edge cases for Xdh.
* Added more test cases for ASN parsing (e.g. high number tags)
* Added test vectors for CVE-2017-18330 to CCM and EAX.
* Added more edge cases for poly1305
* Added test vectors for HKDF.
* Removed some duplicates in the test vectors.
NOKEYCHECK=True
PiperOrigin-RevId: 228700977
GitOrigin-RevId: 5708361fc71a2089a5c102be7d73adbc3b3b8efd
ed448_test.json
Test vectors for EDDSA over the curve edwards448
xchacha20_poly1305_test.json
Test vectors for Xchacha20 with poly1305 as defined in
https://datatracker.ietf.org/doc/draft-arciszewski-xchacha
NOKEYCHECK=True
PiperOrigin-RevId: 224343437
GitOrigin-RevId: 0b9a4eb9074b6ea1f76d0ff435dac215323024a1
salt length do not match. Applications typically used RSA-PSS such
that signature hash and mgf hash are the same and the salt length
is either 0 or the size of the hash.
RFC 8017 allows other combinations. These test check that such
combinations are either rejected or are implemented correctly.
The test file contains just one valid signature for each combination
of mgf-hash signature-hash, salt length that is tested.
Results:
BoringSSL accepts all signatures.
BouncyCastle rejects signatures where mgf and signature hash do not match.
Conscrypt rejects signatures where mgf and signature hash do not match.
Jdk (i.e. the version we have in google3) does not implement RSA-PSS yet.
PiperOrigin-RevId: 206761543
GitOrigin-RevId: f5cffdf23fc04cc0b15925c34c0cb74dfda51737
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 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
bleichen