crypto/mlkem: Encapsulate has wrong order of secret and ciphertext

[tmthrgd]

Go version

go1.24rc1

Output of go env in your module/workspace:

N/A

What did you do?

Used the new crypto/mlkem package from go1.24 (#70122).

What did you see happen?

Noticed that the signature for Encapsulate is Encapsulate() (ciphertext, sharedKey []byte) with ciphertext first and sharedKey second.

What did you expect to see?

As per FIPS 203, the order should be "shared secret key" first and "ciphertext" second:

Algorithm 20 ML-KEM.Encaps(ek)
Uses the encapsulation key to generate a shared secret key and an associated ciphertext.
Checked input: encapsulation key ek ∈ 𝔹384𝑘+32 .
Output: shared secret key 𝐾 ∈ 𝔹32 .
Output: ciphertext 𝑐 ∈ 𝔹32(𝑑𝑢𝑘+𝑑𝑣).
1: 𝑚 ←$− 𝔹32					▷ 𝑚 is 32 random bytes (see Section 3.3)
2: if 𝑚 == NULL then
3: 	return ⊥				▷ return an error indication if random bit generation failed
4: end if
5: (𝐾, 𝑐) ← ML-KEM.Encaps_internal(ek, 𝑚)	▷ run internal encapsulation algorithm
6: return (𝐾, 𝑐)

Because both return types are []byte (so you don't get the type system to help you tell them apart), this seems like a potentially dangerous footgun and unfortunate divergence from the published spec. I also imagine any potential crypto.KEM API is going to want secret first. I think the order should be swapped to match FIPS 203 before go1.24 is released.

For reference, RFC 9180 (HPKE) also specifies it's KEMs to return secret first.

Note: It seems like the original pre-NIST Kyber spec (from round 3) did have the ciphertext first, see #70122 (comment).

[gabyhelp]

Related Issues

• crypto/mlkem: new package #70122 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mateusz834]

Marking as a release blocker, see #70122 (comment).

CC @FiloSottile

[dr2chase]

@rolandshoemaker