On Dec 23, 2016, at 11:26 AM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
An approach for Ron to overcome the specific problem could be to use wrappers over nettle which hide the details, such as the gnutls functions (e.g., gnutls_mac_fast etc.).
If gnutls has sutable wrappers for umac, that sounds like an easy solution, at least until needed interfaces are added to nettle.
I did run across gnutls when looking around for UMAC implementations. From what I can tell, gnutls only exposes UMAC 96 and 128, though, and I was hoping to be able to provide options for all of UMAC-32, -64, -96, and -128.
The more long term question, is should nettle be striving to provide an ABI? If not, it could transform to low-level library gnulib or ccan are (i.e. like a copy-lib)... or alternatively, if yes, provide a high level stable API which hides details and the ABI is easier to provide.
We could add a thin layer of functions involving only opaque pointers, byte strings, and ints. If we really want, it could be a separate .so-file, which could have an ABI more stable than nettle's. But I'm not sure if that's really solves Ron's problem of using the functions without depending on the header file. E.g, say we add a function like
void *mac_ctx_new(enum nettle_mac_algorithm);
and it's called like
void *umac_ctx = mac_ctx_new(NETTLE_ALGORITHM_UMAC);
And then the python glue loads libnettle.so, and wants to make this function call. How would it find the numeric value of NETTLE_ALGORITHM_UMAC? Would it duplicate the definitions in the C header (which is ok, since these constants are (i) part of the ABI and supposedly stable, and (ii) not architecture dependent), or would we need some interface using plain strings to identify algorithms?
Python’s approach to this in “hashlib” is to use string names to identify algorithms, so that would definitely be a good option here. I don’t really see a problem using a set of enum values here which got replicated in a Python wrapper to identify algorithms if the mapping was guaranteed to remain stable, but it wouldn’t be as easy to add new algorithms later. Numbers would need to be assigned for them, and both the Python and C code would have to be updated to know about these new numbers before the new algorithms could be used.
Since you already have string names defined in your meta structures, allowing a lookup by name doesn’t seem like much of a stretch. You could potentially provide both options, with a function to map the name to the enum value. This would be an extra step for a caller who wanted to do the name-based lookup, but that could be hidden inside the wrapper.