On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith <br...@briansmith.org> wrote: > Watson Ladd <watsonbl...@gmail.com> wrote: >> >> Why not hash the public values into the result of the key exchange? I >> don't want security to depend on omittable checks. > > > One would need an omittable check in the code to decide whether to do that > extra hashing, so that wouldn't solve the (non-)problem of "omittable > checks". > > Similarly, one would need an omittable check to decide whether to require > the session hash extension, so it wouldn't solve the (non-)problem of > "omittable checks". > > Actually, because the check for non-zero result can/should/is in the > X25519/X448 functions themselves, the check for non-zero result is the least > likely of all these possible solutions to be omitted. And, it is also the > easiest to test.
Failure to compute H(A, B, X25591(a, B)) would result in an interoperability failure with any other implementation of this ciphersuite. By contrast a zero check will not be exercised by basic interoperability testing, nor would mandatory use of session hash. All currently existing implementations of the X25519 function do not perform zero checks. Ones that do have to return a value, which can easily be ignored. Short of calling abort there is no way for implementors of cryptographic functions to ensure that callers pay attention to return values. > > Cheers, > Brian > -- > https://briansmith.org/ > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
