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

Mike Hamburg <> Mon, 26 January 2015 06:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5702D1A700E for <>; Sun, 25 Jan 2015 22:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8ehSSlSew-P for <>; Sun, 25 Jan 2015 22:42:23 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 254251A1EFF for <>; Sun, 25 Jan 2015 22:42:22 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 017B63AA0F; Sun, 25 Jan 2015 22:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1422254522; bh=N2yyhOFMRKoTg1TZ199YTJZPZIFi4fSTUUQGD6I1nVY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ZijTkgcRU9s/DKv+l8Oc7aiEskoFY188nGjGdc3NMtBSjAUsfDXR7SEItekf6wqVW PHkXmwOIf34W3sL84vic6VDNfj69PhySqgwcXnte+VqTGE5XgWukg75MFHly6830aj eRNM69NgS59lOYExPjHToVAXBJZUTbfYlajl2Kv8=
Message-ID: <>
Date: Sun, 25 Jan 2015 22:42:21 -0800
From: Mike Hamburg <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Dan Harkins <>, Watson Ladd <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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:42:24 -0000

On 1/25/2015 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.
This is only half an answer.  I'm well aware that many crypto libraries 
use generic bignum packages.  But will the endian complicate the 
implementation of the new curves?  That is, do they lack little-endian 
serialization code?  Or is their EC point codec generic enough to handle 
Montgomery/Edwards point formats over whatever field, and yet not 
generic enough to pass a little-endian flag?

I mean, if some real library will need to byte-reverse a buffer, then 
that's a wart, if only a minor one.  If it will need to pass -1 instead 
of 1 to bn_export in a newly-written serialization routine, then this 
really just doesn't matter at all.

-- Mike