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

[Nick Sullivan <[e-mail]>]

As a reminder, the IANA registration process for HPKE
<https://www.iana.org/assignments/hpke/hpke.xhtml> is "Specification
Required <https://datatracker.ietf.org/doc/html/rfc8126#section-4.6>,"
meaning that only a stable public reference (such as an I-D) and a review
by the designated experts are required to obtain a code point.

Best,
Nick



On Wed, Nov 6, 2024 at 10:26 AM John Mattsson <john.mattsson=
[e-mail]> wrote:

> >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]>
> 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]> 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]> 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]> 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
>
>
>
>
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>