ML-KEM-512.

ML-KEM-768. This is the set TLS uses, on its own and as the lattice half of the hybrid groups.

ML-KEM-1024.

The three parameter sets of FIPS 203.

This is not an abstract KEM interface and does not try to be: it is the three sets FIPS 203 defines, closed, carrying their sizes and the calls into the implementation. Only the sizes are exported. If crypton grows a second KEM and an interface common to both is wanted, that belongs in a module of its own, with this as one of its instances.

A key encapsulation mechanism.

The three values are named for what they do rather than for what they are in any one algorithm. In ML-KEM the encapsulation key and the ciphertext are what the names say; in a Diffie-Hellman exchange both are public values of the group, and the "ciphertext" is the ephemeral one the encapsulating side generates. Keeping them apart in the types is what stops one being passed where the other belongs, which they are not interchangeable for even where they have the same representation.

Secret shared via key exchange.

Try to read an encapsulation key.

Beyond the length this runs the check of FIPS 203 section 7.2: the key must be the encoding of coefficients that are all in range, which is to say it must survive a decode and re-encode unchanged. A key that fails it is not one any honest party produced.

Try to read a decapsulation key.

Beyond the length this runs the check of FIPS 203 section 7.3: the hash of the encapsulation key the private key embeds must match the copy of that hash it also embeds. The two disagreeing means the key was not produced as a pair, and decapsulating with it would silently answer with the implicit rejection every time.

Try to read a ciphertext. Only the length is checked; every string of the right length is a ciphertext that decapsulate will answer.

Generate a key pair and hand back the seed it was derived from, d and z of FIPS 203 one after the other.

A DecapsulationKey is the expanded key and nothing else, so the seed cannot be recovered from a pair afterwards. An application that has to write the key out in a form that keeps the seed has to generate it here:

(ek, dk, seed) <- generateKeyPairAndSeed MLKEM768

The seed is as secret as the decapsulation key: keyPairFromSeed turns it back into the same pair.

Derive a key pair from a seed, which is d and z of FIPS 203 one after the other and must be seedSize bytes.

This is the entry point to use when the seed comes from somewhere particular -- a test vector, or a store that keeps seeds rather than expanded keys. For an ordinary key, generateKeyPair draws the seed itself.

Size in bytes of the seed keyPairFromSeed takes, which is d and z of FIPS 203 one after the other.

Size in bytes of the randomness encapsulateWith takes, m in FIPS 203.

Size in bytes of a SharedSecret.