[email protected] (Niels Möller) writes: > See http://nacl.cr.yp.to/scalarmult.html. It's two functions, > > crypto_scalarmult(q,n,p); > > and > > crypto_scalarmult_base(q,n); > > I think nettle should use some different names (unless, maybe, some > curve25519-compat.h file is included). But I think we can use the same > arguments. If we don't implement points with y coordinates outside of the > base field, the crypto_scalarmult function needs a return value, to > indicate success or failure.
Implemented now. The two functions are called curve25519_mul and curve25519_mul_g. The former has a return value, returning failure if the y-coordinate of the given point doesn't belong to the base field (i.e., sqrt fails). Passes the test vectors in http://tools.ietf.org/html/draft-turner-thecurve25519function-00. The square-root computation done by curve25519_mul is *not* side-channel silent. That could be fixed, but it's not clear to me if that's needed. At least in the DH usecase, the input to the square root is a *public* key, so there's no reason to make efforts to hide it. Still on the curve25519 branch, but maybe it can be merged soon. Testing and feedback highly appreciated. Next steps are: 1. Extending struct ecc_curve with more function pointers to support other curves. Review the set of public ecc functions. 2. Benchmarking code. 3. EdDSA (where can I find test vectors for that?). 4. curve25519-specific assembly optimizations. One candidate is an modp_sqr which does the squaring and the reduction all in registers. 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
