Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-00.txt

Frederic Jacobs <> Tue, 13 August 2019 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEB9012018B for <>; Tue, 13 Aug 2019 06:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=b0ygZYR0; dkim=pass (2048-bit key) header.b=R1eYLqji
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id abmmwH5PN7BN for <>; Tue, 13 Aug 2019 06:41:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFD9112018D for <>; Tue, 13 Aug 2019 06:41:06 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2028F22033; Tue, 13 Aug 2019 09:41:03 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute6.internal (MEProxy); Tue, 13 Aug 2019 09:41:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=from:message-id:content-type:mime-version :subject:date:in-reply-to:cc:to:references; s=fm1; bh=tAc66llVl4 Xc9qQr1BQr6Ry82YbFtKe5eoqc3YDt9gQ=; b=b0ygZYR0PJt1Mq0SZlQtipNYiJ T4kjWjSuw4uVi8sz38dKiQCxj/ZB8f2HeL9TG2YEsbedGkPc+IovriRLLzE91UZV 8hNIYzm647DdKo/pDgNafH4tYEKM/2RM0zazpZcNMU5P6KS+mZY1eVn0Dj29WRM2 TD98XOUciyaSKFyzTVuQTessfTNgFOCv3ugoMowKAYl36xOmtds/WQhMPICi/Ga4 6JxAGIrda9ia5gIlH9M6bp5qazt77/Rhg0544EevvVmFoh59GufpgTuqEeXdr/+i x/iZiYR2PIjOEWoatzi5L4YEXoScuv+J8+bPAlgamrND9Bk64wQQPSI57rwQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tAc66l lVl4Xc9qQr1BQr6Ry82YbFtKe5eoqc3YDt9gQ=; b=R1eYLqjipmw9Qs5MwpUnq/ 6tKqsu2HEJIuI3HWe7PlKDoM1rU4yn8qHq9LRqclhdtwC0lgJF9DUYxilFhfJfJQ TkSau8LCbr4kkhiYfUNqbUbk493CKS9XjZx/WBtSdZv/4BKKTQITx9nO7162d/Pl zekO8Asf38NeSs+xFmt3vMKAaXGyyOZkE0KUK8fPq0lbDTy5UUrdomB7OHKWeGJ/ rBQVSifGTzdPnGggd+VJOE+7jkHYi41rhqP8txEnlstHtUcgJcBamthmJL0Rtkqp U1grxZTGigi45vyVJ9RS0EJ8naiHnagfCu8ijwIibzJZpN1wMnWhscTvpwPcCX/Q ==
X-ME-Sender: <xms:7r1SXap9aimpsfbq9wtDiq8YlC2sGhX2Ar_WeaT717eQmHVe_NFriw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddviedgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhkfgtggfuffgjvfhfofesrgdtmh erhhdtjeenucfhrhhomhephfhrvgguvghrihgtucflrggtohgsshcuoehlihhsthhssehf rhgvuggvrhhitghjrggtohgsshdrtghomheqnecuffhomhgrihhnpehirhhtfhdrohhrgh dpihgvthhfrdhorhhgnecukfhppeekfedrjeeirdegjedrvdehvdenucfrrghrrghmpehm rghilhhfrhhomheplhhishhtshesfhhrvgguvghrihgtjhgrtghosghsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:7r1SXexBJS8QD3jLcJKueKsxJwFvp0nhgMdazys8llOOBKCvgGmHaQ> <xmx:7r1SXUzBYqSHftO_xzG2SOeuUT4dLtEWcza1q2Aa4I1yDvTCOEAnYA> <xmx:7r1SXdQy7Betc_zsY3JElPm8H2fuZ8B-6cOhQL7LTXn7WLplxHx1sA> <xmx:771SXYPp1JJEchD9ODciNkn8iFIzVS6WDC23Fa-_F90CRR6QMBoQgA>
Received: from imac-pro.home ( []) by (Postfix) with ESMTPA id 1645C8005B; Tue, 13 Aug 2019 09:41:02 -0400 (EDT)
From: Frederic Jacobs <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D39F2924-D7BF-4A7F-9A41-AF437879C5D1"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\))
Date: Tue, 13 Aug 2019 15:40:58 +0200
In-Reply-To: <>
To: Richard Barnes <>
References: <> <>
X-Mailer: Apple Mail (2.3578.1)
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Aug 2019 13:41:10 -0000

Hello Richard,

I read it over the weekend and had the following feedback.

- Double “the”: "The the shared secret produced by the KEM is combined via the KDF with information describing the key exchange, as well as the explicit info parameter provided by the caller.”
- I assume this was supposed to be “authenticated”: Authentication Encryption with Associated Data (AEAD) Functions

Technical feedback:
- I’ve noticed that in a previous draft, you had ciphersuites defined that are no longer in this version of the document. However, you still refer to a ciphersuite identifier in the context octet string definition:
 context = concat(mode, ciphersuite, enc, pkRm, pkIm,
                      len(pskID), pskID, len(info), info)
I assume this becomes the concatenation of the KEM, KDF, Cipher 2-byte values?

- Some of the example use-cases are examples where the size of the payloads should be minimal. With some standards (eg. 3GPP), the use of NIST-curves  is very important. For those cases, could the compact key representation <> be considered?

- About the info string, in a previous document it was defined as opaque info<0..255>, which now has been changed to opaque info<0..2^16-1>. While I think being able to take longer info, I’m not sure why it’s meant to persist like that in the HPKContext and from an implementation perspective, having a variable-length info buffer complicates things (eg. specifying length in octet string). Implementation-wise I think that just taking an arbitrary info argument and hashing it using the hash function underpinning the key derivation function (or eventually just KDF’ing it) to Nh bytes would make more sense and simplify edge cases in implementation.

- As it currently stands, the RFC doesn’t define a wire format for the payloads. While I think that leaving that possibility is important for adoption in different use cases, it could be useful to define a standard way of concatenating for instance the enc || encryptedPayload and have that in the spec. Optionally defining Elligator-style encoding of the enc to make HPKE payloads less distinguishable.

It’s great to (finally!) see an RFC on interoperable ECIES implementations.



> On 4 Jul 2019, at 13:28, Richard Barnes <> wrote:
> Hi folks,
> After our presentation in Prague and an adoption call on this mailing list, I'm happy to say that we have posted draft-irtf-cfrg-hpke-00. 
> This version has a couple of notable changes from the last individual draft:
> - The "setup" logic across the various modes has been united into a single algorithm
> - As a result, we added a "PSK + Auth" mode, where the sender is authenticated to hold both a PSK and an asymmetric key
> - Instead of one monolithic ciphersuite, individual algorithms are signaled independently
> In addition, there were a bunch of clarifications and bugfixes thanks to Dave Cridland.
> We've asked the chairs for some time to discuss this draft in Montreal, so please take a look and let us know what you think!
> Thanks,
> --Richard
> On Thu, Jul 4, 2019 at 6:09 AM < <>> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Crypto Forum RG of the IRTF.
>         Title           : Hybrid Public Key Encryption
>         Authors         : Richard L. Barnes
>                           Karthik Bhargavan
>         Filename        : draft-irtf-cfrg-hpke-00.txt
>         Pages           : 17
>         Date            : 2019-07-03
> Abstract:
>    This document describes a scheme for hybrid public-key encryption
>    (HPKE).  This scheme provides authenticated public key encryption of
>    arbitrary-sized plaintexts for a recipient public key.  HPKE works
>    for any combination of an asymmetric key encapsulation mechanism
>    (KEM), key derivation function (KDF), and authenticated encryption
>    with additional data (AEAD) encryption function.  We provide
>    instantiations of the scheme using widely-used and efficient
>    primitives.
> The IETF datatracker status page for this draft is:
> <>
> There are also htmlized versions available at:
> <>
> <>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at <>.
> Internet-Drafts are also available by anonymous FTP at:
> <>
> _______________________________________________
> Cfrg mailing list
> <>
> <>
> _______________________________________________
> Cfrg mailing list