Re: [Cfrg] big-endian short-Weierstrass please
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 28 January 2015 18:48 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803F31A1AC6 for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 10:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
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 zI3IcPibdiB4 for <cfrg@ietfa.amsl.com>; Wed, 28 Jan 2015 10:48:48 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A71111A1A22 for <cfrg@irtf.org>; Wed, 28 Jan 2015 10:48:48 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 40785F984 for <cfrg@irtf.org>; Wed, 28 Jan 2015 13:48:45 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 3872A203A0; Wed, 28 Jan 2015 13:48:44 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: cfrg@irtf.org
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5D42BDA@XMB116CNC.rim.net>
User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Wed, 28 Jan 2015 13:48:44 -0500
Message-ID: <87386ug2r7.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/f_MdN5IG5QweCRbXqZVeQ40DcZA>
Subject: Re: [Cfrg] big-endian short-Weierstrass please
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jan 2015 18:48:50 -0000
On Tue 2015-01-27 10:41:50 -0500, Dan Brown wrote: > But I wonder if there are any old implementations of the standards I listed > above, that accept generic specified short Weierstrass curves, but lock > together the KDF and raw ECDH operations. Users stuck with such > implementations couldn't gain _all_ the benefits of Curve25519, side channel > resistance or whatever, but surely there's some residual benefits for them > to use Curve25519 with a generic representation: maybe the rigidity > Curve25519, or interoperability with other users with the newfangled > software, not to mention the blessing of the collective wisdom of CFRG. > > If the argument is that no such implementations could exist, or that the > implementations, or even old ECC standards, are so bad that we should try to > discourage interoperability, then please present that case. It sounds to me like you're presenting a choice between two options for the CFRG: 0) help more people move to better curves, without moving anyone to better algorithms or requiring anyone to move to better implementations. 1) Allow people who can move to better algorithms, implementations, and curves to do so in one step, while leaving people with brittle software behind if the new system is adopted in exclusion to the old. It seems like the answer to this would be governed by your perception of (a) existing curves compared algorithms and implementations, and (b) how you expect the rollout+deprecation process to happen, but even considering both of these choices independently, it seems like (1) is better. Curves vs. Algorithms and Implementations ========================================= If you feel that the existing curves themselves are the main source of concern, but not the algorithms and implementations, you might lean a little bit toward (0). However, there seems to be a general consensus that existing implemetations and algorithms themselves are problematic -- for example, libraries like OpenSSL have rewritten their P-256 implementations in the last year, and deterministic signature mechanisms are clearly better than traditional ECDSA. So (1) is more appealing -- if we can fix more things during this transition, we should fix them. Rollout and Deprecation ======================= There is existing code that is never going to change. There is existing code that can be minorly changed by tweaked parameters. And there is existing code that can be easily, fully upgraded. The first group is never going to disappear, and unfortuately, members of that group might be too important for every tool to just ignore the group entirely (consider systems that want to talk to home routers or networked printers, or systems that are only willing to use NIST curves). So tools that require backward compatibility that covers these systems will need to have some level of fallback interoperability to existing practice in both curves and algorithms. But if we're going to have the fallback to existing practice anyway, we can also use that to cover those implementations that can only accept minor changes. (1) seems like the better option to me, from an overall ecological point of view. Let's take advantage of this transition time to include important fixes in all areas, for those who can make them. As for byte-ordering: higher levels of abstraction (both on the wire and logically) all prefer fixed-length bitstrings anyway. So that's the interface that we should use for the primitive. We should declare something explicit so that libraries know what to produce to get canonical bitstrings, and move on. Little-endian is fine. Regards, --dkg
- [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please David Gil
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Alyssa Rowan
- Re: [Cfrg] big-endian short-Weierstrass please Tony Arcieri
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Alyssa Rowan
- Re: [Cfrg] big-endian short-Weierstrass please Stephen Farrell
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Hanno Böck
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Watson Ladd
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Watson Ladd
- Re: [Cfrg] big-endian short-Weierstrass please Dan Brown
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Yoav Nir
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Paul Hoffman
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] big-endian short-Weierstrass please Daniel Kahn Gillmor
- Re: [Cfrg] big-endian short-Weierstrass please Nico Williams
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker
- Re: [Cfrg] big-endian short-Weierstrass please Andrey Jivsov
- Re: [Cfrg] big-endian short-Weierstrass please Phillip Hallam-Baker