On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith <br...@briansmith.org> wrote: > I agree with all of that in principle. In fact, I think that most of section > 2.3 should be removed in deference to the CFRG document, and only > TLS-specific concerns should be given. > > I still think there is value in requiring senders to send their public value > in the "normalized" form and for allowing (if not requiring) receivers to > reject, at least, public values >= q, for the reasons I gave in my previous > email. Ideally that would happen in the CFRG document. But, what is the > status of the CFRG document? I've heard that it's past the point where > changes will be accepted.
The CFRG document is in AUTH48 right now so, indeed, it's probably too late for that sort of change. To give some background about why the CFRG document ended up the way it did: The curve25519 paper only mentions the extra bit to say: "Note that Curve25519 is not surjective: in particular, its final output bit is always 0 and need not be transmitted." [1]. It didn't specify whether it should be ignored or not and implementations started to differ on that point. Also, in order to keep the code simple, it didn't check for values >= 2^255-19. Both because that could be more code in the primitive itself, and because it would mean that the function would change from being total to partial. Some years ago, there was a small effort to align the different implementations around the same behaviour and ignoring the bit was chosen. I think that decision probably arose from changing the fewest things and also the thought that people might want to use the extra bit as a sign bit in the future. No implementations rejected values >= 2^255-19 from what I recall. Since the CFRG has standardised Curve25519, in practice the existing implementations will seed the implementation ecosystem. Changing something really subtle like the extra bit behaviour, or rejecting oversized values, without a clear need, doesn't seem to me to be worthwhile (or, perhaps, even achievable for a spec). So at this point I'd like to nail down the existing behaviour with tests, try to make it uniform across most implementations, and try to avoid other specs interpreting the byte strings. [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
