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

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

On Tue, January 27, 2015 3:16 am, Stephen Farrell wrote:
>>>
>>> But seriously, if in fact this makes little or no difference, which I
>>> believe
>>> is the case, and which I believe you are also arguing, then what is the
>>> problem with going with the initial coder's choice here?
>>
>> Because, as I've already pointed out in an earlier message, if the
>> universal
>> standard is big-endian and the vast majority of your potential user base
>> (via
>> OpenSSL, not sure about MS CryptoAPI) only does big-endian, then
>> choosing a
>> format that's not big-endian is a really bad idea.
>
> You didn't say why. Why is it a bad idea? What is the downside?
> ("only does big-endian" isn't it clearly, because if the little
> endian form were adopted here that'd no longer be true so the
> question is how that'd cause problems if the spec called for it
> to be done.)
>
> I'm really asking there and not point-scoring btw. mostly because I
> think this entire process has been quite fraught about even the
> least important things, and I'd hope we don't do that to ourselves
> again;-)

  It's a bad idea because standards like X9.62 and ISO/IEC 15946
and RFC 5090 have all defined the way to go from a bitstring to an
integer to a field element and back that involve representation in
big endian. This is the canonical conversion between bit strings
and elements.

  And this is not some arbitrary issue that can just be relegated to
the bowels of the crypto library where we no longer care. Knowledge
of the special-case-ness of curve25519 will percolate up to the
application writer. For instance,

  * After doing an ECDH you take the X-coordinate and pass it to
    a KDF. But how? Well, there's those rules to go from field element
    to integer to bitstring. Except now you have to have a special case.
    So you do BN_bn2bin() unless it's curve25519 then you do
    BN_bn2binle() (which doesn't exist now for a very good reason).

   * Or Imagine if someone wanted to implement Watson's SPAKE2 draft.
    It involves hashing into an elliptic curve to get elements M and N.
    So after you hash up a bunch of cruft you convert the digest as a bit
    string into an integer and then into the X-coordinate of your element.
    But how do you do that? Well you do BN_bin2bn() unless it's curve25519
    and then you do BN_bin2bnle() (which does not exist now for a very
    good reason).

  This spells interop problems even if you just adopt DJB's code to
handle curve25519. Special cases will be a continued source of trouble.

  And for what? At least Martin Luther had a list of grievances that he
nailed to the church door to start his reformation. This particular attempt
at reformation to free curves from the canonical format has none.

  regards,

  Dan.