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

Watson Ladd <> Sun, 25 January 2015 20:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C61201A6F32 for <>; Sun, 25 Jan 2015 12:36:00 -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 lRmbqLUtvX0Z for <>; Sun, 25 Jan 2015 12:35:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5080C1A0032 for <>; Sun, 25 Jan 2015 12:35:58 -0800 (PST)
Received: by with SMTP id 19so2558804ykq.8 for <>; Sun, 25 Jan 2015 12:35:57 -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=lvYL964TM1wVePzPK6ZTDZGN1MuGrkMMWjUkd7xRnu0=; b=BRqlCt0qPJgZSw9qxOWjeibig56vFDJrVYqPIZdSy5bI11qiq7I9njXFeKPZPZ9TYL uvBcZLSce1xZ3Es/Sf4D+ty7/w1aJ11rai95Tuwslr6tlaQ+DKV0YewnCA8ubft8HH9s B0w76UASBV8nXj4A33zDz/iNq2CzjwyGbvC6MP3Q9F4jp8nKwfAaBFahbtgg6kE0YAmH cc+CphNe4bDDqaiOS2H565MuKYVCGRCAqXiSEWZCmVMMgVpiLtrzNZR97MKig/1LFjRx VDE6fYInfkCqkrIINIqbpvX4gxVPcMdHcNlvh+NsdGtZAxufysgqjdJn4T6JLZ7hRRpB BfNQ==
MIME-Version: 1.0
X-Received: by with SMTP id e206mr9009805ykb.126.1422218157550; Sun, 25 Jan 2015 12:35:57 -0800 (PST)
Received: by with HTTP; Sun, 25 Jan 2015 12:35:57 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 25 Jan 2015 12:35:57 -0800
Message-ID: <>
From: Watson Ladd <>
To: Mike Hamburg <>
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: Sun, 25 Jan 2015 20:36:00 -0000

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.

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

The fact that actual developers making actual projects don't consider
this a problem should register.

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

SEC1 does this for points, but not signature elements. I agree that we
should used fixed-length whenever possible.

> Cheers,
> -- 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
> _______________________________________________
> Cfrg mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin