Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Andy Lutomirski <luto@amacapital.net> Tue, 27 January 2015 17:20 UTC
Return-Path: <luto@amacapital.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 CBF101A1B36 for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 09:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 IuPX_0feUJJx for <cfrg@ietfa.amsl.com>; Tue, 27 Jan 2015 09:20:41 -0800 (PST)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ED91A887E for <cfrg@irtf.org>; Tue, 27 Jan 2015 09:20:40 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id f15so14319737lbj.5 for <cfrg@irtf.org>; Tue, 27 Jan 2015 09:20:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DSYLR8Z+e6w8qJBUcwWFXpjP3Ywnl7escnP+7dzLu6o=; b=ZbM8cXl/ZYQ9x63aK0Ky5GPW0n49+bvpGc7t+NXuJihR3LEeR5mVf5RZGwTX8AD9R2 MO+3jOzu7R+WlpEcKdH4Ncg2iZ7J3fVXtQllTz0ctePlCD071FdRt6TNYn3xgKBOM0AI XbkVyAy8e9JG7UqAeGxc6IYml4XEjrHnPSWn961Smv3GonFPvaa90640Fw/i8XpjePv7 DHdogtteCicKnqIIKdjsDlTWpah04Q4yitJFzZp0azykTi4YiFG63gYDNggQJp+RCnLW vjIm/6tiKacPGByE+mDlU9b3ZM5iOCalEmmA20yn2b15AMyusUHXSD8qE7xKnjzWPfxn G8Ew==
X-Gm-Message-State: ALoCoQkX2zWxYwADxIHihxGxK27Q3p3YU9FsTDwKe8v58xvCkOfQgMVsIWZGtPB764NMPmwJCw30
X-Received: by 10.112.119.201 with SMTP id kw9mr2961416lbb.99.1422379239250; Tue, 27 Jan 2015 09:20:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.47.228 with HTTP; Tue, 27 Jan 2015 09:20:17 -0800 (PST)
In-Reply-To: <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF6839A@uxcn10-tdc05.UoA.auckland.ac.nz> <54C77376.3080005@cs.tcd.ie> <9ad11090808dc1e97bfc10196ad0e0c4.squirrel@www.trepanning.net>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 27 Jan 2015 09:20:17 -0800
Message-ID: <CALCETrUififB6HHnymWzk5Agkmhyc2Kghz=BWEHmMLeRwNv7wA@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/mYhzNkm4bGfF0WvexXHJedvKlIo>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "cfrg@irtf.org" <cfrg@irtf.org>
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 17:20:43 -0000
On Tue, Jan 27, 2015 at 8:41 AM, Dan Harkins <dharkins@lounge.org> wrote: > > > 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. This is not a good thing. I've worked on software that manipulates P-256 public keys. They're *variable length* because someone thought that this was a good idea. > > 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). Sorry, but this is backwards. As an application writer, I want to pass a string of bytes into the bowels of the crypto library, and I want to get a string of bytes back. I despise the fact that, with current crypto, I have to parse some ASN.1 crap to figure out *how many* bytes to pass to the crypto library. Given a choice between using ASN.1-encoded numbers (or sequences or whatever) and strings of bytes of either endianness, I'll take the byte strings any day. (Also, it's 100% unambiguous how to pass octet strings into a KDF, given that they all seem to operate, quite sensibly, on bytes. It's not at all unambiguous how to pass numbers to a KDF, on the other hand -- are they big-endian zero-padded? are they big-endian variable-length with MSB zeros stripped? maybe there's a length prefix? maybe that prefix is ASN.1? if so, how is it encoded?) --Andy
- 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