Adam Langley <a...@imperialviolet.org> wrote: > Currently > https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > says that implementations SHOULD reject inputs with the high-bit set. > I think that should be dropped. The X25519 function is specified in > terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec > should just use that draft.
First, maybe I'm overlooking something obvious, but I'm not seeing it: Why are we concerned only with whether the high bit has been set, instead of whether the public value has been reduced mod q (q == 2^255-19)? Aren't there ~19 interesting values that don't have the high bit set but which are also relevant to this issue? The draft notes that if the sender calculated the result correctly, then the result will never have the high bit set. So, then, we should have a requirement on the sender that the sender MUST NOT send a representation of its public value that has the high bit set? And, more generally, the sender MUST NOT send a representation of its public value that isn't reduced mod q. Would this be problematic to add this requirement? If we added the above requirement on senders, then it would matter less whether receivers reject values that aren't reduced mod q, as a conforming implementation would never send them, right? It seems like a good idea to reject non-reduced public values because: 1. By the argument in section 2.3, a conforming sender would never send them, so if the sender did send one, it means there's a problem with the sender of unknown severity, or an unknown attack on the wire. Either way, it's safest to bail out early. 2. Rejecting non-reduced values allows us to compare keys (after validation) by bytewise comparison and/or comparison of secure hashes of the bytes. AFAICT, this seems to matter less for x25519 and ECDH in general than it matters for signatures, but I bet that is just because I'm not creative enough to discover why it might matter for ECDH. I did give an example of why it can matter for signature public keys in [1]. It seems better to me to be cautious on the topic. [1] https://code.google.com/p/chromium/issues/detail?id=522228#c9 Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
