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

[Robert Ransom <[e-mail]>]

On 1/27/14, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> 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.

Curve25519 has a standard format for public and secret keys:
little-endian.  Several independent implementations, each of which has
its own advantages and disadvantages, conform to that standard.
Because each of them implements the existing standard key formats for
Curve25519, they interoperate with each other.

Complying with the existing, little-endian, standard for Curve25519
key formats would have the major technical advantage that TLS
implementations can use existing, off-the-shelf Curve25519
implementations without the unnecessary additional complexity of
reversing the bytes of Curve25519 inputs and outputs.

I have not seen a compelling *technical* reason for TLS to disobey the
currently existing, currently implemented Curve25519 standard by
reversing the bytes.


>> > 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?

Timing attacks can be (and have been) performed successfully on the
public-key portions of TLS implementations across a network.  They do
not require measurements of a server's power supply, as you seem to be
implying.

Data cache attacks are also relevant for all TLS implementations run
on hardware shared among parties who do not trust each other (e.g.
virtual private servers).

> As I
> understand the document specifies additional curves for ephemeral
> key exchange (ECDHE), so side channels are not a threat.

Side channels are a threat to every protocol implemented in software,
unless the implementation guarantees that secret information is not
made available to any hardware component which may leak it.


>> 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.

The existing Curve25519 software represents the rough consensus and
running code of several parties.  There are at least two independent
implementations (Dr. Bernstein's original and Adam Langley's
curve25519-donna).  As far as IETF is concerned, the existing
little-endian key formats for Curve25519 *are* a standard.


If you have a *technical* argument that justifies disregarding the
existing standard for Curve25519 key formats, please state it.


Robert Ransom