There are now a couple of points left on the todo list for the next release (see http://www.lysator.liu.se/~nisse/nettle/plan.html). Basically:
* Complete the dsa reorg (I'd appreciate all comments on that).
* Make the nettle_cipher abstraction use a const context argument for encrypt and decrypt.
* Documentation updates.
This is going to be quite a large number of incompatible changes. I think it makes sense to name the new release 3.0, and announce it as a "typical" dot-zero release, which can be expected to have some serious.
To fix reported issues, we may need a 3.1 releqase reasonably soon after 3.0, and if required, 3.1 may include additional API or ABI fixes, together with new features. After 3.1, we should get back into a more normal development, and maintain backwards compatibility.
I think this will also be a good time to upgrade the license (currently LGPLv2 or later) to a dual license, LGPLv3 or later, or GPLv2 or later.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
- Complete the dsa reorg (I'd appreciate all comments on that).
Not much comments on these issues. I'm now leaning towards a split into dsa.h with the new interface (and unchanged pieces, like struct dsa_signature), and a dsa-compat.h, with the old, deprecated, interface. Both could be included, except that the meaning of the dsa_generate_keypair symbol will change with dsa-compat.h.
- Make the nettle_cipher abstraction use a const context argument for encrypt and decrypt.
In the mean time, I've done this. There are two typedefs, nettle_cipher_func (new, const ctx, used for the block ciphers), and nettle_crypt_func (unchanged, used for aead algorithms).
For the benchmark, I represent the stream ciphers (arcfour, salsa20, chacha) as nettle_aead structs, where the update and digest methods are NULL (and also set_nonce NULL, in the case of arcfour). Maybe that representation would make sense also for a public api, but I'll not add that now.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
nisse＠lysator.liu.se