Re: [CFRG] compact representation and HPKE

Eric Rescorla <> Fri, 12 February 2021 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50D8C3A0FF2 for <>; Fri, 12 Feb 2021 14:14:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 v-dN3BXPWCUZ for <>; Fri, 12 Feb 2021 14:14:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A2793A0FF1 for <>; Fri, 12 Feb 2021 14:14:10 -0800 (PST)
Received: by with SMTP id p21so1563018lfu.11 for <>; Fri, 12 Feb 2021 14:14:10 -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=CDxFhohj/NWyFyCjXzYWF5auUk8e2XWcABm2rceICiw=; b=qLdFr3ns8Lb7uefklUAgJLmP5mnEv/L62jM4YZKjq9pk8gUoQ8aXVX8crccKmZwgHc FmPlXCJHeo4T75BL3XfiIY4Ipq3WYtBhEvamgUE9akB/gigPOgmm6hDI+UM/Z66hm08s 7FM4xZ6OJ8wPOQPrpx3P6xKNVqYPEWKsT1LXNEd/OB3jKSg+E18H2bbaj+EYJG6qC1MZ 4PPwG/nRg31GIvRIw5JZPE5KW1lbzPuEdILoJAU3cMb/DUHEz62Xwj2bvD9CoSaPLZqf 5SN/KYUVdHlAAJaaVa6EOVL805DKEVS/VGiw9g8YFU9MBt22B7/iCdUXqFE7/ZP6fdRK /DgQ==
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=CDxFhohj/NWyFyCjXzYWF5auUk8e2XWcABm2rceICiw=; b=nNmOZHvbJJqsgFuX6GOZ4zraeJSjyX94aPH88m4lxVUfSmo0RpZIMs17FU9N+rqj3V RPhJTNlUEhxJ2Ncni93cIupI0s5dBut8N7lh1avHRx3Qbq11xPOpKlxSCADcNPgcYYTE +uP87ST+XN15vQt1ObJJU/7B5JPKU4Wp5HohvKgzGsDyrfzizrJMXfaKTHN4iRs+qbzh olBCP660M6aSsiMCIxLHmfWh7Pt1KwrEkR9P2Tsg3CWaoeqIvqgBvb9enri4Is6VhUkS ndB+hSyxYVkdAbplHHFXmwSJOJCGB1nnnJQW55/clYdi0x4fh+O/Ag1JRLNQd/UZgEGg pSFw==
X-Gm-Message-State: AOAM530RILf4jvZ99KJyr4z9LbeYC6HSZQlwrTQPCXm5iq1HgdzHybm1 M+aTej1dRYpquai1NkEbydApeoXljA19fEVLKbn0IQ==
X-Google-Smtp-Source: ABdhPJwpnOgjgJp78j8KrsmAC9YzVZyF5zv8kPo1QnmItvsxEGOMSJv7kjqMa59G1VUJ4lYkIU99sr0rUq4yT8zzdLI=
X-Received: by 2002:ac2:5086:: with SMTP id f6mr2549644lfm.16.1613168048683; Fri, 12 Feb 2021 14:14:08 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 12 Feb 2021 14:13:32 -0800
Message-ID: <>
To: Dan Harkins <>
Cc: CFRG <>
Content-Type: multipart/alternative; boundary="00000000000081539a05bb2af48c"
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 22:14:12 -0000

On Fri, Feb 12, 2021 at 2:00 PM Dan Harkins <> wrote:

> On 2/12/21 1:10 PM, Eric Rescorla wrote:
> 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 curves).
> 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.
>   I see. So we go with the technically inferior approach, in order to
> "encourage people
> to move to the CFRG curves."

I don't think that this reflects a fair reading of what I wrote above, and
in any case is not what I meant. Rather what I am trying to say is that we
should weigh the costs of having an inferior interface to the NIST curves
less heavily because we want people to move to CFRG curves anyway, at which
point this will be an non-issue.

  We should go with the "technically superior approach", especially when
> that results
> in a cleaner and more consistent API for HPKE.

The problem is that this comes at a less clean and consistent API for the
underlying cryptographic primitives which then have to be different
depending on which protocol they are embedded in.