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

[Peter Gutmann <[e-mail]>]

Michael Clark <[e-mail]> 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
does?

The universal standard for crypto bignums is big-endian (things like
[e-mail] 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.

Peter.