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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

How about making authentication implicit? Like, using the Kyber key pair to establish a shared key with the CA, who in turn will encrypt with it the outgoing stuff, e.g., certificate? And, offhand, the key owner would MAC the revocation request?

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: CFRG <[e-mail]> on behalf of Mike Ounsworth <Mike.Ounsworth=[e-mail]>
Date: Friday, November 25, 2022 at 12:47
To: "Kampanakis, Panos" <kpanos=[e-mail]>
Cc: CFRG <[e-mail]>
Subject: Re: [CFRG] How will Kyber be added to HPKE (9180)?

 

Hey Panos,

 

Yes, CMP does those. Those cases are fairly straight-forward to port to KEMs.

 

Here we’re considering, for example, when a client (aka a certificate holder) sends a request to request, renew, or update the key in its certificate. Those requests are authenticated with the certificate in question.

 

rfc4210#section-5.1.3 describes three message integrity protection modes:

 

- PasswordBasedMac

- DHBasedMac

- Signature

 

I believe if you have an RSA key marked with keyUsage:keyEncipherment then you just cheat and sign with it anyway.

 

The answer seems to be that to do a KyberBasedMac, we need an extra round trip (possible separate HPKEs in each direction?). That would add an extra round-trip compared to the three message integrity mechanisms above, but since revocation / renewal are infrequent operations, probably that’s fine? 

 

Anyway, we’ll go off and design and Hendrik will present it to LAMPS with his next CMP Updates update.

 

---

Mike Ounsworth

 

From: Kampanakis, Panos <kpanos=[e-mail]> 
Sent: November 25, 2022 11:09 AM
To: Mike Ounsworth <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] RE: [CFRG] Re: 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.

Do you need an AKEM for CMPv3 Mike?

I think CMP was using implicit POP by encrypting (no auth involved) the returned cert to the recipients public key. HPKE could provide that in its base mode (only encryption) using ECDH, Kyber or ECDH+Kyber KEMs. 

Do you want to auth the issuing CA or do you want to use HPKE in another context for CMPv3? 

 

 

From: CFRG <[e-mail]> On Behalf Of Mike Ounsworth
Sent: Thursday, November 24, 2022 12:44 PM
To: Karthik Bhargavan <[e-mail]>
Cc: [e-mail]
Subject: RE: [EXTERNAL][CFRG] [EXTERNAL] Re: How will Kyber be added to HPKE (9180)?

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

Thanks Karthik, John, Neil, and Ilari,

 

CMP is its own crypto protocol, independent from TLS, IKEv2, QUIC, etc. It does have an over-HTTPS mode (RFC 6712), but that does not replace the need for CMP messages to be internally authenticated. We are not looking to re-design CMP, but simply to add Kyber-based message protection modes to the list of already supported modes.

 

I think I have learned from this thread that we are indeed looking for (or at least can tolerate) an “interactive Kyber Authenticated Key Exchange (AKE)”, and that HPKE will not provide it.

 

Thank you all for your input!

 

---

Mike Ounsworth

 

From: Karthik Bhargavan <[e-mail]> 
Sent: November 24, 2022 10:17 AM
To: Mike Ounsworth <[e-mail]>
Cc: Neil Madden <[e-mail]>; Ilari Liusvaara <[e-mail]>; [e-mail]
Subject: 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=[e-mail]> 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 <[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]> 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
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg