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

[Michael Clark <[e-mail]>]

On 27/1/15 6:34 pm, Peter Gutmann wrote:
> 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.

I agree. I did qualify the statement that its unlikely to register on a
profile. e.g. don't forget to paraphrase without the context:

On 26/1/15 8:57 pm, Michael Clark wrote:
> So with big-endian wire-formats, practically all machines are going to
> bswap as the internal rep will be little endian. That cost is probably
> low compared to the cost of the computation, so there is a reasonable
> rationale to stick to big-endian.

This seems to be about adapting to IETF tradition. Fair enough.

The question is whether or not in the case of Curve25519, the keys are
considered an "opaque octet string" or unless the point needs to be
consumed and interpreted outside of the cryptographic primitive; then
there is an argument to follow the big-endian bignum tradition.

1). Will Curve25519 be used elsewhere (other than as a diffie-hellman
replacement) where the keys are exposed in form they need to be operated
on as a bignum, rather than opaque 32-byte octet strings? i.e. is to be
considered a standalone cryptographic primitive?

2). From reading Curve25519, the keys are stated as opaque, however I
understand that Curve25519 can be expressed in various isogenies where
the keys (32-byte strings) are no longer opaque and are big-nums. Is it
intended to be used in a general way as a parametrization?

If so it would mean it might be a good idea either for Curve25519 to use
byteswap from network byte order or to define a big-endian alternative
with a different name that does so. X25519; where the keys are no longer
opaque as per the current normative reference that specifies
"little-endian" 32-byte strings:

  https://tools.ietf.org/html/draft-josefsson-tls-curve25519-01
  http://cr.yp.to/ecdh/curve25519-20060209.pdf

a). If it is intended to be used as a standalone primitive, then it
doesn't matter so much: "32-byte octet string"

b). However if it is to be used generally as a parametrization that fits
into a curve generalization then this provides a good rationale to use
the tradition of big-endian bignums. i.e. ends up in ASN.1 fields, with
different parametrization of the same generalization.

Does that make it any easier? :-)