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

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

On 22/01/2014 22:16, Robert Ransom wrote:
> * The draft still specifies a big-endian point format.  What is the
> technical benefit of requiring every TLS implementation which uses one
> of the existing efficient, secure implementations of Curve25519
> Montgomery-form scalar multiplication to reverse the byte order of its
> input and output?  (Note that people want to use Curve25519 in TLS
> because of those existing implementations, so deliberately breaking
> compatibility with them seems especially unwise.)
> 
I have no objection to changing the byte ordering if nobody speaks up for
big-endian in the next few days.

> * The draft should specify that implementations MUST discard (i.e. set
> to zero) the most significant bit of a received public key, for two
> reasons: (a) Existing Curve25519 scalarmult implementations differ in
> their handling of inputs with that bit set, and could be distinguished
> by an active attacker using that difference.

I wasn't aware that some implementations ignored the most significant bit. Out
of curiosity, could you cite examples?

One of the "selling points" of Curve25519 is that no public key validation is
needed, so I find it quite unfortunate that after all there is something to do
when receiving public keys.

> (b) Future specifications
> may wish to include the sign bit of an Edwards-form x coordinate in a
> Curve25519 point format for use with other protocols (e.g. Schnorr
> signature, Ace) without breaking backwards compatibility with use in
> ECDH.
> 
This is a serious concern indeed. By the way, there was another issue under
discussion that is related: should the point format be just the 32 bytes, or
should we use a leading byte to follow the existing practice from X9.62, as Salz
Rich suggested? If we use a leading byte, maybe it's better to have two formats,
one for "x coordinate only", one for "y + bit sign of x"?

> * The draft does not specify the curve equation of Curve25519 or the
> basepoint for use in ECDH.
> 
Of course it's no problem to add it. Do you think we should explain the
arithmetic too (Montgomery ladder + differential addition formulas)?

> * The ‘Security Considerations’ section suggests that Curve25519 can
> be implemented securely using bignum libraries which leak information
> about the numbers they operate on to a side-channel attacker, as long
> as the internal projective representation of each point is randomized.
>  Has this proposed side-channel countermeasure been evaluated?  If so,
> which types of information leakage does the countermeasure render
> harmless?
> 
I'm not aware of any specific analysis of this countermeasure for this type of
curves.

> * The draft claims that every curve listed in RFC 4492 whose name ends
> in “k1” is defined over a binary (characteristic 2) field.  This is
> false: RFC4492 defines several GLV curves over prime fields (e.g.
> ‘secp256k1’), and their names also end in “k1”.
> 
Right, this should have been corrected already.

Manuel.