Dmitry Eremin-Solenikov dbaryshkov@gmail.com 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