Last week, NIST published the final version of the ML-KEM[1] specification, FIPS 203. One change from the draft is that the final document explicitly allows storing the private decapsulation key as a seed. This is a plea to the cryptography engineering community: let's all agree to only use seeds as the storage format of ML-KEM keys, and forget that a serialized format for expanded decapsulation keys even exists. Seeds have multiple advantages. The most obvious is size: a seed is 64 bytes, while an expanded decapsulation key is 1 632, 2 400, or 3 168 bytes depending on the ML-KEM parameter set. More importantly, though, a 64-byte seed is always valid, while an expanded decapsulation key needs to be validated. FIPS 203, Section 7.3, requires the following check H(dk[384𝑘 : 768𝑘 + 32])) == dk[768𝑘 + 32 : 768𝑘 + 64] to ensure two parts of the input key are consistent: the pre-computed hash of the encapsulation key, and the encapsulation key itself. That's not all, though. The decapsulation key expanded format is ByteEncode₁₂(s) || ByteEncode₁₂(t) || ρ || H(ekPKE) || z where s and t are vectors of NTT elements. An NTT element is in turn a vector of field elements, and a field element is a number between zero and 3 329, encoded as a 16-bit integer. What if an encoded field element is higher than 3 329? It's invalid! What then? Well. If you find one in an encapsulation key you are required to reject it by FIPS 203, Section 7.2. But what if you find it in the encapsulation key…Read More