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