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

[Watson Ladd <[e-mail]>]

On Sat, Jan 24, 2015 at 9:14 PM, Dan Harkins <[e-mail]> wrote:
>
>
> On Sat, January 24, 2015 8:18 am, Salz, Rich wrote:
>>>   So a long-standing tradition of the on-the-wire format is changed
>>> because
>>> of the way the first curve25519 library was written? That's a weak
>>> justification.
>>
>> Strongly disagree.  But this is a religious argument and the sides will
>> probably never come to terms.  On the one hand we have tradition. On the
>> other we have a large deployed base.  Within the IETF canon of rough
>> consensus and running code, which argument will win?  Which argument
>> should win?  The IETF should follow its tradition and drop its wire format
>> tradition.
>
>   To me it's not a religious argument. But when you just say "strongly
> disagree" without any justification for making such a statement then
> perhaps I guess I can see how it is religious for you.
>
>   Endianness is the lowest of low levels. It is handled by a function that
> is #define'd around an #ifdef LITTLE_ENDIAN in some _common_ include
> file. Then everything reading and writing to the network has ntoh_whatever()
> routines that call the #define'd function. It makes for portable code.
> The alternative is to put endianness knowledge into the crypto library
> and have "if (religion) then if (big endian) then foo else bar fi else
> ntoh_foo fi". Which is something to which I strongly disagree. Better to
> just say "ntoh_foo".

Really? Because if you look at DJB's code you will see that it is
host-endian independent. Maybe your code casts (*char) to (*int) in
contravention of the C standard (yes, really: the proper type punning
is via unions), but it is entirely possible to avoid needing to do
this via shifts and legitimate casts.

>
>   I remember when the discussion of curve25519 started one of the
> proponents mentioned that the idea of many people writing code to
> implement it was not necessary, and was unwise, and that everyone
> should just use the existing library. And it's that idea that prompted my
> statement. We should just change our endianness practices, which make
> better looking and more maintainable code, because whoever wrote The
> Definitive Reference Implementation of Curve25519 choose little endian
> and everyone is just expected to use that. Why? Because.

OpenBSD had no problem adopting this: I doubt they lower standards for
maintenance then you do. Besides, you probably don't know how to write
C as well as DJB, and you almost certainly don't know as much about
making secure implementations as he does. Your code will not receive
anything close to the man-decades of review and automated testing that
some Curve25519 implementations have.

>
>> The reformation is coming:  fixed on the wire curve formats are gone; it
>> is now up to each curve to specify its wire rep.
>
>   And yet counter-reformation was much more grand and beautiful
> and majestic as compared to the cold, boring, puritan, calvinist
> reformation. Really, it's not anything that needs to be repeated.

Edwards curves could have been shoehorned into the SEC1 formats by
using the isomorphic Weierstrass form. Is that what you want? Or do
you want some other curve format (like x-coordinate Montgomery
little-endian) for all the new curves (of which we only have 1 right
now)?

Sincerely,
Watson Ladd
>
>   Dan.
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin