I'm thinking about Nettle releases. I think it would be nice to get out a maintenance 3.10 release before summer vacations. (current NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly accurate).
After that, there are two different directions:
* Try to clean up some of the API issues. This will break the API (and like for previous changes, it could make sense to add foo-compat.h include files that supports old API, to make it easy to upgrade an application to work with the new nettle version, while incrementally adjusting to the new api). It may also break ABI and imply an soname change, or we could keep old symbols working for the case of old applications linking to new libnettle.so (but not the other way round, as documented at https://www.lysator.liu.se/~nisse/nettle/nettle.html#Compatibility). If we go this way, that would be a Nettle-4.0, and it would make sense to me to try to get that done without much new features, and without making it a huge long-term project.
* Focus on getting post-quantum algorithms into Nettle.
What do you think?
Regards, /Niels
Hello Niels,
Niels Möller nisse@lysator.liu.se writes:
I'm thinking about Nettle releases. I think it would be nice to get out a maintenance 3.10 release before summer vacations. (current NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly accurate).
That would be awesome.
After that, there are two different directions:
- Try to clean up some of the API issues. This will break the API (and like for previous changes, it could make sense to add foo-compat.h include files that supports old API, to make it easy to upgrade an application to work with the new nettle version, while incrementally adjusting to the new api). It may also break ABI and imply an soname change, or we could keep old symbols working for the case of old applications linking to new libnettle.so (but not the other way round, as documented at https://www.lysator.liu.se/~nisse/nettle/nettle.html#Compatibility). If we go this way, that would be a Nettle-4.0, and it would make sense to me to try to get that done without much new features, and without making it a huge long-term project.
I have a bit of concern, if an application links to nettle, but also bundles some parts of it to support lower nettle versions, that would make it difficult to import the code[1] as it would require pulling in dependent files.
That said, none of the issues marked as "API change" on the issue tracker looks too disruptive to me (maybe #2 and #5 are): https://git.lysator.liu.se/nettle/nettle/-/issues/?label_name%5B%5D=API%20ch...
Do you have anything else in your mind?
- Focus on getting post-quantum algorithms into Nettle.
From GnuTLS perspective, it would be helpful if there is support for at least one post-quantum KEM algorithm so it could make TLS handshake provide quantum safety and forward secrecy (with PSK). Signature algorithms could be done later.
Regards,
Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/master/devel/import-from-nettle.sh
Daiki Ueno ueno@gnu.org writes:
That said, none of the issues marked as "API change" on the issue tracker looks too disruptive to me (maybe #2 and #5 are): https://git.lysator.liu.se/nettle/nettle/-/issues/?label_name%5B%5D=API%20ch...
I think #2, "Drop the length argument from all hash and mac digest functions", is the one that is hardest to do with some backwards compatibility. Keeping old variants of the *_digest functions themselves should be doable, but we'd also change the nettle_hash_digest_func typedef, which is an incompatible change to the nettle_hash and nettle_mac structs, all instances of them, and the corresponding algorithm lists.
And it sounds rather cumbersome to define alternate types, struct instances and algorithm lists that are backwards compatible, like a
#define nettle_get_hashes() nettle_get_hashes_compat()
that fully supports the old conventions (and potentially do symbol naming so that abi is unbroken too; there are some subtle issue, e.g., struct names could leak into abi of C++ libraries depending on Nettle, due to C++ name mangling; is that a problem that must be solved, or if unsolved, that requires an soname bump?). Putting effort into backwards compatibility could be worth it, if it makes upgrade path for applications less steep?
Do you have anything else in your mind?
Generalizing https://git.lysator.liu.se/nettle/nettle/-/issues/3 "Rework interface for RSA private key operations" to change all public interfaces taking mpz_t values to take octet strings instead. But I think attempting to fix that at the same time is a too large scope. To make progress, I think it would make sense with one release only reworking the libnettle api/abi. And to rework of lib hogweed abi/api as a separate project.
- Focus on getting post-quantum algorithms into Nettle.
From GnuTLS perspective, it would be helpful if there is support for at least one post-quantum KEM algorithm so it could make TLS handshake provide quantum safety and forward secrecy (with PSK). Signature algorithms could be done later.
That's my understanding too, that the current main worry is forward secrecy of protocols that use key exchange methods that are vulnerable to an attacker with a quantum computer.
Regards, /Niels
Niels Möller nisse@lysator.liu.se writes:
- Focus on getting post-quantum algorithms into Nettle.
From GnuTLS perspective, it would be helpful if there is support for at least one post-quantum KEM algorithm so it could make TLS handshake provide quantum safety and forward secrecy (with PSK). Signature algorithms could be done later.
That's my understanding too, that the current main worry is forward secrecy of protocols that use key exchange methods that are vulnerable to an attacker with a quantum computer.
While encryption may be more urgent, it takes a lot of time for algorithms to permeate standards and implementations, and there are long-term support distributions with 10 years of support or more. For example, Red Hat's signing infrastructure is limited to what their oldest supported release can consume.
I asked in 87sf5daacn.fsf@thinkbox for the PQC algorithms that we'll need for the upcoming PQC extensions to OpenPGP. Unfortunately, that mail is not available in the nettle-bugs archive, but can be found here: https://marc.info/?l=nettle-bugs&m=169963043712268&w=2
Since then, the draft has been adopted by the working group, and is available here:
https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
The set of PQC algorithms has not changed, we need ML-KEM, ML-DSA, and SLH-DSA. The draft dropped KMAC in favor of SHA3 as key combiner, so we (likely) don't need KMAC anymore.
I have seen the proposed implementation of ML-KEM (big thanks!), but unfortunately didn't have the time to try it out yet. If I do, I'll send feedback.
Best, Justus
Niels Möller nisse@lysator.liu.se writes:
I'm thinking about Nettle releases. I think it would be nice to get out a maintenance 3.10 release before summer vacations. (current NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly accurate).
I've published a release candidate at
http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc1.tar.gz.sig
I've also extended the expire date on the release signing key, http://www.lysator.liu.se/~nisse/archive/distribution-key.gpg
Testing is highly appreciated, in particular on systems not covered by the CI system (running at the gitlab.com mirror at https://gitlab.com/gnutls/nettle). I aim to make the release during the coming weekend.
Regards, /Niels
Niels Möller nisse@lysator.liu.se writes:
I've published a release candidate at
http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc1.tar.gz.sig
I've found one packaging bug: The new sc-*-test files didn't make it into the distribution archive. Made a new set of files,
http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc2.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc2.tar.gz.sig
Regards, /Niels
Hi :)
Niels Möller nisse@lysator.liu.se writes:
http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc2.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.10rc2.tar.gz.sig
FWIW, I tested these on AMD64 and Arm64 using our Rust bindings for Nettle, and the sequoia-openpgp test suite. I discovered no problems.
Best, Justus
nettle-bugs@lists.lysator.liu.se
-
Daiki Ueno -
Justus Winter -
Niels Möller