Daniel Kahn Gillmor <[email protected]> writes:
> This also means that newer versions of the perl bindings won't work by
> default against older versions of libnettle,
I don't know how the build system for the perl bindings is setup, but
using something like autoconf should make it easier if you really want
to support multiple nettle versions, with or without public key support.
> The attached patch would present an interface to dynamically enumerate
> the available ciphers and digest algorithms (and armor methods)
> supported by the current version of libnettle.
The need for this hasn't occured to me, but I see the point. What do
others think?
> bindings built against
> this meta-interface wouldn't need to be closely tied to any particular
> version of nettle, and so could be both forward- and backward-compatible.
But some other parts of the nettle interfaces have not been as stable
between releases, so it doesn't solve the problem completely.
> I'd be happy with any other interface that would give me the same
> effect, of course, and i'm not convinced that this is the best way to do
> it -- it just seemed the simplest in the current implementation.
Right, it's about as simple as one can get, and I like that. I think one
level of indirection like you do is desirable, for linking reasons.
One may want to think about fancy hardware accelerators (currently not
supported at all), which would require some runtime check on what's
available.
> It would also be nice to make a similar interface to genericize cipher
> modes (ECB, CBC, CTR, and GCM), if that's possible; i'm not sure what
> the best approach is for doing that.
I'm not sure this is as useful. The modes have different properties and
generally don't work well as substitutes for each other. And at least,
the list is expected to be expanded less frequently than the list of
hashes or block ciphers.
Some comments on the implementation:
> +const struct nettle_armor *nettle_armors[] = {
> + &nettle_base64,
> + &nettle_base16,
> + NULL
> +};
The typing should be something like
const struct nettle_armor * const nettle_armors[]
to say that both the list itself and the pointed to structures are
const.
Also, I think there should be one compilation unit and object file per
list, so that it's, for example, possible to statically link with the
list of all hash algorithms without also dragging in all ciphers.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
