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

"D. J. Bernstein" <> Sun, 25 January 2015 08:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4C1DD1A0193 for <>; Sun, 25 Jan 2015 00:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.896
X-Spam-Level: **
X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CCCT_aeyI-kM for <>; Sun, 25 Jan 2015 00:30:33 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id A22491A0011 for <>; Sun, 25 Jan 2015 00:30:32 -0800 (PST)
Received: (qmail 22842 invoked by uid 1017); 25 Jan 2015 08:30:52 -0000
Received: from unknown (unknown) by unknown with QMTP; 25 Jan 2015 08:30:52 -0000
Received: (qmail 10435 invoked by uid 1000); 25 Jan 2015 08:30:18 -0000
Date: Sun, 25 Jan 2015 08:30:18 -0000
Message-ID: <>
From: "D. J. Bernstein" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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 08:30:34 -0000

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

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