[CFRG] Re: PQ HPKE in JOSE and COSE with ML-KEM-768, HKDF-SHA256, AES128GCM

[Orie Steele <[e-mail]>]

If I'm reading the pqc-forum correctly, the domain separation applies to
KeyGen only (which is before HPKE).

Meaning that the parts of test vectors after KeyGen would remain unchanged?

Or are you suggesting there will be HPKE ML-KEM domain separation from
regular ML-KEM?

I'm mostly interested in what parts of HPKE ML-KEM will change, assuming
ML-KEM is a black box that will eventually become immutable.

Ideally, I'd be able to confirm compatibility, prior to the keygen domain
separation being added to FIPS 203 and FIPS 204.

Also, I'm prototyping with TypeScript because that's what's easiest for me
to generate examples for drafts.

I agree with all the normal cautions about doing crypto in javascript.

Regards,

OS

On Tue, May 28, 2024 at 7:31 AM Bas Westerbaan <[e-mail]> wrote:

> Some replies inline.
>
> I based my HPKE KEM implementation on ML-KEM-768 in
>> https://github.com/paulmillr/noble-post-quantum
>>
>
> A word of caution that this implementation is not constant time. (It's
> very difficult in javascript anyway, but a warning is in place.)
>
>
>> This meant I needed to address both the HPKE and COSE / JOSE related
>> context issues myself.
>> It was not obvious to me exactly how to do this.
>> Especially since there is no registry entries for ML-KEM in:
>> https://www.iana.org/assignments/hpke/hpke.xhtml
>> The answer appears to be in this draft:
>> https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-hpke-mlkem-00#name-encap-and-decap
>> I've done my best to follow the draft, in my experimental implementation.
>>
>> Are there implementations of HPKE out there using kem id 0x0070?
>>
>> Are we waiting on some final confirmation from NIST to add 0x0070 to
>> https://www.iana.org/assignments/hpke/hpke.xhtml ?
>> I can understand not wanting to burn a code point.
>>
>
> ML-KEM is not final yet. What people call ML-KEM now is typically the
> "ipd", the initial public draft. HPKE KEMs test vectors typically include
> deterministic key generation, and it seems likely [1]  that that will
> change for the final version of ML-KEM.
>
> Best,
>
>  Bas
>
> [1]
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/5CT4NC_6zRI/m/KyFx0sapAgAJ
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>