ML-KEM Input Validation: Check Keys at the Boundary

DEV Community

ML-KEM input checks belong at the key boundary, not the ciphertext error path

ML-KEM input checks belong at the key boundary, not the ciphertext error path Post-quantum key exchange moves a new kind of object into ordinary application code. ML-KEM produces an encapsulation key, a ciphertext, and a shared secret. FIPS 203 requires input checking before encapsulation and decapsulation, but the checks are easy to place in the wrong layer when a library, protocol, or service owns only part of the operation. The standard gives concrete length checks. An encapsulation key has length 384k + 32 bytes. A decapsulation key has length 768k + 96 bytes. An ML-KEM ciphertext has length 32(d_u k + d_v) bytes. The decapsulation key also has a hash check over a defined portion of the key. These are type and integrity checks, not a claim that a key came from the correct peer or that a ciphertext came from the expected session. Check the key where it enters the trust boundary An application that receives an encapsulation key from a peer should check the bytes before calling Encaps. A gateway that imports a long-lived key should check it when the key is loaded. A protocol that carries a decapsulation key in a backup or configuration record should check it at import, even if the eventual decryption happens elsewhere. FIPS 203 permits the decapsulation key check to be performed by another party or outside every decapsulation call, if the component has other assurance that the check occurred. That flexibility is useful for hardware and validated modules. It is not permission to pass an unchecked byte string through an application boundary and assume some later component will repair the state. Do not make the error path an oracle ML-KEM decapsulation is designed to produce a shared secret for a validly encoded but incorrect ciphertext. That behavior limits the value of treating every failed key exchange as a simple authentication error. Code should not turn timing, logs, error codes, or returned key material into a public validity signal. Length failures and malformed inputs should be rejected locally with a fixed error path. A valid-length ciphertext that does not authenticate the peer should end the protocol at its authentication layer. The KEM does not establish peer identity by itself, and a successful shared secret does not prove that the sender is authorized. Record the KEM parameter set with every stored key and ciphertext. ML-KEM-512, ML-KEM-768, and ML-KEM-1024 have different lengths. A parser that infers the parameter set from input size must reject ambiguous or truncated values before arithmetic. Test the maximum length, zero length, off-by-one length, and a valid-length key with a failed hash check. Keep an inventory of the boundary A useful review asks who generates each key, who checks it, who stores it, and who can replace it. It should identify every protocol that carries an encapsulation key and every format that carries a private key. For each path, verify the library version, approved parameter set, input checking, error handling, and test coverage. Hybrid deployments need the same care. A negotiated group name may select ML-KEM in one stack and a hybrid construction in another. Store the selected group, the exact key encoding, and the version of the combining logic. Do not compare opaque keys by display label. FIPS 203 provides a precise algorithm and input contract. The deployment still has to decide where that contract begins. Put the length and hash checks at the boundary that admits the bytes, keep authentication above the KEM, and test the failure paths as carefully as the happy path. References NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms

Powered by Readybot.io