kem: Scheme.DeriveKeyPair length check too strict about circl

[emersion]

Actually, a >= check wouldn't be enough for MLS: the official test vectors pass a 64-byte seed to KEM_P521_HKDF_SHA512 (which has SeedSize of 66). We'd need to drop the checks entirely.

[armfazh]

In Section 7.4, MLS, DeriveKeyPair is called with node_secret, which is the output of DeriveSecret

node_secret[n] = DeriveSecret(path_secret[n], "node")
node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n])

Looking at the definition of DeriveSecret in Section 8, MLS, it outputs KDF.Nh bytes.

DeriveSecret(Secret, Label) =
    ExpandWithLabel(Secret, Label, "", KDF.Nh)

There is a mismatch between KDF.Nh and KEM.Nsk only in the following MLS suites:

MLS ID	MLS Suite	KDF.Nh	KEM.Nsk
0x04	MLS_256_DHKEMX448_AES256GCM_SHA512_Ed448	64	56
0x05	MLS_256_DHKEMP521_AES256GCM_SHA512_P521	64	66
0x06	MLS_256_DHKEMX448_CHACHA20POLY1305_SHA512_Ed448	64	56

@emersion , I recommend you to reach the MLS authors to seek guidance, this could be a typo in the spec.

[emersion]

Good idea. I've sent an email to the mailing list: https://mailarchive.ietf.org/arch/msg/mls/JdrJvjGnVjNHX1xE4kTcsmq_PRc/

[bwesterb]

The kem.Scheme interface isn't meant to match up precisely with HPKE. Its DeriveKeyPair function is meant to match up exactly with the natural key derivation. HPKE's derivation can be built on top of that, eg. as in X-Wing. I think we might want to add a separate interface for HPKE key derivation.

[bwesterb]

Also the

For a given KEM, the ikm parameter given to DeriveKeyPair() SHOULD have length at least Nsk, and SHOULD have at least Nsk bytes of entropy.

requirement is problematic for PQ KEMs, which have large secret keys, and is ignored. This requirement is very much written thinking only of elliptic curves.