With support for SHA3, it seems clear that nettle's naming for sha2 functions was a mistake. It should be "sha2_256", rather than "sha256".
This is my current plan. Step 1 is as backwards compatible as practical, while step 2, to be taken at some later time, drops backwards compatibility.
Step 1:
* Split sha.h into sha1.h and sha2.h, and use the new names in sha2.h. Except for the name mangling, e.g.,
#define sha2_256_init nettle_sha256_init
not
#define sha2_256_init nettle_sha2_256_init
in order to maintain ABI compatibility.
* Keep sha.h for backwards compatibility. Have it include sha1.h and sha2.h, and use #define to make old names aliases for the new names.
* Do a thorough rename in the implementation; use new names for all internal use of sha2, rename files, etc.
* For all other interfaces where a sha2 function shows up in a name, e.g., hmac_sha256_set_key, and DSA_SHA256_MIN_P_BITS, rename for consistency and use #defines to make old names aliases.
* For nettle_hash, make the new name of the struct an alias for the old, e.g.,
#define nettle_sha2_256 nettle_sha256
but for now do *not* change the contents of the name. I.e., nettle_sha2_256.name will still contain the string "sha256", not "sha2_256".
Step 2:
* Delete sha.h, and the other compatibility aliases defined elsewhere.
* Do the rename also on library symbols, i.e., nettle_sha256_init -> nettle_sha2_256_init.
* Change the value of the name fields of the nettle_hash objects.
As far as I see, Step 1 maintains reasonably complete API and ABI compatibility. The only subtlety I'm aware of is C++ ABI compatibility for code *using* nettle, where I think
struct sha256_ctx;
vs
struct sha2_256_ctx; #define sha256_ctx sha2_256_ctx
would give different name mangling of C++ functions using arguments of this type (and not declared extern "C"). I think that is a problem that I'm going to ignore. Or do you think it is important enough to make the aliases for the struct tags the other way around?
Comments?
Regards, /Niels