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

Mike Hamburg <> Sun, 25 January 2015 18:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B76FC1A0358 for <>; Sun, 25 Jan 2015 10:26:14 -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 vU_a34gax36N for <>; Sun, 25 Jan 2015 10:26:13 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28B7D1A034F for <>; Sun, 25 Jan 2015 10:26:13 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id B0F113AA0F; Sun, 25 Jan 2015 10:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1422210352; bh=e2cPnp3SZ5o9AwEOuJZ7MA8aJDzUpcQGKBKMRFb172c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Vj0oLonsz6gnfX8G+Vv2wn0rJ3sUDpBl7SeRVbjeiPYuML8VlbUGZDdXDFc7YlBY9 QuYRoFY+w6BFXln4RYwBmMcEV7jakYfoY+R6xzcx7OZzGrxuZ3KY6FCRPO3Z1vo1GA 4SQZGzZIAWaeAe7tr9tenHUEKN4nl6rPiUP9sEwg=
Message-ID: <>
Date: Sun, 25 Jan 2015 10:26:10 -0800
From: Mike Hamburg <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Dan Harkins <>,
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Sun, 25 Jan 2015 18:26:15 -0000

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.

Otherwise, I don't see why it really matters. Feel free to try to convince
me, but make sure you compose your post using Emacs and not vi.

However!  I think it's very strongly preferable that point formats and
signatures should contain a fixed number of bytes on a given curve.
(Perhaps allowing different sizes for compressed points, but leading zeros
*should not be stripped*.)  That way points and signatures can go into
structs instead of using some awful ASN.1 TLV format.

-- Mike

On 01/25/2015 09:48 AM, Dan Harkins wrote:
> On Sun, January 25, 2015 12:30 am, D. J. Bernstein wrote:
>>> a long-standing tradition of the on-the-wire format
>> Just to make sure that I understand, after reviewing a ton of tcpdump
>> output: You're referring to the HTTP tradition of variable-length ASCII
>> decimal encodings for integers on the wire (cache times, data lengths,
>> version numbers, etc.)? Does this mean that IETF pushed this HTTP
>> tradition into AES-GCM's internal integer encodings before deploying
>> AES-GCM, and plans to do the same for other cryptographic systems?
>    No, you could not be more wrong in that assumption.
>>> better looking and more maintainable code
>> You're absolutely right: being able to reuse existing variable-length
>> ASCII decimal integer encoders and decoders has always been a critical
>> part, I daresay the most important part, of implementing, reading,
>> auditing, and maintaining cryptographic software. RFC 1321 (MD5) got
>> this totally wrong---the integers are _backwards_ and _non-decimal_ and
>> _non-ASCII_---and we all know what happened to MD5 as a result.
>> Now that you've reminded me of what really matters for cryptographic
>> code complexity and security, I would love to put together an ASCII
>> decimal version of Curve25519, but I have to admit that I'm not
>> _completely_ clear on the details of the HTTP tradition that you're
>> talking about. For example, are leading zeros allowed? This would allow
>> simpler integer encoding for some embedded systems, but it would cause
>> trouble for existing parsers that switch to octal for a leading 0, such
>> as base-0 strtol(). Also, can the integers exceed 2147483647?
>    Do you want to be taken seriously when you respond like this?
>    Dan.
> _______________________________________________
> Cfrg mailing list