Re: [TLS] Point validation in 1.3

[Antoine Delignat-Lavaud <[e-mail]>]

Le 2016-11-17 14:58, Antoine Delignat-Lavaud a écrit :
> Le 2016-11-15 15:35, Ilari Liusvaara a écrit :
>> On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote:
>>> I think the performance enhancement (in terms of handshakes per 
>>> second)
>>> that you get by reusing ephemeral keys is so great, that we have to
>>> assume people will do it.  You don’t have to keep the keys 
>>> indefinitely.
>>> It’s fine to generate a new key every second or ten seconds or so.
>>> 
>>> Which makes running the point validation all the more important.
>> 
>> There's two main reasons for point validation:
>> 
>> 1) Preventing leaking of the secret exponent.
>> 2) Preventing key collisions from low-order points.
>> 
>> TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without 
>> EMS).
>> 
>> X25519/X448 have been explicitly designed to resist 1).
>> 
>> If you want to prevent using low-order points for some reason, there 
>> is
>> a handy trick: Check if the output of X25519/X448 is all zeroes or
>> not, and abort if it is.
> 
> There is an unfortunately common mis-conception that X25519 doesn't
> need point validation for Diffie-Hellman which comes from the original
> PR of Bernstein et al. Curve25519 has an order 8 subgroup that can be
> used to do key collisions and transcript synchronization attacks (see
> III.B.2 in [1]). The proper validation is to exclude 0, 1,
> 325606250916557431795983626356110631294008115727848805560023387167927233504,
> 39382357235489614581723060781553021112529911719440698176882885853963445705823,
> 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 +
> 325606250916557431795983626356110631294008115727848805560023387167927233504,
> 2^255 - 19 +
> 39382357235489614581723060781553021112529911719440698176882885853963445705823,
> 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this
> validation, any one peer of the connection can (mostly) control the
> session key, which is mitigated in TLS 1.3 but still an undesirable
> property in any compound authentication setting.

I misunderstood your message, if you check the output of the 
multiplication with the peer public key rather than the public key 
itself, checking for 0 is indeed the easiest (and safe) check to 
perform.

Antoine