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

Watson Ladd <> Mon, 26 January 2015 06:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EA7B1A1EFF for <>; Sun, 25 Jan 2015 22:56:18 -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 ep8EprIIz1tY for <>; Sun, 25 Jan 2015 22:56:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DD201A1A5B for <>; Sun, 25 Jan 2015 22:56:16 -0800 (PST)
Received: by with SMTP id f73so2826592yha.4 for <>; Sun, 25 Jan 2015 22:56:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYft59gy55xCwctP2HEpSnAM7HufrbyMe9mtQ1ZzRLg=; b=NKHctqrEst/22ImLcDGXm8aePY+rUtDyf+frK0tx43twm9cy2Qo2P2/vPy3GjJS1EF 3+ZYDimlmGgv62fopbk7DsfExSPSmK3DS9RvEhoA2Ia0NL12UTVzzDLuucE4XrCc65qN wkFDcU5yDaF7LYIuDqjxwm84gB3o2LT0DQZsEmrjzjIkjSdXVjKNDVczFQzFn6M/3Nb7 98u+JBMbZKEgcVYQxKjcnzQVyAZOxt5vKGk8GPto6Aqkvenu3wZs6HpYhce2bdTw4GLf S6dr22k78P+PWZ7S8WReTDIW8yQ2JN5ULx/50Mt5uQClVLCAb46hvzcHAPo4QSNi8VZo TsMw==
MIME-Version: 1.0
X-Received: by with SMTP id 46mr8584509yho.138.1422255375448; Sun, 25 Jan 2015 22:56:15 -0800 (PST)
Received: by with HTTP; Sun, 25 Jan 2015 22:56:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sun, 25 Jan 2015 22:56:15 -0800
Message-ID: <>
From: Watson Ladd <>
To: Dan Harkins <>
Content-Type: text/plain; charset="UTF-8"
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:56:18 -0000

On Sun, Jan 25, 2015 at 10:31 PM, 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.

I've never seen a big-endian bignum library: everyone uses
little-endian internally for the calculations, so there already is a
forced reordering.

>> 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.

You're ignoring the large costs of confusion between people who think
Curve25519 has big endian because the CFRG said so, and Curve25519 has
little-endian because tweetnacl.c or tweetnacl.js says so.

>> 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.

I don't think this is a real problem for several reasons:

-Curve25519 defines a single scalar mult function. It's easy to fold
any endian conversions into this function at the beginning and end.
-If you don't export this function, but instead force a separate
deserialization and reserialization step before and after, you can put
those swaps there instead
-If deserialization and serialization don't know what curve they are
on, because you assume Weierstrass, your scalarmul code must know and
could change it.
-If your scalarmult code doesn't know, how is that possible? You can
write something with a and p as parameters, but this won't work for
Curve25519 even if we change the endianness.

Of course, you could simply use tweetnacl.c or the implementations in
NaCl and trust that someone else solved all those problems.

Watson Ladd

>   Dan.