IETF Logo Mail Archive

Re: [Cfrg] hash-to-curve updates and suite reduction

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Tue, 28 April 2020 15:24 UTC

Return-Path: <prvs=23871758be=uri@ll.mit.edu>
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 990FC3A168F for <cfrg@ietfa.amsl.com>; Tue, 28 Apr 2020 08:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 YSKj3B4IEeXf for <cfrg@ietfa.amsl.com>; Tue, 28 Apr 2020 08:24:48 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 D133B3A0C7A for <cfrg@irtf.org>; Tue, 28 Apr 2020 08:24:47 -0700 (PDT)
Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 03SFOfGs041215; Tue, 28 Apr 2020 11:24:41 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Christopher Wood <caw@heapingbits.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] hash-to-curve updates and suite reduction
Thread-Index: AQHWHVonMXnM714VkUmjuoioK4aXlaiOp4+A
Date: Tue, 28 Apr 2020 15:24:39 +0000
Message-ID: <80F64681-7E5A-4664-957B-0EAB737E6A94@ll.mit.edu>
References: <710336c1-b499-4119-a0d8-a1aaa16a0b07@www.fastmail.com>
In-Reply-To: <710336c1-b499-4119-a0d8-a1aaa16a0b07@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-originating-ip: [172.25.1.84]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3670917879_1869099819"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-28_10:2020-04-28, 2020-04-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004280121
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/2U5MyTbAYpz9wauvGpEPe-LWzn8>
Subject: Re: [Cfrg] hash-to-curve updates and suite reduction
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: Tue, 28 Apr 2020 15:24:50 -0000

Offhand: in this context I would prefer erring towards code reuse, even at the cost of lesser efficiency.

On 4/28/20, 08:40, "Cfrg on behalf of Christopher Wood" <cfrg-bounces@irtf.org on behalf of caw@heapingbits.net> wrote:

    Hi folks,
    
    The hash-to-curve authors spun draft-irtf-cfrg-hash-to-curve-07 recently [1]. Some of the major changes focus on how we handle DSTs for domain separation in hash_to_field. If you have some spare cycles, please have a look and provide feedback! 
    
    In addition to this change, I'd also like to call attention to the section on suites [2]. We've heard criticism that there are currently too many suites defined, which can complicate implementations and protocols [3]. The list should likely be reduced. In particular, the document should probably specify at most one recommended suite covering both the RO and NU cases for each curve. (Alternatives could be defined elsewhere, i.e., in separate documents if needed.) 
    
    In this interest of document clarity and ease of use by the community, we'd like to know what folks think about this proposal. Some questions to consider are:
    
    - What should be the preferred mapping function for each curve? For example, P-256 specifies P256_XMD:SHA-256_SSWU_RO_  and P256_XMD:SHA-256_SVDW_RO_, which use the Simplified SWU (SSWU) and Shallue-van de Woestijne maps, respectively. Considering libraries that might implement the Shallue-van de Woestijne for more than one curve, should we err towards code re-use or stick with the less-general SSWU map?
    - Should each curve have one suite for the RO case and another for the NU case? Doing so assumes implementers know when and how to choose between these two variants. This is something the document mostly skips over, saying simply, "When the required encoding is not clear, applications SHOULD use a random oracle."
    
    Thanks in advance for your time and consideration.
    
    Best,
    Chris
    
    [1] https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-07
    [2] https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-07#section-8
    [3] https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/235
    
    _______________________________________________
    Cfrg mailing list
    Cfrg@irtf.org
    https://www.irtf.org/mailman/listinfo/cfrg

v2.23.0 | Report a Bug | By Email