Nikos Mavrogiannopoulos <[email protected]> writes: >> 2. curve25519_mul should be changed to have a void return type (an >> earlier implementation failed for inputs which didn't correspond to >> points on the curve, but instead were points on its twist). But the >> current implementation, using the Montgomery ladder, doesn't care and >> computes a well defined result for all inputs. > > No idea about this, do you think that a future re-implementation could > need an error code?
I've done this change now. In the documentation, I now say that the output is undefined for inputs on the twist curve. Which I think is fine for diffie-hellman: if you don't trust your partner to do his/her part of the diffie-hellman exchange correctly (and authenticate the messages you receive), you can't expect the generated session key to be secure or useful, no matter how curve25519_mul computes the shared secret. After optimizing the twisted edwards point operations, one could try the alternative implementation using a (somewhat expensive) change of coordinates to the twisted edwards curve, followed by a scalar multiplication there (which should be slightly faster than the Montgomery ladder), and then a change back to the original coordinates. It seems questionable that can be faster, and unlikely that it's going to be singificantly faster. So if that strategy is ruled out by benchmarks, we can document that the output for all possible inputs is what's computed by the Montgomery ladder. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
