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

HPKE is designed as a one-shot construction, whereas Figure 3 of the Kyber
[2018] paper is an interactive two message key-exchange protocol.
So HPKE will not fit your needs if this two-message protocol is what you
require.
KEM-TLS using Kyber may be closer to what you need, if it gets standardized
(https://kemtls.org/)

-Karthik

On Thu, Nov 24, 2022 at 5:04 PM Mike Ounsworth <Mike.Ounsworth=
40entrust.com@dmarc.ietf.org> wrote:

> 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 <cfrg-bounces@irtf.org> *On Behalf Of * Neil Madden
> *Sent:* November 24, 2022 10:01 AM
> *To:* Ilari Liusvaara <ilariliusvaara@welho.com>
> *Cc:* cfrg@irtf.org
> *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 <ilariliusvaara@welho.com>
> 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.*
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>