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

[Mike Ounsworth <[e-mail]>]

Thanks Neil.

But wouldn't that require the client to have a long-term signature key? That is not our case; we need to derive MAC keys in cases where both client and server have Kyber certificates.

The general question of "how" is out-of-scope here; I'm just trying to ask if this is possible with RFC9180 + some future extension to support Kyber.

---
Mike Ounsworth

From: CFRG <[e-mail]> On Behalf Of Neil Madden
Sent: November 24, 2022 10:01 AM
To: Ilari Liusvaara <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [CFRG] How will Kyber be added to HPKE (9180)?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________

On 24 Nov 2022, at 15:36, Ilari Liusvaara <[e-mail]<mailto:[e-mail]>> wrote:

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.

Isn't there a straightforward generic construction of an AKEM from a normal KEM plus a (PQ) signature scheme that could be used here? i.e., run the KEM and then sign the encapsulated key? Obviously this would produce quite large encapsulations, and a "key-pair" for such an AKEM would then be two key-pairs encoded into one (with a covering self-signature to prevent tampering). In principle this seems doable?

-- Neil
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.