Dmitry Eremin-Solenikov <[email protected]> writes:

> I have been working on support for two particularly strange GOST
> curves, which are defined in Weierstrass form, but there exists a
> birationally equivalent Untwisted Edwards form (so all sign/verify
> calculations should be done in Edwards form).

I've merged some of Daiki's preparations for curve448 (also equivalent
to an untwisted edwards curve) to master-updates, to be merged to master
as soon as ci looks ok. I'm sorry this has been stalled. Initially it
had to wait for a release (since before nettle-3.5, the changes to
struct ecc_curve would be a subtle abi break, and nettle-3.4 was part of
that transition), but then it has dragged on.

> During this rework I thought about switching ecc_point from bearing
> just x and y coordinates to have per-curve defined coordinates (like
> projectile or inverted).

Struct ecc_point is intended to be a public api, which should be
independent of the implementation's preferred representation. So just
two numbers x, y.

That doesn't specify choice of coordinates precisely, though. For the
nist curves, it's coordinates for Weierstrass form, since that's how the
curves are specified. For curve25519 (and curve448, when completed), the
main api uses octet strings for input and output, so struct ecc_point is
not that important. For the GOST curves, I don't know, but I think we should
use the coordinates that are most useful for applications.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to