Project Wycheproof

NIST SP 800 38f defines three keywrap primitives used for wrapping cryptographic keys. They all use a 6-round construction based on a strong pseudorandom permutation (W).

• KW (Key Wrap): Uses AES. Input size must be a multiple of 8 bytes. Defined in RFC 3394.
• KWP (Key Wrap with Padding): Uses AES. Adds padding to allow arbitrary length inputs. Defined in RFC 5649.
• TKW (TripleDES Key Wrap): Uses TripleDES. Input size must be a multiple of 8 bytes.

Note: For KWP, it is recommended to disallow keys of size 8 or smaller (wrappings of size 16 bytes) to avoid theoretical vulnerabilities related to the breaking of the strong pseudorandom property for small plaintexts.

Wycheproof provides documentation for understanding and using its test vectors. Use the following resources to navigate the project:

• Test Vector Availability: See files.md to find which test vectors exist.
• General Formats: See formats.md for the general structure of test vectors.
• Individual File Formats: See types.md for specific file formats. These are formally defined by JSON schemas located in the wycheproof/schemas directory.
• Bug Tracking: See bugs.md for a list of known bugs.

Wycheproof test vectors are provided in JSON format. The latest version (0.9) includes enhanced metadata such as links to CVEs, research papers, and classifications of potential bugs by type and effect.

Key Conventions:

• File Naming: Typically follows the pattern <algorithm>_<parameters>_test.json.
• JSON Structure: All files are valid JSON. The root object contains a "schema" field pointing to its corresponding JSON schema located in wycheproof/schemas/.
• Data Integrity: Headers and test groups are always well-formatted. Only the inputs within individual tests may contain malformed data.
• Key Formats: The testGroups header often provides keys in multiple formats to ensure compatibility with different libraries.

Wycheproof provides test vectors for a wide range of popular cryptographic algorithms to detect vulnerabilities like invalid curve attacks, biased nonces, and Bleichenbacher's attacks. Supported algorithms include:

• Symmetric Encryption/MAC: AEGIS, AES-EAX, AES-FF1, AES-GCM, AES-SIV, ARIA, ASCON v1.2, Camellia, ChaCha20-Poly1305, XChaCha20-Poly1305, KMAC, SM4, VMAC.
• Asymmetric/Key Exchange: DH, DHIES, DSA, ECDH, ECDSA, EdDSA, ECIES, RSA, X25519, X448, BLS-12-381, ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium).
• Key Derivation/Hashing: HKDF, HMAC, PBKDF2, SipHash.
• Other: Chunked encryption (Cobblestone), MORUS, SEED.

Wycheproof provides test vectors for three versions of the AEGIS cipher. Note that test vectors follow the specifications in [WuPre14] and the IETF draft, which may differ from earlier academic papers (e.g., AEGIS256 in some papers uses 6 rounds in finalize, whereas Wycheproof uses 7).

Supported versions:

• AEGIS128: A slower, more conservative version with a 128-bit key.
• AEGIS128L: A faster version with a 128-bit key.
• AEGIS256: A version using a 256-bit key.

RSA-OAEP is designed to prevent chosen ciphertext attacks. A correct implementation of RSA-OAEP prevents these attacks, whereas implementations of RSA-PKCS #1 v.1.5 cannot achieve the same property because they may be susceptible to attacks (like Manger's attack) if the caller leaks information about the decrypted ciphertext.

Note that the security of OAEP does not depend on collision resistance; therefore, using OAEP with SHA-1 does not pose a security risk.

FF1 is a format-preserving encryption (FPE) mode that encrypts short strings from a specific alphabet into strings of the same length using that same alphabet. For example, decimal digits ('0123456789') can be encrypted into other decimal digits (e.g., '8614187640').

FF1 is an instance of FFX and is standardized in NIST SP 800-38G.

Diffie-Hellman parameters must be carefully selected to avoid discrete logarithm attacks (like the special number field sieve) or trapdoors.

Best practices:

• Use predefined groups: Use well-known, standardized DH groups (e.g., RFC 3526) to avoid the risks associated with generating custom parameters.
• Avoid common misconfigurations: Ensure $p$ is prime (not composite), $p-1$ contains a large prime factor, and the generator $g$ is used correctly (not $q$).
• Check for weak primes: Be cautious of primes close to a power of two or those with smooth group orders.

When using an IV size other than 12 bytes, the initial IV is computed using GHASH. This can lead to counter overflows for messages longer than 16 bytes. If an implementation incorrectly handles CTR overflows (e.g., by reusing AES-CTR logic where counters increment modulo $2^{128}$ instead of modulo $2^{32}$), it can result in incorrect ciphertext and potentially leak the authentication key.

An attacker can exploit this by observing approximately 200-600 GB of data encrypted with the same key to derive the authentication key.

AEGIS does not allow nonce reuse. Reusing a nonce with the same key allows an attacker to recover the internal state of the cipher via a chosen ciphertext attack.

For AEGIS128, the internal state can be recovered in as few as 9 queries. For AEGIS128L, it can be recovered in as few as 7 queries. Once the state is recovered, an attacker can decrypt any ciphertext encrypted with that same nonce and key, and can also encrypt additional messages.