Re: [CFRG] compact representation and HPKE

Eric Rescorla <> Fri, 12 February 2021 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95B423A0E7A for <>; Fri, 12 Feb 2021 13:11:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vm8-T22xhtO3 for <>; Fri, 12 Feb 2021 13:11:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36AD33A0E79 for <>; Fri, 12 Feb 2021 13:11:02 -0800 (PST)
Received: by with SMTP id j6so683318ljo.5 for <>; Fri, 12 Feb 2021 13:11:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26ctp2wLR+oR0PVjPAqrRmMmvfN5fYtMmqx+uCi7s30=; b=T1q61+b8cFl3J7rcigboqhA6OchHO1KCPqf9pz9rE2Piz3ibAvoRbtZdHWcpIS7muW LVzU6wtTJfBvZ9FmqyxWwnlcv4wB8VWd9FLGwErrdILq1dIvjrxyfsSr0HaXYrabcBoq u3OZ17nZtvtWelbprIxtZMSaf6W6ltw25ugtgW8d9WSRFs6BRQUzGsnGoOZRhrzqGaxO VarVATyHWBJQrvPYNhg5cYD+a83idswyvaV7QUeIk9UchQM3jfVmOu2p0ykL1NO5zjhw 1h65ZMlA33vGPnOuTWpYc2T/961JUFRIUVa/BuojfVUeAMCF7j9GN4Hu0fLHw1ZviFS1 Xc4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=26ctp2wLR+oR0PVjPAqrRmMmvfN5fYtMmqx+uCi7s30=; b=BMTasNYq047llf/DTO7Ims7T9urdw5uS1f95kBpNOrVkeq7RyGFq8dRJgBp5V1287T Nvurj3AR731K/sDVGsLSJmIImz7v5yGbJjbyyxwoq4OnGG/4ca3Bg4mj3ae6m9AUQEQJ QpENDBMnV1D98uVbdGJDEMYw8E9NnV9dCGNHgh+lxGK9yuq3rErw7izquf0IhfW67SqF Syi3nT3+MFmACBgGNXdkS7wdsnNSYTdMW6K0WtqomB1WudlRH8GwWKLyfhRLsUIVYNz/ AbgRAcDO7OMbf+2V7PZVpVwu3GoROFzrZq3Q95NO5R/6ffkTWsPCRmzteZM2uB6B39kn PJSQ==
X-Gm-Message-State: AOAM530KoGPehOECETV8L/nfEoVhSRpCSdAHT4YTWDanhN12iEBLVOrd SndhXSIaMuLzRF8qJfYz1/VL0dRv0uYYyKhyX+LHcQ==
X-Google-Smtp-Source: ABdhPJzc3fsSQXUTJqFBgoIcMNePGvrRWqD4Vv+BuoGgdl2pFRswUgFwy5I1nk4DaE+chquM+GM3BCKPMhjRtrKr2YI=
X-Received: by 2002:a2e:9d96:: with SMTP id c22mr2712127ljj.109.1613164260398; Fri, 12 Feb 2021 13:11:00 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 12 Feb 2021 13:10:24 -0800
Message-ID: <>
To: Dan Harkins <>
Cc: CFRG <>
Content-Type: multipart/alternative; boundary="000000000000b4b35105bb2a1223"
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: Fri, 12 Feb 2021 21:11:05 -0000

As I understand it, the competing values here are:

(1) A technically superior approach (x-coordinate only)
(2) Consistency with existing uses of these curves (e.g., in TLS 1.3, which
uses x-coordinate-only form for CFRG curves but uncompressed form for NIST

Assuming I understand this correctly, I think I value consistency more,
especially in light of the fact that we are encouraging people to move to
CFRG curves anyway, which are already in the technically superior form.


On Fri, Nov 6, 2020 at 12:00 PM Dan Harkins <> wrote:

>    Hello,
>    When doing a DH-based KEM with the NIST curves, HPKE specifies that
> SerializePublicKey and DeserializePublicKey use the uncompressed format
> from SECG. This ends up using 2*Ndh+1 octets to represent the serial
> form of the public key.
>    Since compact output is being used in DH-based KEMs-- that is, the
> secret result of DH() is the x-coordinate of the resulting EC point--
> it would also be possible to use compact representation (per RFC 6090)
> and have SerializePublicKey merely do integer-to-octet string
> conversions of the x-coordinate. DeserializePublicKey would then
> do octet string-to-integer conversion for the x-coordinate and use the
> equation of the curve to choose the y-coordinate. The sign isn't
> important because we're doing compact output.
>    This would make the interface for the NIST curves and the Bernstein
> curves be uniform-- Serialize would produce an octet string of Ndh
> and Deserialize would consume an octet string of Ndh-- at the cost
> of some CPU inside DeserializePublicKey.
>    Please consider this suggestion.
>    regards,
>    Dan.
> --
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> _______________________________________________
> CFRG mailing list