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

[Orie Steele <[e-mail]>]

[as an individual]

Hello hybrid (not the PQ/T kind) enthusiasts,

We've been working to align the algorithms and key expressions needed for
HPKE in JOSE and COSE:

- https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/
- https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt-07
- https://datatracker.ietf.org/doc/draft-steele-jose-cose-hpke-cookbook/

Based on my experience implementing "HPKE-Base-P256-SHA256-AES128GCM".
I attempted to implement "HPKE-Base-ML-KEM-768-SHA256-AES128GCM"
I was able to produce the following EDN from my experimental implementation:

16([
  / protected / <<
    / algorithm / 1 : -777777 / HPKE-Base-ML-KEM-768-SHA256-AES128GCM /
  >>,
  / unprotected / {
    / key identifier /    4:
"urn:ietf:params:oauth:ckt:sha-256:QcJhXe4j82YETvLzXQ5pXDtin541byZup5l0WuSC820",
    / encapsulated key / -4: h'f161ea5a094a55b21...6ae13e7e43613f'
  },
  / ciphertext / h'f224bd528704969d0ad5...6d0d27121a67e808c'
])

A couple comments and suggestions, spanning several drafts adopted and
unadopted in CFRG, JOSE and COSE.

## JOSE HPKE should use new header params not new key types.

@Ilari Liusvaara <[e-mail]> is correct that a new header
parameter ( ek / -4 ) is a better approach then what I have previously
implemented for JOSE, using { epk : { ek } }.

JOSE HPKE should drop the registration requests related to new kty: epk, ek
: enc.
JOSE HPKE should adopt the COSE convention of passing "encapsulated keys"
or "kem cipher texts" as header parameters.
This became more obvious to me, only after seeing how PQ Kem based HPKE
envelopes will look.
I've changed my mind, and I agree with the arguments Ilari has patiently
made for the past several months : )

## KEM vs HPKE KEM

I based my HPKE KEM implementation on ML-KEM-768 in
https://github.com/paulmillr/noble-post-quantum
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.

Currently the registry implies that "X25519Kyber768Draft00" (0x0030) is the
only interoperable KEM that has any QR (Quantum Resistance).
I would like to test HPKE ML-KEM-768 with HKDF-SHA256 and AES128GCM,
without needing to implement a PQ/T hybrid KEM.

Regards,

OS

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>