Re: [Cfrg] A way out of the little/big endian dispute?

["Dan Harkins" <[e-mail]>]

On Mon, March 30, 2015 8:22 am, Watson Ladd wrote:
> On Mon, Mar 30, 2015 at 7:59 AM, Dan Harkins <[e-mail]> wrote:
[snip]
>>
>>   I have never discussed a person's SSH code or the difficulty in doing
>> scalarmult in big endian for a good reason… they have nothing to do
>> with representation on the wire. If one were of the opinion that
>> cleaner code and/or faster scalarmults can be had by implementing
>> as little endian then hey, bully for you. Implement little endian.
>
> If the wire representation doesn't actually affect the caller of the
> curve25519 function, or the implementation, what's the problem?

  If you truly believed there was no problem then you wouldn't be
arguing to change the wire format for this curve.

>>
>>   In your SPAKE2 draft you have a table with points for 3 curves,
>> none of which are curve25519. You have previously said, and I
>> paraphrase here, that you don't know the endianness of those
>> bignums because you don't care. Which is right! And the reason
>> you don't have to care is because _the convention is big endian_,
>> everything is conveyed as big endian (note that that says nothing
>> about how anyone must implement the underlying library to
>> support those curves).
>
> If you actually read the draft, you would see these aren't numbers but
> strings of bytes, and SEC1 determines what they mean.

  Wrong! You are expressing a point, as defined by SEC1 (you need
a normative reference for that document in section 7 by the way).

  And if I was to take your draft and implement it I would look at
section 2.3.4 of SEC1 "OctetString-to-EllipticCurvePoint Conversion"
and proceed to 2.2 where I "Convert X to a field element xp of Fq
using the conversion routine specified in Section 2.3.6" which says
to "Convert [the octet string] to an integer _a_ using the conversion
routine specified in Section 2.3.8." And that section is "OctetString-
to-Integer Conversion" and one can see in step 1 that it is quite
obviously big endian. Then my big endian integer becomes xp and
I will proceed to derive yp based on the value of the octet, Y, that
preceded X. Et voila, I have a big endian representation of an
elliptic curve point!

  It is actually a good argument for a single wire format representation
that you not only don't know but apparently don't care about how
information in your draft, necessary for interoperable implementation,
is formatted. The single wire format lets you write your draft in a
way that describes operations done on the points while being blissfully
ignorant of the matter of getting a point from a string of octets. That
is a good thing.

>>
>>   If you were to put curve25519 points into your draft you would
>> have to note the endianness of everything now because people
>> would be forced to care in order to implement your draft correctly.
>
> Imagine I had a group that wasn't written down as numbers, but as
> permutations. I still wouldn't have to care: I would just note which
> format was being used. It's entirely irrelevant that these strings are
> a byte followed by a packed bignum: all sensible code calls the
> appropriate unpack function for the group, no matter what that unpack
> function does internally. In fact, I don't see why I ever have to
> explain how group elements are written down, instead of pointing to
> the relevant standard explaining how those elements are written down.

  No, code, both sensible and insensible, obtains a point on an elliptic
curve in big endian format by doing this sort of octet-string to point
to octet-string conversions. There isn't "the appropriate unpack function
for the group", there is The Appropriate Unpack Function. Period.
Similarly, there is The Appropriate Pack Function, period, which you
call when you want to construct a message containing a point on an
elliptic curve that you will send to another over the ether. What you
are advocating for is the creation of this notion of different (un)pack
functions for different curves. Why? Because this curve was implemented
differently (for reasons that have nothing to do with wire format) and
you cannot abide any questions about it. We must change the way
it is done because this new curve must not be touched.

>>   It seems to me that what is being asked here is not just "let's
>> change the wire format to little endian for this particular curve",
>> it's "let's put the Imprimatur of the CFRG on a particular
>> _implementation_ of curve25519." That's a very different request
>> and something I don't think this group should be involved in.
>> We don't do rubber stamp here.
>
> And which implementation do you think we're putting the imprimatur on?
> Because there are multiple, independent implementations that all use
> little-endian.

  The implementation that all the other implementations have expressly
stated they are conforming to (e.g. "The usage is exactly the same…." to
quote one of those other implementations).

  Dan.