Re: [Cfrg] New names for draft-ladd-safecurves

Jon Callas <jon@callas.org> Wed, 22 January 2014 02:16 UTC

Return-Path: <jon@callas.org>
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 4915D1A01B8 for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 18:16:23 -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, SPF_PASS=-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 8gtw3JSIJlhk for <cfrg@ietfa.amsl.com>; Tue, 21 Jan 2014 18:16:21 -0800 (PST)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 77A741A0125 for <cfrg@irtf.org>; Tue, 21 Jan 2014 18:16:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id B79384B86A5E for <cfrg@irtf.org>; Tue, 21 Jan 2014 18:16:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ2xfJbYbWmj for <cfrg@irtf.org>; Tue, 21 Jan 2014 18:16:20 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id ED3984B86A52 for <cfrg@irtf.org>; Tue, 21 Jan 2014 18:16:19 -0800 (PST)
Received: from [10.0.23.100] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 21 Jan 2014 18:16:20 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 21 Jan 2014 18:16:20 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <52DEDE86.2060707@elzevir.fr>
Date: Tue, 21 Jan 2014 18:16:18 -0800
Message-Id: <BD3574E7-1A8F-4184-B02C-A0C359FF9588@callas.org>
References: <CACsn0ck02mnETBUfuyJjLV9K8Yuiki8_-RG0tVszL8BDhkK27w@mail.gmail.com> <6489F7D3-BF54-416F-94BE-64FD1CFCCB1E@callas.org> <CADMpkc+fxfXL8A21bGKgobKFvHxhQaiCEzROQmX4uH_73bgk1Q@mail.gmail.com> <CACsn0c=yrO5WiqshQ0z-eF+u1boyUYK5OQdr_XORXKTzJ7=KKA@mail.gmail.com> <CF03FB51.2CEE5%paul@marvell.com> <52DEDE86.2060707@elzevir.fr>
To: cfrg@irtf.org
X-Mailer: Apple Mail (2.1827)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Cfrg] New names for draft-ladd-safecurves
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, 22 Jan 2014 02:16:23 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My concern is essentially this:

Assume a curve that we'll call 1234-56 for some reason. If it's a nominally Edwards curve (like 414-19, fka Curve3617), it can (and will) appear in Edwards, twisted Edwards, and Montgomery forms. There are lots of good reasons for flopping it around and doing arcane things with it.

On the one hand, one might want to transport the curve in any of those formats. The primary purpose of a standard is for interoperability. Thus, having a way to know what form a curve is transported in is a good idea.

On the other hand, having many names for things causes questions and confusion because you then have to explain why the different names are really the same thing. Elliptic curves are hard enough as it is.

On the third hand, it might even be good to have a single *transport* format and just pick one. Force people to transport in one format.

On the fourth hand, is that *really* going to cause less confusion than having a name for each format?

See -- I don't have an answer here. With my standards hat on, I tend towards the third hand. Define *a* transport format and have just one. With my crypto hat on, some crypto people would cheer that, and others wouldn't. Either way, there's chance for error.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

wj8DBQFS3yn0sTedWZOD3gYRAnx2AJ4q3SrQ7/eeTUYgwAYnZNLfncOg6wCfWRy5
EvQ+uaBNA2SjnJFLcasiYlg=
=XuJM
-----END PGP SIGNATURE-----