Nikos Mavrogiannopoulos nmav@gnutls.org 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