Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

[Manuel Pégourié-Gonnard <[e-mail]>]

On 11/01/2014 20:03, Adam Langley wrote:
> On Sat, Jan 11, 2014 at 12:50 PM, Alyssa Rowan <[e-mail]> wrote:
>> But on reflection, pretty much everything else in internet standards
>> goes big-endian, so there's consistency there, and an endian swap
>> isn't exactly a big deal. No objection.
> 
> Happy to see curve25519 specified, but I do object to this. Every
> curve25519 implementation follows djb's API, which is byte orientated.
> I think it's sensible to leave the exact field representation to the
> DH function rather than have that concept spill into TLS. Maybe future
> DH functions will want to save an inversion and send extended
> coordinates or something.
> 
> Flipping the endianness just means that every single implementation
> has to undo it before feeding it into the curve25519 function.
> 
I understand your point.

Concerning implementations, unless I'm mistaken all the implementations of
Curve25519 you mention use custom routines for field arithmetic. I was thinking
about other implementations might want to use a more generic bignum library,
whose output function will probably be big-endian since that's the ordering
generally used in protocols. So for these implementations, big-endian would
probably be more natural.

(As a matter of fact, that's precisely the case of the implementation in
PolarSSL, but of course it wouldn't be fair to count it as pre-existing the
draft, since I've been involved in both the draft and this implementation.)

Manuel.