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

[Mike Hamburg <[e-mail]>]

On 1/25/2015 10:31 PM, Dan Harkins 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.
This is only half an answer.  I'm well aware that many crypto libraries 
use generic bignum packages.  But will the endian complicate the 
implementation of the new curves?  That is, do they lack little-endian 
serialization code?  Or is their EC point codec generic enough to handle 
Montgomery/Edwards point formats over whatever field, and yet not 
generic enough to pass a little-endian flag?

I mean, if some real library will need to byte-reverse a buffer, then 
that's a wart, if only a minor one.  If it will need to pass -1 instead 
of 1 to bn_export in a newly-written serialization routine, then this 
really just doesn't matter at all.

Cheers,
-- Mike