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

Yoav Nir <> Mon, 26 January 2015 06:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C7D11A7017 for <>; Sun, 25 Jan 2015 22:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6YCPsZD9iB31 for <>; Sun, 25 Jan 2015 22:57:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04D2E1A1EFF for <>; Sun, 25 Jan 2015 22:57:44 -0800 (PST)
Received: by with SMTP id l2so7272664wgh.5 for <>; Sun, 25 Jan 2015 22:57:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UAdvjVOsxNMz6TaQNGgHQu2Mx6RRohP6aZ327A+0mBM=; b=zE3Rvmgf+sPSk6OtA3JNYSVLkJrRpdgcd4cd2vSqLU5CVykAtgKcCu/yMz8DCeA3FG 9J2dxPIVxyTNpMwTW/Vb2Ja5BwB3berHJH5HDlq1rsgLA+RoT9aEjybh11b89R2mkSw6 3Zoy1t9bW5NRGatF/9VIDZPFSpmujz7ULZmvOTME8MmxwUurplAuxa4rm/bNXdD6M46c Fq+qqLSRrybtfGMraE4hazGiKHx1eM4YAth3MC7M776a9f+Ajyu5gxnaDwT3tDUouqnL tqApfjsuSIPc4PAz6QvrbvCKk0yb2QPHVurRSf9s2nfuXhcTCO3EqJn6y6i/4lW9yB2l WXug==
X-Received: by with SMTP id bd1mr29175500wib.10.1422255462723; Sun, 25 Jan 2015 22:57:42 -0800 (PST)
Received: from ([]) by with ESMTPSA id l6sm12999811wjx.33.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Jan 2015 22:57:41 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: text/plain; charset="utf-8"
From: Yoav Nir <>
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Mon, 26 Jan 2015 08:57:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.1993)
Archived-At: <>
Cc: "" <>
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: Mon, 26 Jan 2015 06:57:46 -0000

> On Jan 26, 2015, at 8:31 AM, Dan Harkins <> wrote:
> On Sun, January 25, 2015 12:35 pm, Watson Ladd wrote:
>> On Sun, Jan 25, 2015 at 10:26 AM, Mike Hamburg <> wrote:
>>> I think that this is actually an interesting question, so maybewe can
>>> put aside religion and mockery thereof for little bit...
>>> Does anyone know of existing code which processes cryptography over
>>> multiple fields using a generic bignums package (hopefully with
>>> fixed-size
>>> bignums for timing resistance), and would be complicated by inconsistent
>>> endian practices in a new curve?  If so, it might be worth considering a
>>> consistent endian.
>  Yes Mike, there are numerous crypto libraries, both open source and
> proprietary, that use a generic bignum package. And it is that "might be
> worth considering" that is making me raise this issue.

All other things being equal, yes, consistent is better than not. But really, it’s not difficult to add functions like BN_bin2bn_le() and BN_bn2bin_le() to OpenSSL which makes both kinds of on-the-wire encoding equally easy to implement. There is little benefit in carrying over an optimization from the days when the dominant platform for doing things on the Internet was Solaris running on Sparc CPUs. By far the most dominant hardware platforms today are Intel and ARM, and both of them are little-endian. No, ntohl() is not a resource-intensive operation, but to avoid needing it is better than to not avoid it. Also, calling this function (or macro) that was short-sighted. It assumed that everything on the network would be big-endian. It should have been called big2internal(). 

>> Both NSS and OpenSSL have a bignum library underlying ECC operations,
>> but I don't know how often that gets used in practice vs per curve
>> optimized implementations. But we're talking about swapping bytes in a
>> serialization function: it's a potential wart, but a small one. If we
>> do reverse endianness, then what SSH is already doing won't be
>> included.
>  Warts are ugly. And if small warts are not a concern then let's just
> leave SSH with a wart and everyone else can be wart-free.

converting from wire format to local format is always a wart. You can only be wart-free if you have a unified design for everything from the start. That’s not the way the Internet came to be as evidenced by the fact that we’re still writing RFCs. There are warts everywhere, and this one doesn’t make it worse.

>> The fact that actual developers making actual projects don't consider
>> this a problem should register.
>  Well this actual developer making actual projects considers this a
> problem. The argument from Rich is that he's OK with curve25519
> being a special case because of he wants to interop with some existing
> implementations. And I guess that's the difference. Aside from SSH
> (which will have "a potential ward, but a small one") I don't see
> a large number of protocols implemented with this format that
> make this change compelling.

In a 3-month project to add curve25519, this represents less than an hour of extra work. It’s in the noise.