Re: [CFRG] compact representation and HPKE

Karthik Bhargavan <> Mon, 15 February 2021 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 693163A0D6F for <>; Mon, 15 Feb 2021 08:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VkQNfpdRI-OQ for <>; Mon, 15 Feb 2021 08:44:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B030C3A0D69 for <>; Mon, 15 Feb 2021 08:44:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.81,181,1610406000"; d="scan'208";a="373125064"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2021 17:44:34 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Karthik Bhargavan <>
In-Reply-To: <>
Date: Mon, 15 Feb 2021 17:44:33 +0100
Cc: Christopher Wood <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [CFRG] compact representation and HPKE
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: Mon, 15 Feb 2021 16:44:38 -0000

I think the idea of having a compact representation of EC points for use in IoT-like scenarios is an attractive one, but the core ciphersuites of HPKE should only depend on standardized and widely-implemented point formats.

In particular, HPKE is certainly not the right place to standardize a new EC point format, however sensible the change may seem.
A protocol like EDHOC is laser-focused on small wire messages and is meant to be implemented by IoT-specific crypto libraries, and so it makes sense for that protocol to employ such optimizations.
Perhaps the LAKE working group could drive a IETF/CFRG standard for x-only EC point representations that are more generally usable by other protocols?

Having said all that, HPKE is extensible and we do anticipate extensions to HPKE in the near future, notably for adding PQ ciphersuites.
I think the best way to proceed for compact HPKE would be, along the lines of Dan’s suggestion, to propose new KEM algorithm identifiers for compact encodings of the NIST curves, and to do this as part of a new CFRG draft as an extension to HPKE.
I suspect that, beyond the point representation, we may find other parts of HPKE that would benefit from compaction for low-bandwidth scenarios.