Re: [Cfrg] Point format endian

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 27 January 2015 16:07 UTC

Return-Path: <paul.hoffman@vpnc.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 C08931A8855 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:07:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 oJh3U8eqD-Jh for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:07:31 -0800 (PST)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E71491A1B36 for <cfrg@irtf.org>; Tue, 27 Jan 2015 08:07:30 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0RG7Tba097766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <cfrg@irtf.org>; Tue, 27 Jan 2015 09:07:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <b2b8d964885246748ebde894064b6a3c@ustx2ex-dag1mb2.msg.corp.akamai.com>
Date: Tue, 27 Jan 2015 08:07:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB4F04F6-82BA-41F9-B443-BA800D8E32A4@vpnc.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF68325@uxcn10-tdc05.UoA.auckland.ac.nz> <54C76EED.6090205@cs.tcd.ie> <sjm386wjko8.fsf@securerf.ihtfp.org> <b2b8d964885246748ebde894064b6a3c@ustx2ex-dag1mb2.msg.corp.akamai.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/x2lPIJ2WX6Bo-jhJuQpf0yMxxE4>
Subject: Re: [Cfrg] Point format endian
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: Tue, 27 Jan 2015 16:07:31 -0000

We do not need "consensus" in this RG, just assurance that what we recommend does not have security holes. No one has suggested any security holes based on the endianness. The argument that "using different math would add code" is true, but pretty much irrelevant relative the to the size of the code needed to add a new curve. There is no interoperability issue: if someone messes up the math in either endian direction, they will know the first time they test their code, and there is approximately 2^-128 chance that if they got it wrong and only tested one vector, that they will accidentally get a good result.

The longer we argue about our preferences (instead of actual security issues), the worse off the IETF is.

--Paul Hoffman