Re: [CFRG] compact representation and HPKE

Dan Harkins <dharkins@lounge.org> Wed, 10 February 2021 18:36 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E2E3A12C5 for <cfrg@ietfa.amsl.com>; Wed, 10 Feb 2021 10:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT2keMPXpcVS for <cfrg@ietfa.amsl.com>; Wed, 10 Feb 2021 10:36:52 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A163A1104 for <cfrg@irtf.org>; Wed, 10 Feb 2021 10:36:52 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QOB0AY4QT1GA6@wwwlocal.goatley.com> for cfrg@irtf.org; Wed, 10 Feb 2021 12:36:52 -0600 (CST)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QOB00B9BT026F@trixy.bergandi.net> for cfrg@irtf.org; Wed, 10 Feb 2021 10:36:03 -0800 (PST)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 10 Feb 2021 10:36:03 -0800
Date: Wed, 10 Feb 2021 10:36:50 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <C20B10DB-DE8F-4084-B85E-9E48F3046245@inria.fr>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Cc: ML IRTF CFRG <cfrg@irtf.org>
Message-id: <8b2e0353-f5b8-eedb-d513-006bb30bcb04@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
References: <0fcfb0ed-249b-7cd3-09ba-ed1c73122383@lounge.org> <C20B10DB-DE8F-4084-B85E-9E48F3046245@inria.fr>
X-PMAS-Software: PreciseMail V3.3 [210210] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/VtXQcbJ11VuJfRIGI5CarPIjMhA>
Subject: Re: [CFRG] compact representation and HPKE
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 18:36:54 -0000

   Hi Benjamin,

On 2/10/21 10:24 AM, Benjamin Beurdouche wrote:
> Hi all,
>
> Isn't the uncompressed form way more common?
> I guess you can certainly use some compressed form for transport in that case...

   Many other uses require that both sides agree on the sign and therefore
either the point is sent uncompressed or as the x-coordinate plus a sign 
bit.
But in this case we don't care about the sign. We are doing "compact output"
(per RFC 6090) and therefore can take advantage of "compact representation"
(ibid).

   regards,

   Dan.

>
> B.
>
>
>> On 6 Nov 2020, at 19:19, Dan Harkins <dharkins@lounge.org> 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
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg

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