[DNM] Add ML-KEM (FIPS 203). #470
Conversation
ML-KEM is not final yet, so this implementation isn't final either. We keep Kyber around (for now) as it's currently widely deployed. Code differences between them are minimal anyway.
| @@ -143,6 +151,9 @@ func (pk *PublicKey) EncapsulateTo(ct, ss []byte, seed []byte) { | |||
| // c = Kyber.CPAPKE.Enc(pk, m, r) | |||
| pk.pk.EncryptTo(ct, m[:], kr[32:]) | |||
There was a problem hiding this comment.
While at it, maybe we can use a name for this constant. This matches the type of K in the Algorithm 16 from FIPS 203 ("derive shared secret K and randomness r") and is consistent with your other use of kr[:SharedKeySize] below.
| pk.pk.EncryptTo(ct, m[:], kr[32:]) | |
| pk.pk.EncryptTo(ct, m[:], kr[SharedKeySize:]) |
There was a problem hiding this comment.
This is accidental, and that 32 is not the shared key size.
There was a problem hiding this comment.
I am not following.
My understanding is that the first part of kr is the shared secret key. So kr[SharedKeySize:] would skip the shared secret key, and refer to the remaining part, r.
Output: shared key K ∈ B32
(K, r) ← G(m ∥ H(ek)) ▷ derive shared secret key K and randomness r
c ← K-PKE.Encrypt(ek, m, r) ▷ encrypt m using K-PKE with randomness r
There was a problem hiding this comment.
In Kyber the first 32 bytes does not contain the returned shared secret, but an intermediate key that happens to be 32 bytes as well.
There was a problem hiding this comment.
In that case, what about replacing kr[:SharedKeySize] by kr[:32] to avoid that implication?
Thanks. Addressed. |
ML-KEM is not final yet, so this implementation isn't final either.
We keep Kyber around (for now) as it's currently widely deployed. Code differences between them are minimal anyway.