Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

Andy Lutomirski <> Tue, 27 January 2015 17:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CBF101A1B36 for <>; Tue, 27 Jan 2015 09:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IuPX_0feUJJx for <>; Tue, 27 Jan 2015 09:20:41 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2ED91A887E for <>; Tue, 27 Jan 2015 09:20:40 -0800 (PST)
Received: by with SMTP id f15so14319737lbj.5 for <>; Tue, 27 Jan 2015 09:20:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id kw9mr2961416lbb.99.1422379239250; Tue, 27 Jan 2015 09:20:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Jan 2015 09:20:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Andy Lutomirski <>
Date: Tue, 27 Jan 2015 09:20:17 -0800
Message-ID: <>
To: Dan Harkins <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Peter Gutmann <>, "" <>
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Jan 2015 17:20:43 -0000

On Tue, Jan 27, 2015 at 8:41 AM, Dan Harkins <> 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

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?)