Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

[Nikos Mavrogiannopoulos <[e-mail]>]

On Sat, 2014-01-25 at 01:18 -0800, Robert Ransom wrote:

> > You seem to imply that following conventions established during the years is
> > unecessary. That could be true, but your only point of backing that up is
> > that a library that implements this curve uses the little endian format.
> Several libraries implement Curve25519 scalar multiplication in
> constant time, with varying degrees of portability and efficiency.
> All of them operate on public and secret keys in little-endian format.

I still cannot see your argument here. Is there a requirement for this
curve to be implemented or do these libraries use little-endian format
because it suits them better (e.g., they target little endian systems)?
This is an honest question as I don't know the answer.

> > Why force any other
> > library that will implement this curve handle its points in a special way?
> Does this mean that you intend to implement Curve25519 using a generic
> bignum library?  How will your implementation (attempt to) avoid
> leaking information about key material to a side-channel attacker?

Do you mean about power analysis (e.g., constant power consumption or
time)? Why would that matter for the protocol in question? As I
understand the document specifies additional curves for ephemeral
key exchange (ECDHE), so side channels are not a threat.

> It is about standardizing a curve which has a well-established
> convention of storing and transmitting keys in little-endian format.

I believe that software does the transmitting rather than the curve
itself, so that I think that my point of not standardizing software but
a curve is still valid.

regards,
Nikos