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

[Yoav Nir <[e-mail]>]

> On Jan 26, 2015, at 8:31 AM, 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.

All other things being equal, yes, consistent is better than not. But really, it’s not difficult to add functions like BN_bin2bn_le() and BN_bn2bin_le() to OpenSSL which makes both kinds of on-the-wire encoding equally easy to implement. There is little benefit in carrying over an optimization from the days when the dominant platform for doing things on the Internet was Solaris running on Sparc CPUs. By far the most dominant hardware platforms today are Intel and ARM, and both of them are little-endian. No, ntohl() is not a resource-intensive operation, but to avoid needing it is better than to not avoid it. Also, calling this function (or macro) that was short-sighted. It assumed that everything on the network would be big-endian. It should have been called big2internal(). 

>> 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.

converting from wire format to local format is always a wart. You can only be wart-free if you have a unified design for everything from the start. That’s not the way the Internet came to be as evidenced by the fact that we’re still writing RFCs. There are warts everywhere, and this one doesn’t make it worse.

>> 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.

In a 3-month project to add curve25519, this represents less than an hour of extra work. It’s in the noise.

Yoav