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

[Watson Ladd <[e-mail]>]

On Sun, Jan 25, 2015 at 10:31 PM, Dan Harkins <[e-mail]> wrote:
>
>
> On Sun, January 25, 2015 12:35 pm, Watson Ladd wrote:
>> On Sun, Jan 25, 2015 at 10:26 AM, Mike Hamburg <[e-mail]> wrote:
>>> I think that this is actually an interesting question, so maybewe can
>>> put aside religion and mockery thereof for little bit...
>>>
>>> Does anyone know of existing code which processes cryptography over
>>> multiple fields using a generic bignums package (hopefully with
>>> fixed-size
>>> bignums for timing resistance), and would be complicated by inconsistent
>>> endian practices in a new curve?  If so, it might be worth considering a
>>> consistent endian.
>
>   Yes Mike, there are numerous crypto libraries, both open source and
> proprietary, that use a generic bignum package. And it is that "might be
> worth considering" that is making me raise this issue.

I've never seen a big-endian bignum library: everyone uses
little-endian internally for the calculations, so there already is a
forced reordering.

>
>> Both NSS and OpenSSL have a bignum library underlying ECC operations,
>> but I don't know how often that gets used in practice vs per curve
>> optimized implementations. But we're talking about swapping bytes in a
>> serialization function: it's a potential wart, but a small one. If we
>> do reverse endianness, then what SSH is already doing won't be
>> included.
>
>   Warts are ugly. And if small warts are not a concern then let's just
> leave SSH with a wart and everyone else can be wart-free.

You're ignoring the large costs of confusion between people who think
Curve25519 has big endian because the CFRG said so, and Curve25519 has
little-endian because tweetnacl.c or tweetnacl.js says so.

>
>> The fact that actual developers making actual projects don't consider
>> this a problem should register.
>
>   Well this actual developer making actual projects considers this a
> problem. The argument from Rich is that he's OK with curve25519
> being a special case because of he wants to interop with some existing
> implementations. And I guess that's the difference. Aside from SSH
> (which will have "a potential ward, but a small one") I don't see
> a large number of protocols implemented with this format that
> make this change compelling.

I don't think this is a real problem for several reasons:

-Curve25519 defines a single scalar mult function. It's easy to fold
any endian conversions into this function at the beginning and end.
-If you don't export this function, but instead force a separate
deserialization and reserialization step before and after, you can put
those swaps there instead
-If deserialization and serialization don't know what curve they are
on, because you assume Weierstrass, your scalarmul code must know and
could change it.
-If your scalarmult code doesn't know, how is that possible? You can
write something with a and p as parameters, but this won't work for
Curve25519 even if we change the endianness.

Of course, you could simply use tweetnacl.c or the implementations in
NaCl and trust that someone else solved all those problems.

Sincerely,
Watson Ladd

>
>   Dan.
>
>