Daiki Ueno <u...@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%20change
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. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
