Hello, чт, 5 дек. 2019 г., 8:15 Niels Möller <[email protected]>:
> Dmitry Eremin-Solenikov <[email protected]> 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? > This conversion will take place at each a_to_h call. More importantly the conversion at h_to_a will include modular inversion. So I wanted to lower the amount of such conversions. > 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. > Would it be ok to change ecc_point size to become a per curve option? > > > > 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 > A close rival to ecdsa sign/verify (see rfc 7091 and 5832). 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. > No problem, I'll submit then the next round of patches without this one. > (For your curves, you may need a slightly different ecc_mul function to > support Z != 1, same loop but different table_init). > And ecc point memory size. And adjusting tests that use low-level representation. > > 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. > Again, in this case it concerns only public key being converted to an internal representation. > 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. > _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
