Re: [CFRG] compact representation and HPKE

Andrey Jivsov <> Fri, 12 February 2021 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9F183A1018 for <>; Fri, 12 Feb 2021 14:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nsuKFrvY2GU6 for <>; Fri, 12 Feb 2021 14:29:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E38EE3A1011 for <>; Fri, 12 Feb 2021 14:29:50 -0800 (PST)
Received: by with SMTP id u25so1697055lfc.2 for <>; Fri, 12 Feb 2021 14:29:50 -0800 (PST)
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=xxjWiyHaIwEUdNXES4nZ5kIaMS2CbbRooFf2ic6Shw0=; b=ZnCRwZLtz8fkIKF6htCr7psyXwVqSYxDLuwn0g7EHSvNXvp7uTXXq6Fp6cfmESFI/6 ohg7lJD/I1iZ9Hyr7wwRaQYqi+UM2MSdwDImOPqXNsQI724mg+TTV6YwuUR7dXkTaeEP k+MNRV8CsGOyjiYLevgeOGC1J3VCV4ZR+lh3pBxIoio5XkxADEaOSJQyLaKc9chBNrOy GzkST3j4qZfnm3ZMTRol40U4ehoEEF5+7QZL5XXbFeiz7uKDjRW0hL23mJrYVr4iKvor wvmaU2+yZd8G8sgCBAI78TeCeoIIRlFaj1HERl6gV8rRZrcEqzkFT5FlvfxnzsIcAE86 W59g==
X-Gm-Message-State: AOAM532eU2S9T/CXr99Cb16/UJ5wkeeQiZ8SMac8f6YlmJYHtAhOLWoU wA/IlxXwWP11X0FxC1E0tjopbKi30U32a3Qj/C3hXubd7tSAybTP
X-Google-Smtp-Source: ABdhPJzSCTuWwjErLESO+b87BewEV8VWkVFj2TTF5HxfHeoeZQ58VUGMcnkC9Ox+kfdNSmVxacPKOMQOhqbormK0vkU=
X-Received: by 2002:ac2:545c:: with SMTP id d28mr2649759lfn.446.1613168988700; Fri, 12 Feb 2021 14:29:48 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Andrey Jivsov <>
Date: Fri, 12 Feb 2021 14:29:38 -0800
Message-ID: <>
To: Eric Rescorla <>
Cc: Dan Harkins <>, CFRG <>
Content-Type: multipart/alternative; boundary="00000000000088e0f205bb2b2c6b"
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:29:54 -0000

> 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.

I am not seeing a big interface problem here.

With methods discussed here, and all in, compression is
the act of removing the leading byte and y. This is trivial and doesn't
need crypto awareness.

The decompression can be based on the size of input (field size, v.s. 2x+1
field size).

Also, I am not sure there is any FIPS compliance issue here, at least with
my draft. FIPS protocols hash only x, and y can/should be reconstructed
anyway. Key generation, for cases where this matters, can be done as a
blackbox, e.g. this works with any FIPS 140-2 Level 3 compliant HSM device,
with non-extractable keys, without any awareness on the part of HSM.

On Fri, Feb 12, 2021 at 2:14 PM Eric Rescorla <> wrote:

> 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.
> -Ekr
> _______________________________________________
> CFRG mailing list