[CFRG] Re: ML-KEM for HPKE: just use seeds

[John Mattsson <[e-mail]>]

>And the only thing this really requires beyond FIPS 203 is that the 64-byte decapsulation key format is a MUST, which >is in alignment with other ML-KEM work in IETF right now (such as lamps-kyber-certificates)

Seems good to me. Good that the 64-byte decapsulation key format is a MUST. But I am not sure the following should be a MUST.

   “that is by freshly sourcing 32 random bytes for d and then freshly
   sourcing another 32 random bytes for z from a FIPS-approved RBG.”

I think the correct way to do this is to derive everything from a 32 byte seed as discussed here.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/2EWXvBaE-Yw/m/bMyO7B-fAwAJ

Would it be possible to discuss and allow this?

Cheers,
John

From: Deirdre Connolly <[e-mail]>
Date: Wednesday, 6 November 2024 at 11:16
To:
Cc: CFRG <[e-mail]>
Subject: [CFRG] Re: ML-KEM for HPKE: just use seeds
As per the meeting today, just re-surfacing this for the group:

https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/04/

and if there's good vibes, I'll go request the codepoints:

0x40 - ML-KEM-512
0x41 - ML-KEM-768
0x42 - ML-KEM-1024

And the only thing this really requires beyond FIPS 203 is that the 64-byte decapsulation key format is a MUST, which is in alignment with other ML-KEM work in IETF right now (such as lamps-kyber-certificates)

On Mon, Oct 14, 2024 at 9:58 PM Deirdre Connolly <[e-mail]<mailto:[e-mail]>> wrote:
With help from Rohan, we have pushed version -03, which removes the confusing language about KDFs and AEADs and chooses different codepoints in the HPKE KEMs Registry (now 0x0040, 0x0041, and 0x0042):

https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/03/

There are some todo's to complete on making the explicit mapping between FIPS 203 and RFC 9180 functions concrete and some references that should be done by the 121 deadline.

On Sun, Oct 13, 2024 at 11:47 AM Deirdre Connolly <[e-mail]<mailto:[e-mail]>> wrote:
Yes you are correct - I was thinking I was registering a whole 'HPKE' ciphersuite which is incorrect, this is just for the KEM, which is fully described by FIPS 203 and doesn't need the extra KDF and AEAD definitions, I'll be removing that text.

On Sat, Oct 12, 2024, 5:56 AM Rohan Mahy <[e-mail]<mailto:[e-mail]>> wrote:
Apologies for my hasty response on too little sleep.

After skimming FIPS203 again, it looks like the hash function is fully specified, so just deleting the paragraph about KDFs and AEAD seems best to me.

And NSecret is indeed always 32. It might be worth a note so readers less familiar with ML-KEM don't think it is a typo.

Thanks,
-rohan

On Sat, Oct 12, 2024, 02:23 Rohan Mahy <[e-mail]<mailto:[e-mail]>> wrote:
Hi Dierdre,
Thanks very much for getting this out. My main technical concern is this paragraph, which does not provide a clear mapping of ML-KEM size to its KDF, and muddles cipher suite definition with KEM definition:

We use HKDF-SHA256 and HKDF-SHA512 as the HPKE KDFs and AES-128-GCM and AES-256-GCM as the AEADs for ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

Please define the specific KDF to use clearly in text or in a table. (I think we can leave AEAD out of this.) I heard much talk of using ML-KEM-768 for the 128-bit and 192-bit security levels. Should we have 3 or 4 definitions for HPKE KEM?
ML-KEM-512 (SHA256) for ??
ML-KEM-768 (SHA256) for 128?
ML-KEM-768 (SHA384) for 192
ML-KEM-1024 (SHA512) for 256

Regarding the IANA registration section, it requests 0x0512, 0x0768, and 0x1024. Please don't. 0x0040, 0x0041, etc would be much better. Is NSecret really only 32 for all three KEMs? I would have guessed these increased to 48 and 64.

I'll propose an editorial PR soon, but these are my only substantive issues.
Thanks,
-rohan