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

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

On 23/01/2014 20:45, Robert Ransom wrote:
> So, the only implementation I know of that does not ignore the MSB is
> a horribly slow one that should never be used in production -- I would
> not be surprised if it's slower than a typical implementation of the
> BND curves.
> 
Good to know. It really pleads for recommending to ignore the MSB even if we
don't need it later.

> I still think that avoiding implementation fingerprinting would
> justify “implementations SHOULD mask off the high bit”.
> 
I agree.

> Remember that what Dr. Bernstein refers to as ‘public key validation’
> in the Curve25519 paper is considerably more expensive than one
> bitwise AND:
> [...]

Sure.. Another point I thought about in the meantime is that the security
consequences of not doing that check are minimal for Curve25519 (implementation
fingerprinting) as opposed to short Weierstrass curves with (x, y) coordinate
(small subgroup attack).

> If you add a leading byte as an extension hook *and* specify an
> ECPointFormat value for the current ‘Montgomery-form x’ point format,
> current implementations can refuse to receive point formats which they
> won't understand.

Haha, I think I finally understood. You're referring to this paragraph of the
draft, right?

   Since only one point format can be used with Curve25519, which is
   distinct from the formats used by short Weierstrass curves, the
   contents of the "Supported Point Formats" extension is irrelevant for
   this curve.

Yes, if we add a leading byte, and we want to be able to use other formats
(hence other leading bytes) with Curve25519 in TLS in the future, then this
phrase should be removed and a new ECPointFormat value requested from IANA.

> If you don't add a leading byte, I think the ECPoint length byte can
> still be used as an adequate extension mechanism for future non-ECDH
> protocols.
> 
As long as there is no more than one future format mapping to the same length.
Eg, is for some reason some people want to send

> I agree, but future implementations should be allowed to send an
> uncompressed second coordinate without breaking compatibility with
> implementations of this protocol.  What I'm suggesting is that (a)
> current implementations send 32-byte points; (b) current
> implementations accept both 32-byte and 64-byte point objects, and
> ignore the second half of a 64-byte point.
> 
That's an option too, but compared to a leading byte, it doesn't allow to define
two different 64-byte point formats in the future, right? So maybe the leading
byte (with ECPointFormat negociation) is the most future-proof way.

Manuel.