Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
Well, I've had two particular GOST curves in mind. They are defined in Weierstrass form, but have birationally equal Edwards curves that can be used for point addition.
And to do that conversion without an expensive modular inversion, you get a Z != 1?
It might make sense to to more work in ecc_point_set, but I'd prefer to not introduce a Z cooordinate for the current weierstrass curves.
Converting to/from Edwards form during each operation doesn't look like a good solution.
And what are those operations? ecdsa_verify? I agree it's not ideal to have that function do the coordinate conversion every time. On the other hand, conversion may be very cheap compared to the two scalar multiplications done by ecdsa_verify. I think I'd prefer to postpone that optimization.
(For your curves, you may need a slightly different ecc_mul function to support Z != 1, same loop but different table_init).
Hmm, I don't see how mpz_t internal representation can be a threat.
In this case, maybe not (in particular if it's for ecdsa_verify, with no secret inputs). But in general, practically any mpz_t operation on a number of nominally n bits will leak information on whether or not most significant bits are all zero.
That's why I prefer to use mpz_t only in the public api (and even there, it might be preferable to use octet strings of predetermined length, just like for the curve25519 operations). Depending on applications' needs.
Regards, /Niels