Hello colleagues,
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). Major issues came from the fact that I have tried defining generator point in Edwards form (which is more logical).
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).
WDYT?
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
nisse@lysator.liu.se (Niels Möller) writes:
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.
The gnutls tests failed, see https://gitlab.com/gnutls/nettle/-/jobs/357863630.
Unclear to me if it's the nettle change or some unrelated problem.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
The gnutls tests failed, see https://gitlab.com/gnutls/nettle/-/jobs/357863630.
These are the failing gnutls tests:
FAIL: chainverify FAIL: key-import-export FAIL: privkey-keygen FAIL: x509sign-verify-gost FAIL: key-export-pkcs8 FAIL: pkcs11/pkcs11-chainverify
Unclear to me if it's the nettle change or some unrelated problem.
Some look related to gost curves, and the privkey-keygen failure is for a variant of ed25519.
Generated key with EdDSA (Ed25519)-160 FAIL privkey-keygen (exit status: 139)
There are similar failures on the ecc-sqrt branch,
https://gitlab.com/gnutls/nettle/-/jobs/321736090
from a few weeks ago.
Both branches included changes to the internal struct ecc_curve. So either gnutls is exercising some nettle features with poor test coverage in nettle's own tests, or gnutls is somehow depending on internals.
Regards, /Niels
Hello,
пт, 22 нояб. 2019 г. в 09:28, Niels Möller nisse@lysator.liu.se:
nisse@lysator.liu.se (Niels Möller) writes:
The gnutls tests failed, see https://gitlab.com/gnutls/nettle/-/jobs/357863630.
These are the failing gnutls tests:
FAIL: chainverify FAIL: key-import-export FAIL: privkey-keygen FAIL: x509sign-verify-gost FAIL: key-export-pkcs8 FAIL: pkcs11/pkcs11-chainverify
Unclear to me if it's the nettle change or some unrelated problem.
Some look related to gost curves, and the privkey-keygen failure is for a variant of ed25519.
GOST curves support in GnuTLS depends on exact Nettle ABI. I'd propose to add --disable-gost to Nettle's GnuTLS execution for now, till ECC ABI gets stable again.
An alternative approach would be to define a symbol like NETTLE_ECC_ABI_2 which can be used to detect ECC ABI compatibility.
ed25519 should not be directly tied to ABI compat. I'll take a look.
Generated key with EdDSA (Ed25519)-160 FAIL privkey-keygen (exit status: 139)
There are similar failures on the ecc-sqrt branch,
https://gitlab.com/gnutls/nettle/-/jobs/321736090
from a few weeks ago.
Both branches included changes to the internal struct ecc_curve. So either gnutls is exercising some nettle features with poor test coverage in nettle's own tests, or gnutls is somehow depending on internals.
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
GOST curves support in GnuTLS depends on exact Nettle ABI. I'd propose to add --disable-gost to Nettle's GnuTLS execution for now, till ECC ABI gets stable again.
I've just pushed a change to the .gitlab-ci file, so I hope the next build looks better.
An alternative approach would be to define a symbol like NETTLE_ECC_ABI_2 which can be used to detect ECC ABI compatibility.
For code depending on nettle internals, maybe you can use facilities in nettle/version.h (both compile time and runtime check would be appropriate, since changes to struct ecc_curve is no longer considered a change to the public abi, and will not imply an soname change or anything like that).
ed25519 should not be directly tied to ABI compat. I'll take a look.
Thanks.
Regards, /Niels
Hello,
вс, 24 нояб. 2019 г. в 11:45, Niels Möller nisse@lysator.liu.se:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
GOST curves support in GnuTLS depends on exact Nettle ABI. I'd propose to add --disable-gost to Nettle's GnuTLS execution for now, till ECC ABI gets stable again.
I've just pushed a change to the .gitlab-ci file, so I hope the next build looks better.
GnuTLS also received a MR to fix tests in minimal build, so next master-updates build should succeed.
An alternative approach would be to define a symbol like NETTLE_ECC_ABI_2 which can be used to detect ECC ABI compatibility.
For code depending on nettle internals, maybe you can use facilities in nettle/version.h (both compile time and runtime check would be appropriate, since changes to struct ecc_curve is no longer considered a change to the public abi, and will not imply an soname change or anything like that).
The problem is that both 3.5(.1) and master have same version. I just hope that we can get all ECC changes in single release.
ed25519 should not be directly tied to ABI compat. I'll take a look.
Should work now. The test message was misleading. It also was a GOST issue.
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
I've just pushed a change to the .gitlab-ci file, so I hope the next build looks better.
GnuTLS also received a MR to fix tests in minimal build, so next master-updates build should succeed.
It looks green now. Just merged those changes over to master. Please remind to remove --disable-gost when things have stabilized.
The problem is that both 3.5(.1) and master have same version. I just hope that we can get all ECC changes in single release.
Version checks on master will unfortunately never be quite reliable.
Regards, /Niels
чт, 21 нояб. 2019 г. в 22:22, Niels Möller nisse@lysator.liu.se:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
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.
ecc_point_set/_get() are fine from my point of view. I was working on internal ecc_point representation (w/o size changes).
Basically I have two strange curves which are defined in Weierstrass form, but have equivalent Untwisted Edwards form. I planned to make ecc_point_set/get convert between x,y and u,v,w (and to store these coordinates in ecc_point). To make things easier I also changed secp curves to store x,y,z in ecc_point.
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
Basically I have two strange curves which are defined in Weierstrass form, but have equivalent Untwisted Edwards form. I planned to make ecc_point_set/get convert between x,y and u,v,w (and to store these coordinates in ecc_point).
Then the internal representation would be plain limb arrays holding u, v, w in order. With individual coordinates in ordinary or montgomery representation, depending on what makes the reduce operation most efficient.
Now I'm getting unsure about what should go in the struct ecc_point limb array. But I think curve implementation has some room to choose it's preferred representation.
Regards, /Niels
пт, 22 нояб. 2019 г., 18:16 Niels Möller nisse@lysator.liu.se:
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
Basically I have two strange curves which are defined in Weierstrass form, but have equivalent Untwisted Edwards form. I planned to make ecc_point_set/get convert between x,y and u,v,w (and to store these coordinates in ecc_point).
Then the internal representation would be plain limb arrays holding u, v, w in order. With individual coordinates in ordinary or montgomery representation, depending on what makes the reduce operation most efficient.
Yes, I've implemented it exactly in this way.
Now I'm getting unsure about what should go in the struct ecc_point limb array. But I think curve implementation has some room to choose it's preferred representation.
Currently I have xyz for secp curves and uvw for edwards curves.
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
nettle-bugs@lists.lysator.liu.se
-
Dmitry Eremin-Solenikov -
nisse＠lysator.liu.se