Re: [Cfrg] Point format endian

"Derek Atkins" <> Tue, 27 January 2015 16:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D7A0D1A8864 for <>; Tue, 27 Jan 2015 08:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tR4ZD7-Qiv5V for <>; Tue, 27 Jan 2015 08:25:59 -0800 (PST)
Received: from ( [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44E901A885A for <>; Tue, 27 Jan 2015 08:25:59 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C816FE2039; Tue, 27 Jan 2015 11:25:56 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 14183-04; Tue, 27 Jan 2015 11:25:54 -0500 (EST)
Received: by (Postfix, from userid 48) id 521D9E203A; Tue, 27 Jan 2015 11:25:54 -0500 (EST)
Received: from (SquirrelMail authenticated user warlord) by with HTTP; Tue, 27 Jan 2015 11:25:54 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 27 Jan 2015 11:25:54 -0500
From: Derek Atkins <>
To: Paul Hoffman <>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] Point format endian
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 16:26:01 -0000


On Tue, January 27, 2015 11:07 am, Paul Hoffman wrote:
> We do not need "consensus" in this RG, just assurance that what we
> recommend does not have security holes. No one has suggested any security
> holes based on the endianness. The argument that "using different math
> would add code" is true, but pretty much irrelevant relative the to the
> size of the code needed to add a new curve. There is no interoperability
> issue: if someone messes up the math in either endian direction, they will
> know the first time they test their code, and there is approximately
> 2^-128 chance that if they got it wrong and only tested one vector, that
> they will accidentally get a good result.
> The longer we argue about our preferences (instead of actual security
> issues), the worse off the IETF is.

It is important for interoperability.  If I tell you that my ECC Public
Key is 0102030405060708090a but you interpret that as 0a090807060504030201
-- we will get different results even if both of us implement the math
correctly.  So I would argue that transmission encoding of keys and
results *is* a matter of security.

Then of course there's the matter of using the shared secret in another
algorithm, like AES.  Again, byte-order differences would result in
different AES keys.  Yet another matter of security.

Yes, it just mean we just need to "choose one".  But for the last 20+
years we've already chosen:  network-byte-order.

> --Paul Hoffman


       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant