Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
"Dan Harkins" <dharkins@lounge.org> Tue, 27 January 2015 16:44 UTC
Return-Path: <dharkins@lounge.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 EC52B1A88E4 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level:
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 vMvseqLu9qHe for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 08:44:09 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 00ABE1A88F2 for <cfrg@irtf.org>; Tue, 27 Jan 2015 08:41:47 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8348610224008; Tue, 27 Jan 2015 08:41:46 -0800 (PST)
Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 27 Jan 2015 08:41:46 -0800 (PST)
Message-ID: <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net>
In-Reply-To: <54C77376.3080005@cs.tcd.ie>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF6839A@uxcn10-tdc05.UoA.auckland.ac.nz> <54C77376.3080005@cs.tcd.ie>
Date: Tue, 27 Jan 2015 08:41:46 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Gh4sng58qXhEu2emrOOqXUNVHM4>
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
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:44:12 -0000
On Tue, January 27, 2015 3:16 am, Stephen Farrell wrote: >>> >>> But seriously, if in fact this makes little or no difference, which I >>> believe >>> is the case, and which I believe you are also arguing, then what is the >>> problem with going with the initial coder's choice here? >> >> Because, as I've already pointed out in an earlier message, if the >> universal >> standard is big-endian and the vast majority of your potential user base >> (via >> OpenSSL, not sure about MS CryptoAPI) only does big-endian, then >> choosing a >> format that's not big-endian is a really bad idea. > > You didn't say why. Why is it a bad idea? What is the downside? > ("only does big-endian" isn't it clearly, because if the little > endian form were adopted here that'd no longer be true so the > question is how that'd cause problems if the spec called for it > to be done.) > > I'm really asking there and not point-scoring btw. mostly because I > think this entire process has been quite fraught about even the > least important things, and I'd hope we don't do that to ourselves > again;-) It's a bad idea because standards like X9.62 and ISO/IEC 15946 and RFC 5090 have all defined the way to go from a bitstring to an integer to a field element and back that involve representation in big endian. This is the canonical conversion between bit strings and elements. And this is not some arbitrary issue that can just be relegated to the bowels of the crypto library where we no longer care. Knowledge of the special-case-ness of curve25519 will percolate up to the application writer. For instance, * After doing an ECDH you take the X-coordinate and pass it to a KDF. But how? Well, there's those rules to go from field element to integer to bitstring. Except now you have to have a special case. So you do BN_bn2bin() unless it's curve25519 then you do BN_bn2binle() (which doesn't exist now for a very good reason). * Or Imagine if someone wanted to implement Watson's SPAKE2 draft. It involves hashing into an elliptic curve to get elements M and N. So after you hash up a bunch of cruft you convert the digest as a bit string into an integer and then into the X-coordinate of your element. But how do you do that? Well you do BN_bin2bn() unless it's curve25519 and then you do BN_bin2bnle() (which does not exist now for a very good reason). This spells interop problems even if you just adopt DJB's code to handle curve25519. Special cases will be a continued source of trouble. And for what? At least Martin Luther had a list of grievances that he nailed to the church door to start his reformation. This particular attempt at reformation to free curves from the canonical format has none. regards, Dan.
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Brown
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Alyssa Rowan
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Peter Gutmann
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian (was: Adoption of … Salz, Rich
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Salz, Rich
- Re: [Cfrg] Point format endian Stephen Farrell
- Re: [Cfrg] Point format endian Paul Hoffman
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Derek Atkins
- Re: [Cfrg] Point format endian Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Point format endian Paul Hoffman
- Re: [Cfrg] Point format endian Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … Andy Lutomirski
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Stephen Farrell
- Re: [Cfrg] Point format endian Tony Arcieri
- Re: [Cfrg] Point format endian (was: Adoption of … Michael Clark
- Re: [Cfrg] Point format endian Damien Miller
- Re: [Cfrg] Point format endian Phillip Hallam-Baker
- Re: [Cfrg] Point format endian Phillip Hallam-Baker
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd
- Re: [Cfrg] Point format endian (was: Adoption of … D. J. Bernstein
- Re: [Cfrg] Point format endian (was: Adoption of … Dan Harkins
- Re: [Cfrg] Point format endian (was: Adoption of … Watson Ladd