[jose] Re: [EXTERNAL] Re: HPKE and diminishing returns

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 19 June 2024 15:29 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A4DBAC16941B for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 08:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jlTODAKVgExi for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 08:29:40 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E389C15792A for <jose@ietf.org>; Wed, 19 Jun 2024 08:29:38 -0700 (PDT)
Received: from localhost (localhost []) by welho-filter2.welho.com (Postfix) with ESMTP id 5C9DF46D7F for <jose@ietf.org>; Wed, 19 Jun 2024 18:29:36 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:]) by localhost (welho-filter2.welho.com [::ffff:]) (amavisd-new, port 10024) with ESMTP id xNmihz8dtK1T for <jose@ietf.org>; Wed, 19 Jun 2024 18:29:36 +0300 (EEST)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1D2E5230A for <jose@ietf.org>; Wed, 19 Jun 2024 18:29:34 +0300 (EEST)
Date: Wed, 19 Jun 2024 18:29:34 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: JOSE WG <jose@ietf.org>
Message-ID: <ZnL5XmfTebPSltSE@LK-Perkele-VII2.locald>
References: <762F63AC-D5B7-4C07-AE44-29BDA6F1077C@gmail.com> <CA+k3eCRez+M4NAH=OqPfciHV4geAXiSn7AnrmUqdFwNVrXt6XA@mail.gmail.com> <Zm2NfyM_XcQZBswu@LK-Perkele-VII2.locald> <CAN8C-_+i4aEFvAFENmyJTzK-b2u_14hpBDeOGi1Nx6cCMyKxDA@mail.gmail.com> <CA+k3eCQo_NhKbZvKqc=rSCL8a8Jaj2PziQaxUriBV35cqE4a+g@mail.gmail.com> <CH0PR11MB573955429ADF7F9516A95DF19FCD2@CH0PR11MB5739.namprd11.prod.outlook.com> <ZnF1UfCv9iGrcwWr@LK-Perkele-VII2.locald> <CAFpG3geuPFMPMJdeD9yz=CxMgviZN7Nk=r8LfECDmBRhQk1+TA@mail.gmail.com> <ZnGn7eI6dKpfEUVA@LK-Perkele-VII2.locald> <CAFpG3gcT95i0DD11dUW37TN9ucfQVzYxMEkE8okiuFPzZAR=7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFpG3gcT95i0DD11dUW37TN9ucfQVzYxMEkE8okiuFPzZAR=7w@mail.gmail.com>
Sender: ilariliusvaara@welho.com
X-MailFrom: ilariliusvaara@welho.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: [EXTERNAL] Re: HPKE and diminishing returns
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/pqu87BUdz6JXtjHyFyCFKMQRYtc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

On Wed, Jun 19, 2024 at 05:00:09PM +0530, tirumal reddy wrote:
> On Tue, 18 Jun 2024 at 21:02, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> > Hybrid KEMs do not introduce the same complexities as HPKE:
> >
> HPKE has the advantage of integrated key management to handle the
> combination of the shared secrets to derive the final secret, utilizing a
> KDF at the required strength, and ensuring the appropriate security levels
> to combine traditional and post-quantum cryptography (PQC).
> What makes leveraging HPKE complex compared to native Hybrid KEM support in
> JWE?

The thing that makes HPKE complicated to integrate is that it also
performs symmetric encryption.

JOSE (and COSE) already has KDF in order to handle ECDH-ES. And proper
hybrid KEM (e.g., X-Wing) already handles combining traditional and
post-quantum cryptography.

> > > In both cases, a new parameter would have to be defined to carry
> > > the KEM ciphertext.
> >
> > New parameter is trivial to add.
> The new parameter will not be integrity protected but in the case of JWE
> compact serialization it must be integrity protected.

There is no need to integerity protect the encapsulated key unless using
some bad KEMs with PSK.

And also, if there was some requirement for integerity protecting it,
then the whole thing would be broken, because it can not be protected
with multiple recipients.

> > I had designs like this a while back. I think HPKE-Base-P256-SHA256 can
> > be regarded as Direct Key Agreement. Which would make
> > HPKE-Base-P256-SHA256-A128KW Key Agreement with Key Wrapping.
> >
> Yes.

Idea that is bit odd but should technically work would be to use
Direct Key Agremeent and Key Encryption.

As constructing Key Encryption from HPKE is easier than constructing
Key Agreement with Key Wrap out of HPKE.

Yes, it is not symmetric, but there are going to be all sorts of
differences anyway.

> > This design is compatible with oneshot API (all designs using existing
> > modes are).
> >
> The design is not compatible with oneshot API in case of compact
> serialization, it creates a cyclic dependency (encapsulated key will have
> to be integrity protected).

ECDH-ES also uses headers in key agreement step, and works just fine
with compact serialization.

Key agreement operation occurs before committing protected headers,
which occurs before bulk encryption.

> > One small issue with this is that enc gets base64-url encoded twice,
> >
> The overhead of base64url encoded twice is only applicable to compact
> serialization, it is the same problem with Hybrid KEM or Pure PQ KEM (e.g.,
> ML-KEM) where the KEM ciphertext will have to be base64url encoded twice.

Yes, native KEMs also double-encode, unless doing weird stuff with