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
-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.