Niels Möller writes: Simon Josefsson writes: fre 2012-11-30 klockan 12:56 +0700 skrev Ivan Shmakov:
While such a step would be logical, I'd like to note that while SHA-2 algorithms are widely known as SHA-256, etc., it's the SHA3-256, etc. forms that seems to be preferred for SHA-3.
I am inclined to agree — the name "SHA256" seems to be more popular than "SHA2-256" or even "SHA2" according to Google hits. Grep RFCs that use the term "SHA256" and that is also the more common usage. Going back to the NIST specification:
If the naming in Nettle isn't an obvious mistake, I would prefer not to change things. However, I don't really care strongly.
If I may rephrase what you're both saying, it's that everybody else seems to be using the "mistaken" naming, and then it makes more sense for Nettle to stick to that common usage. That argument makes sense to me; maybe I got a bit carried away.
The point is that back when SHA-2 was designed, there was no need to name its individual variants SHA2-224, SHA2-256, etc. Perhaps if SHA-3 was anticipated at that time, a more generic name scheme would have been devised. It didn't happen, however, and SHA-2 variants are known as SHA-224, SHA-256, etc., and are likely to be known under these names from now and forever (as long as the algorithms remain in use, that is.) It isn't a “mistake” — just the history.
I think I'd still like to do the header split, sha.h -> sha1.h and sha2.h, for better consistency within Nettle, but that's less intrusive, and backwards compatibility is trivial, with a sha.h including both.
FWIW, I see nothing wrong in such a change. (And, actually, see something right in it.)