On Wed, Jun 4, 2014 at 7:06 AM, CodesInChaos <[email protected]> wrote: > No matter which way is chosen, it's important to get the IETF TLS > specification for Curve25519 to match what's chosen and to include > test-vectors for it.
Please, please try to follow the CFRG: that's where this specifying is going on. If they get it right we are happy. If not, we aren't. Anyone can contribute: it really does matter. > > Personally I prefer ignoring the bit. My effort to change > LibSodium/Donna was to ensure that all major implementations have the > same behaviour. I'm hard pressed to think of a situation where you don't know if you are doing ECDH or signatures. However, I hear the argument that one code path can calculate the scalar multiplication for both if we do this bit trick, and by ignoring the the top bit interoperate. The only detail/problem is that you have to mask the top bit of generated shared keys. This complicates exposing a simple scalarmult operation. > > If we can get all major implementations, including NaCl to ignore the > bit I'd be happy to follow that path. > On a related note, DJB's implementations in SUPERCOP recently changed > from interpreting it as a 256 bit integer to ignoring the top bit. > But I don't know if NaCl will follow. Somebody should talk with its authors. > > Note that you can put a sign into MSB, even with 256 bit integer > interpretation, it's just a bit annoying. > _______________________________________________ > Curves mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/curves -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
