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

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

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.

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

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

  Dan.