Daniel Kahn Gillmor dkg@fifthhorseman.net 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