Whoops, thanks for the correction. It should be the code point assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448, Ed25519 and Ed448.
Thanks, Joe On 1/12/16, 6:24 AM, "Simon Josefsson" <si...@josefsson.org> wrote: >Adam Langley <a...@imperialviolet.org> writes: > >> Curve25519, as the name suggests, operates on 255-bit numbers. When >> encoded as bytes, there's obviously a 256th bit that needs to be >> specified. >> >> Curve25519 implementations didn't set the bit but did used to vary on >> how they parsed it. Some would take a 256-bit number and reduce it >> while others would ignore the bit completely. >> >> However, I believe that implementations have converged on ignoring it. >> That behaviour is specified in draft-irtf-cfrg-curves and tested via >> the test vectors. >> >> 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. > >I agree. > >/Simon _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
