Return-Path: 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 DA6EC3A147A for ; Tue, 28 Apr 2020 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=eWFLtktU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BnNR6+6I 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 mxfcifRSy0jy for ; Tue, 28 Apr 2020 05:39:34 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D023A1471 for ; Tue, 28 Apr 2020 05:39:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 789265E7 for ; Tue, 28 Apr 2020 08:39:33 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 28 Apr 2020 08:39:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=ECMhR6DQd1vWLCNBbQGTDWs0cx9ggVoRZzQkrs3OPcM=; b=eWFLtktU fvVlIldwrTWTNF43pm0o+YqqLODjJAxN4ylE995GYGBHAnUZzDI8i9X2yVmxXD6s 245D3z0LHqpvbo1PiEwOv9qSuQWDf7wE8RMJztlklCZgapsqG1QnW/TMj8oorl3M XD3lQvT1mgV9YOYSlwpPP9X4Y/WR6TPdC36mGKpSzYzXcTZMkwZVK4zdHPE/wgky Ki8tc4c3zQbnwJUw9hg2s81HlqHKB5Q1foHiitqoY5nQMFNEWCc/4xuvMTUuFvVI ukR5cB6MG2GDAtWKL2xMaMbtyDOYaWDNJPOjUW3Fm0OezhNXqkv+Gv4KYmQPM9zr aNijGVrvdDW2iQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ECMhR6DQd1vWLCNBbQGTDWs0cx9gg VoRZzQkrs3OPcM=; b=BnNR6+6IN1RXlNDbozPJ8XI66Vff7t26utthF5fbmwufQ dGGTkJq7sOs+5ftJ2WTDXmNwZsCb6EbpkBQj0KqLFLCiKdPEil9rDbL0gQKe2GoV KJ2PfthQv5OR8sFa6vWDJGYbSDnY6W5tvwn6r7hHIXxiBseTknqyrxFppnuiAtdF h1eDouIlkeOAj9ImNFpRTrghYDwpfAzoyFMVeinBPKVks3ealYsLXo0MHZlzeuOU 9XL+8VGitxtH8Snv6vKmaZALviD3PD9VzUvYF1WjUEgVOQsptUQJriskc7/TqfjV kxM2K/P2b2xXDxeMdSui0/kmFy6qQCnNW6nfw+1CQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedugdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhith hhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CA2423C00A1; Tue, 28 Apr 2020 08:39:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <710336c1-b499-4119-a0d8-a1aaa16a0b07@www.fastmail.com> Date: Tue, 28 Apr 2020 05:39:12 -0700 From: "Christopher Wood" To: cfrg@irtf.org Content-Type: text/plain Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 12:39:36 -0000 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