On Thu, Mar 13, 2014 at 11:22 AM, Niels Möller nisse@lysator.liu.se wrote:
These functions now take the parameters separately. One could get something more in style with the the old interface by defining #define dsa_sign(pub, key, [...]) dsa_sign(&pub->params, key->x, [...]) #define dsa_verify(pub, [...]) dsa_verify(&pub->params, pub->y, [...])
Hello, It would be nice if the new interface is api compatible with the old one; especially if that would be possible with macros such as the one you show, so that compatibility bloat doesn't need to be included in the library.
It seems reasonable to provide one key generation function which also generates parameters, and one key generation function which takes fixed parameters as argument. Any suggestion for naming? For compatibility, it would be preferable to keep dsa_generate_keypair unchanged, and invent a new name for the function above. /* Convenience structs, close to the interface used in nettle-2.7.x and earlier. */ struct dsa_public_key { struct dsa_params params; /* Public value */ mpz_t y; }; This is essentially the same struct as in earlier versions, but it wraps the parameters in a struct, so it's an API change. I think this is the sane way to do it, if this is viewed as an interface to be supported in future versions, and not just something retained for backwards compatibility.
I thought that this was used to keep API compatibility. I don't think it makes sense to introduce new APIs that are close to old APIs. There is already a new API.
int dsa_generate_keypair_old(struct dsa_public_key *pub, struct dsa_private_key *key,
void *random_ctx, nettle_random_func *random, void *progress_ctx, nettle_progress_func *progress, unsigned p_bits, unsigned q_bits);As said above, there's a naming issue here. I think it would be nice to keep this function with name and prototype unchanged.
If old sources can be compiled with no changes, I agree it should keep the same name. If not, I don't see many advantages of keeping an API that looks like the old but is not compatible with it. It will take up space, and require maintaining more code.
regards, Nikos