The ways a token can be wrong

A token declaring alg none and carrying no signature at all. A service that accepts it can be forged by anyone who can type. CWE-347.

A correctly signed token whose exp claim is in the past. A service that accepts it is not checking expiry, so any leaked token works forever.

A correctly signed token whose nbf claim is in the future. Usually a clock difference between two machines rather than an attack.

A token that claims to be signed, with the signature deleted. A service treating an absent signature as nothing to check can be forged. CWE-347.

A correctly signed token whose contents were changed afterwards. The signature no longer matches the claims, which is what signing exists to catch. CWE-345.

A token signed with the real key but pointing at a key id that is not published. A service that tries every key until one works is guessing. CWE-347.

A correctly signed token, and the control case: if your service rejects this one, the failure cases below will not tell you much.

A properly signed token, signed with a key your service should not trust. Checks whether it verifies which key signed, or only that something did. CWE-347.

Algorithm none must not be accepted by default.

The JWE/JWS is encoded with JSON serialization instead of compact serialization.

The PKCS #1 padding of the signature has been modified.

The signature has been modified.

The signature uses a different algorithm than the algorithm specified in the key.

The plaintext in this test vector has been compressed.

The JWE/JWS is encoded with JSON serialization instead of compact serialization.

The PKCS #1 padding has been modified. Padding errors should not be distinguishable.

The private key is an RSA-OAEP key, but the encryption uses PKCS #1.5 padding

A key was used with the wrong cryptographic primitive.

Marks test vectors with behavior that is not well defined by the RFCs. Best practice is to reject such cases.

The keyset contains multiple keys with the same kid. The test expects that such keysets are rejected.

The keyset contains public and private keys. The test expects that such keysets are rejected.

Test vector from RFC 7518.

The test vector contains a ciphertext with a modified tag. The test vector was obtained by manipulating a valid ciphertext. The purpose of the test is to check whether the verification fully checks the tag.

The test vector contains pseudorandomly generated inputs. The goal of the test vector is to check the correctness of the implementation for various sizes of the input parameters. Some libraries do not support all the parameter sizes. In particular the size of the IV is often restricted.

Special case iv

The JWE/JWS is encoded with JSON serialization instead of compact serialization.

The provided keys are actually JSON Web Keysets instead of single JSON Web Keys.

AES-EAX reduces the counter value modulo 2^128. This test vector was constructed for testing the wrapping of the counter value.

Overflow with large IVs

Known test vector from eprint.iacr.org/2003/069

The test vector contains a ciphertext with a modified tag. The test vector was obtained by manipulating a valid ciphertext. The purpose of the test is to check whether the verification fully checks the tag.

The test vector contains pseudorandomly generated inputs. The goal of the test vector is to check the correctness of the implementation for various sizes of the input parameters.

AES-EAX allows arbitrary sizes for the nonce. This test vector uses an IV smaller than 12 bytes.

The counter for GCM is reduced modulo 2**32. This test vector contains values such that the GCM counter wraps around.

Known test vector.

GCM allows long IVs. Such IVs are compressed using GHASH to generate the CTR values. Some implementations restrict the range of the IV sizes.

The test vector contains a ciphertext with a modified tag. The test vector was obtained by manipulating a valid ciphertext. The purpose of the test is to check whether the verification fully checks the tag.

The test vector contains pseudorandomly generated inputs. The goal of the test vector is to check the correctness of the implementation for various sizes of the input parameters. Some libraries do not support all the parameter sizes. In particular the size of the IV is often restricted.

GCM leaks the authentication key if the same IV is used twice. Hence short IV sizes are typically discouraged or generated with a special construction such as the one described in Section 8.2 of NIST SP 800-38d. Some libraries may reject small IV sizes.

The test vector contains special cases for iv and tag.