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

[Deirdre Connolly <[e-mail]>]

I have now put in this request 💃

On Wed, Nov 6, 2024 at 10:43 AM Nick Sullivan <[e-mail]>
wrote:

> 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]
>>
>