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

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

On 12/01/2014 20:53, Adam Langley wrote:
> On Sun, Jan 12, 2014 at 11:17 AM, Manuel Pégourié-Gonnard
> <[e-mail]> wrote:
>> 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.
> 
> Using a generic bigint library is tough if you want to be constant
> time. (For example, integer division on Intel is variable time.)
> 
Right, but it seems to me some randomisation can help here.

> Also, internally, the library likely stores values as a series of
> words in little-endian order and is likely to be operating on
> little-endian systems, so little-endian is the more native
> representation.
> 
Agreed.

> I guess my overall point is that I don't see the concept of an
> "integer" as being a good one to put into TLS here. I think keeping a
> DH function as something that operates on bytestrings makes sense.
> Maybe they'll want to operate on binary fields, or compress the 'y'
> coordinate into one of the unused bits, or export a different
> coordinate form.
> 
If there was currently no concept of "integer" in TLS, I'd totally agree with
you here. But since there is, and they usually are represented as big-endian,
there is a tension between being consistent with existing usage and going the
arguably better way.

Manuel.