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

Peter Gutmann <> Tue, 27 January 2015 10:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A03261A8766 for <>; Tue, 27 Jan 2015 02:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rMIYfCXrx48K for <>; Tue, 27 Jan 2015 02:35:05 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B625C1A8738 for <>; Tue, 27 Jan 2015 02:35:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1422354905; x=1453890905; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EImqITEcIztAgYHdsn6UGl8h50Ku4nyMMWK4ohUFNn8=; b=rjDAvSicN4wBY+kVZJ/SKvMkTI/R2Dm5ETXNLIvNLD9goOR2YR3cLqwP /xGxRaVP0WxVRXkSN9yqIF3AeGdTba/+edGBotweC6EoW0mlchQRntXCL k9r9ggJcgA/i8pB24L2R68k4RvwFoN0+2FVYgJHDvjHBAjv4zROjz3CS7 U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="303896679"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 27 Jan 2015 23:34:59 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 27 Jan 2015 23:34:59 +1300
From: Peter Gutmann <>
To: "''" <>
Thread-Topic: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
Thread-Index: AdA6HOWyc3EIrAHPSf+7q6EEIfAl2Q==
Date: Tue, 27 Jan 2015 10:34:58 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 27 Jan 2015 10:35:07 -0000

Michael Clark <> writes:

>This code could do with some optimization, bswap(32|64) intrinsic (uses BSWAP
>machine instruction on x86_64, ARM, etc), working with a machine word size
>loop with a small tail loop to handle the modulus of the difference in length
>of the bignum from the machine word size. It is working byte by byte.

This is another example of "I can't believe we're having this discussion".
We're talking about bignum operations measured in the millions of CPU cycles
(a basic 1024-bit RSA decrypt is about 10M cycles, with P256 it's 7M cycles,
courtesy of the Crypto++ benchmark data) and you're bringing up optimising
something that might take a few hundred cycles (ignoring memory latency
overhead, which is going to hit you at some point whether you endian-reverse
or not).

The issue isn't about whether a 0.001% overhead is worth applying custom
architecture-specific assembly-language to eliminate, it's the issue of
encoding a particular implementation artefact into a standard.  As djb has
helpfully pointed out, he could have decided to encode the values as ASCII
decimal digits, or perhaps doodles, sign language, and squirrel noises.  Would
crypto standards then require that everything using 25519 be able to encode
the output as squirrel noises just because that's what one implementation

The universal standard for crypto bignums is big-endian (things like aren't a standard, it's what one implementation
chooses to do).  The 25519 form is an implementation artefact and should have
no place in a standard.