Nikos Mavrogiannopoulos <[email protected]> writes: > I only follow in the high level, but wouldn't it be better for this > function to be allowed fail if there are cases could fail? Even if the > current version doesn't, a future version could detect a broken peer > (but not malicious) and that is better than just ignoring it.
I think it's a desirable property of curve25519, as implemented using the Montgomery ladder, that no "point validation" is needed (even if I don't understand the fine details in why point validation is needed for many other curves). So 1. I like the interface with no return value, and I'd like to keep it unless there's some *significant* performance gain using some other method. And every eliminated return value makes the Nettle API simpler. 2. I think it is unlikely that the Montgomery method will be beaten. I discussed it briefly with djb before switching to the current implementation. The thing is that with twisted Edwards, an addition (8M) or a doubling (3M + 4S) is significantly faster than one step of the Montgomery ladder (5M + 4S). But for a scalar multiply we need 255 doublings + a bunch of additions (sligthly more than 64, with a 4-bit window size) + cost of point decompression + cost of side-channel silent table lookups. And the total is likely higher than for the 255 Montgomery steps in the current implementation. It's just that I'm a bit anxious to commit to using Montgomery ladder in future versions until I have done some benchmarks of my own. Maybe I should stop worrying about that, and document the output fully for all possible inputs? In the unlikely case that it turns out later to be a mistake, we *can* do an API break and fix it later. 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
