On Thu, Mar 13, 2014 at 11:22 AM, Niels Möller <[email protected]> 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
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
