-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aloha!
I took a look at the code in sha256.c and have a couple of small comments.
(1) The K table is not zero extended. This just makes the table look weird:
K[64] = { 0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL, 0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL, 0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL, 0x72be5d74UL, 0x80deb1feUL, 0x9bdc06a7UL, 0xc19bf174UL, 0xe49b69c1UL, 0xefbe4786UL, 0xfc19dc6UL, 0x240ca1ccUL, 0x2de92c6fUL, 0x4a7484aaUL, 0x5cb0a9dcUL, 0x76f988daUL, 0x983e5152UL, 0xa831c66dUL, 0xb00327c8UL, 0xbf597fc7UL, 0xc6e00bf3UL, 0xd5a79147UL, 0x6ca6351UL, 0x14292967UL, 0x27b70a85UL, 0x2e1b2138UL, 0x4d2c6dfcUL, 0x53380d13UL, 0x650a7354UL, 0x766a0abbUL, 0x81c2c92eUL, 0x92722c85UL, 0xa2bfe8a1UL, 0xa81a664bUL, 0xc24b8b70UL, 0xc76c51a3UL, 0xd192e819UL, 0xd6990624UL, 0xf40e3585UL, 0x106aa070UL, 0x19a4c116UL, 0x1e376c08UL, 0x2748774cUL, 0x34b0bcb5UL, 0x391c0cb3UL, 0x4ed8aa4aUL, 0x5b9cca4fUL, 0x682e6ff3UL, 0x748f82eeUL, 0x78a5636fUL, 0x84c87814UL, 0x8cc70208UL, 0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL, };
I would suggest zero extending the table to get the same textual width of all elements.
(2) Pretty cool that you actually generate the constants from the FIPS 180 specification! Good verification.
(3) The SHA-224 H0-table refers to the _SHA256_DIGEST_LENGTH. This imho should be a separate define _SHA224_DIGEST_LENGTH. Yes, it is the same length in practice but it looks weird esp since the generated digest for SHA-224 is in fact not the same even though the internal diget state vector H is the same length as SHA-256.
(4) I'll think I'm going to ask on the SHA-3 maillist (hosted by NIST) if John Kelsey & Co can provide an explanation for the H0-constants used in SHA-224 and SHA-1 in the same way as for SHA-256, SHA-512 etc. It really is a bit peculiar that they don't.
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aloha!
(Answering my own mail, nice. ;-)
Joachim Strömbergson wrote:
(4) I'll think I'm going to ask on the SHA-3 maillist (hosted by NIST) if John Kelsey & Co can provide an explanation for the H0-constants used in SHA-224 and SHA-1 in the same way as for SHA-256, SHA-512 etc. It really is a bit peculiar that they don't.
I've done this and got a response from Thomas Pornin. The problem with FIPS 180 (including the latest versio 180-4) is that the H0 values for SHA-1 and SHA-224 lack a stated explanation. Something that exists in the document for SHA-256, SHA-384 etc.
For SHA-1 the H0 constants are a simple sequence pattern and according to Thomas actually comes from MD5. Looking at the pattern it is quite clear that it is in fact a big endian sequence:
(From sha1.c in Nettle):
/* SHA initial values */ 0x67452301L, 0xEFCDAB89L, 0x98BADCFEL, 0x10325476L, 0xC3D2E1F0L,
Reading the bytes backwards and right-left it is 0..F and then an down-up pattern with high nybble going down and low nybble going up.
The H0-values for SHA-224 is actually the low 32-bits of the H0-values for SHA-384. An easy comparison between the values in chapter 5.3.4 of FIPS 180-4 and chapter 5.3.2 makes it obvious. And for SHA-384 NIST in chapter 5.3.4 states:
"These words were obtained by taking the first sixty-four bits of the fractional parts of the square roots of the ninth through sixteenth prime numbers."
We should therefore be able to update the shadata program to generate the SHA-224 constants.
Suggestion: Change the comments in sha256.c (for sha224) to point to the origin of the constants. And also add a short comment in sha1.c and md5.c that the constants are simple patterns.
According to Thomas the sequence pattern in md5 was choosen by Rivest quite arbitrarily.
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================
Joachim Strömbergson joachim@secworks.se writes:
For SHA-1 the H0 constants are a simple sequence pattern and according to Thomas actually comes from MD5.
(From sha1.c in Nettle):
/* SHA initial values */ 0x67452301L, 0xEFCDAB89L, 0x98BADCFEL, 0x10325476L, 0xC3D2E1F0L,
The first four values are the same as for md5. The final value is unique to sha1.
The H0-values for SHA-224 is actually the low 32-bits of the H0-values for SHA-384.
Interesting, I hadn't noticed that.
We should therefore be able to update the shadata program to generate the SHA-224 constants.
The reason sha512 and sha384 aren't generated by shadata.c, is that the needed precision exceeds what can be expected from a C double. And for sha224, if it had been the *high* 32 bits, double would have been enough.
Now that we include mini-gmp, I guess one could make use of that to compute the needed roots to high enough precision.
Suggestion: Change the comments in sha256.c (for sha224) to point to the origin of the constants. And also add a short comment in sha1.c and md5.c that the constants are simple patterns.
I've added comments for sha1 and sha224.
According to Thomas the sequence pattern in md5 was choosen by Rivest quite arbitrarily.
Not much to comment there...
Regards, /Niels
Joachim Strömbergson joachim@secworks.se writes:
(1) The K table is not zero extended. This just makes the table look weird:
I'll add a %08lx format to shadata.c.
(3) The SHA-224 H0-table refers to the _SHA256_DIGEST_LENGTH. This imho should be a separate define _SHA224_DIGEST_LENGTH. Yes, it is the same length in practice but it looks weird
Maybe this constant is misnamed. It's the size of the *internal* state, which for sha224 (and sha384) is unrelated to the output digest size. It's defined in the public sha2.h header only because it's the size of the state array in struct sha256_ctx. And a separate define for sha224 makes little sense, because there is no separate struct sha224_ctx, it's just a #define alias for sha256_ctx.
Regards, /Niels
Aloha!
3 jan 2014 kl. 21:27 skrev nisse@lysator.liu.se (Niels Möller):
(3) The SHA-224 H0-table refers to the _SHA256_DIGEST_LENGTH. This imho should be a separate define _SHA224_DIGEST_LENGTH. Yes, it is the same length in practice but it looks weird
Maybe this constant is misnamed. It's the size of the *internal* state, which for sha224 (and sha384) is unrelated to the output digest size. It's defined in the public sha2.h header only because it's the size of the state array in struct sha256_ctx.
Yes, exactly. The name is confusing
And a separate define for sha224 makes little sense, because there is no separate struct sha224_ctx, it's just a #define alias for sha256_ctx.
Clean code. It makes sense because for the user it is a different algorithm even though it shares a lot of the guts with SHA-256. An alias is enough just like a define that actually define the same size of the state. Imho.
Regards, /Niel
-- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
nettle-bugs@lists.lysator.liu.se
-
Joachim Strömbergson -
nisse＠lysator.liu.se