Re: [CFRG] How will Kyber be added to HPKE (9180)?

[Ilari Liusvaara <[e-mail]>]

On Thu, Nov 24, 2022 at 02:49:33PM +0000, Mike Ounsworth wrote:
> Hi CFRG!
> 
> Background: we are working to add KEM support to Certificate
> Management Protocol v3 (CMPv3) (draft-ietf-lamps-cmp-updates, which
> will eventually be 4210bis). We are planning to accomplish this by
> supporting HPKE (RFC 9180) as a new message protection mechanism in
> CMPv3 and hoping that we can inherit Kyber more-or-less for free once
> HPKE supports it.
> 
> Question "how": How will Kyber be added to HPKE? I assume there will
> be an equivalent to section 4.1 that defines KyberKEM with its own
> Encap(pkR), Decap(enc, skR), AuthEncap(pkR, skS), and
> AuthDecap(enc, skR, pkS) - ie the same interfaces as for DHKEM (4.1),
> but making use of Kyber internally? The Kyber2018 paper [1] figure 3
> defines an authenticated Kyber exchange that looks like it should
> easily fit into the existing HPKE APIs. In other words, will
> supporting 9180 now with abstractions around those 4 functions allow
> for easy drop-in of Kyber later?

Kyber does not support AuthEncap/AuthDecap. The whole reason why Auth*
interfaces is optional is to allow for KEMs that do not allow non-
interactive authentication, like the post-quantum ones.

In fact, the only possibly-PQC algorithm to support AuthEncap/AuthDecap
is CSIDH (not to be confused with totally broken SIDH/SIKE), and
security of that in both classical and quantum settings is subject to
debate.

I guess whatever authentication referenced in that paper is interactive
authentication, which is not possible to use in HPKE.


> Question "when": is there already a draft in the pipeline for
> adoption? When do you expect RFC publication? Presumably not before
> NIST final Kyber spec?

AFAIK, there is no draft yet.

However, the relevant registry is "specification required", not
"rfc required", so publication of RFC is not a precondition. And
while I do not know about HPKE, I think at least some registeries
interpret that I-D is sufficiently stable documentation to clear the
bar (and such interpretation is not unjustified).

And technically it would be possible to reference the pre-standard
Kyber version 3.02 (sic) to get some codepoints registered, even if
those codepoints will probably be incompatible with the eventual
final Kyber standard.



-Ilari