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

[Robert Ransom <[e-mail]>]

On 1/24/14, Manuel Pégourié-Gonnard <[e-mail]> wrote:
> On 23/01/2014 20:45, Robert Ransom wrote:

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

Yes.

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

Yes, I am.

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

Yes.

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

Yes.  (Even though I am now convinced that there is only one
reasonable choice for the other coordinate for Curve25519.)


Robert Ransom