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 writes:
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".
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.
There's a logic in keeping the things as they are, too. When SHA-1 was introduced, it supported only 160 bit size digests, so there was no need to mention the size explicitly. When SHA-2 appeared, it supported several sizes, but none of them coincided with the SHA-1's 160 bits, thus the “version” was apparent from the bit size. At last, came SHA-3, and being the later one, it has to bear its explicit version number.
[…]
fre 2012-11-30 klockan 12:56 +0700 skrev Ivan Shmakov:
Niels Möller writes:
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".
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.
There's a logic in keeping the things as they are, too. When SHA-1 was introduced, it supported only 160 bit size digests, so there was no need to mention the size explicitly. When SHA-2 appeared, it supported several sizes, but none of them coincided with the SHA-1's 160 bits, thus the “version” was apparent from the bit size. At last, came SHA-3, and being the later one, it has to bear its explicit version number.
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:
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
Quoting:
This Standard specifies secure hash algorithms - SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 - for computing a condensed representation of electronic data (message).
See also the wikipedia page, it never uses the term "sha2-256" but consistently use the term "SHA-256".
http://en.wikipedia.org/wiki/SHA-2
Is there any other authorative sources on SHA2 and what it should be called?
If the naming in Nettle isn't an obvious mistake, I would prefer not to change things. However, I don't really care strongly.
/Simon
Simon Josefsson simon@josefsson.org 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.
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.
Regards, /Niels
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.)
fre 2012-11-30 klockan 12:38 +0100 skrev Niels Möller:
Simon Josefsson simon@josefsson.org 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.
Even further than that, I think I'm saying that I would be inclined to disagree that SHA256 is a mistaken naming. What source do you have that says the name "SHA2-256" is the right name? From the sources I quoted, including FIPS 180-4, the name is "SHA256". I suggest, as a general rule, that naming should preferrably be consistent with what appears to be the most authorative specification available for each algorithm.
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.
Yes, doing that split makes sense to me. SHA256 etc doesn't have much in common with SHA1, so they belong in separate header files. Putting SHA256 in sha.h might have been the earlier mistake, if any. The initial mistake might have been calling the header file sha.h instead of sha1.h.
/Simon
Even further than that, I think I'm saying that I would be inclined to disagree that SHA256 is a mistaken naming. What source do you have that says the name "SHA2-256" is the right name? From the sources I quoted, including FIPS 180-4, the name is "SHA256". I suggest, as a general
Err, I meant "SHA-256", not "SHA256", of course.
/Simon
Simon Josefsson simon@josefsson.org writes:
The initial mistake might have been calling the header file sha.h instead of sha1.h.
Right. That was many years ago.
Regards, /Niels
Simon Josefsson simon@josefsson.org writes:
fre 2012-11-30 klockan 12:38 +0100 skrev Niels Möller:
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.
Yes, doing that split makes sense to me. SHA256 etc doesn't have much in common with SHA1, so they belong in separate header files.
I did that split the other day.
And while updating hash documentation, I also reorganized that section of the manual a bit.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Ivan Shmakov -
nisse＠lysator.liu.se -
Simon Josefsson