The attached two patches update SHA3 to the final published version.
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached two patches update SHA3 to the final published version.
Thanks! Sorry I've been a bit silent during the summer, I've been on a long and partly offline vacation, and I'm going off again tomorrow and over the weekend.
I really appreciate your work on sha3, it's pretty important. I'll review the patches when I get back.
A question for the list: Is there any use of the current sha3 code (which is the hash algorithm at the time keccak won the sha3 competition)? Do we need to keep some kind of support for that algorithm, or can we just drop it and do standard sha3 only?
Regards, /Niels
On Wed, Aug 12, 2015 at 5:05 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached two patches update SHA3 to the final published version.
Thanks! Sorry I've been a bit silent during the summer, I've been on a long and partly offline vacation, and I'm going off again tomorrow and over the weekend. I really appreciate your work on sha3, it's pretty important. I'll review the patches when I get back. A question for the list: Is there any use of the current sha3 code (which is the hash algorithm at the time keccak won the sha3 competition)? Do we need to keep some kind of support for that algorithm, or can we just drop it and do standard sha3 only?
Not for my use cases. What I worry most is how would applications detect the correct sha3 being in place? Would there be a new definition in the header or should applications check the nettle version number? (if it is the latter it means that I cannot have a hot fix in Fedora for example, unless there is a new release).
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Not for my use cases. What I worry most is how would applications detect the correct sha3 being in place?
I'm not sure how it should be handled. If we think of it as a bugfix, the soname would be the same, and some applications using sha3 might want some runtime check. For the serpent byteorder fix (nettle-2.2), we didn't bump the soname.
The important question is, what applications are using Nettle's current sha3 code? https://codesearch.debian.net/search?q=sha3_%5B0-9%5D*_update finds only the Haskell bindings. Are there any Haskell people on this list who can comment on any need for bug-compatibility?
Would there be a new definition in the header or should applications check the nettle version number?
For compile-time check, we could add an
#define NETTLE_SHA3_NIST 1
in sha3.h. Would that be of any help for applications? For runtime checks, I think the simple (but not very beautiful) way is to hash the empty string and look at the output.
(if it is the latter it means that I cannot have a hot fix in Fedora for example, unless there is a new release).
I'm afraid it will cause confusion to fix this without increasing the version number in some way. Do you think that a nettle-3.2 release (with fixed sha3, and a couple of other smaller changes) is needed soon?
Regards, /Niels
On Wed, Aug 19, 2015 at 1:14 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
Not for my use cases. What I worry most is how would applications detect the correct sha3 being in place?
I'm not sure how it should be handled. If we think of it as a bugfix, the soname would be the same, and some applications using sha3 might want some runtime check. For the serpent byteorder fix (nettle-2.2), we didn't bump the soname.
No I also don't think we need to bump the soname. nettle_version_major() and nettle_version_minor() could be used for runtime checks.
The important question is, what applications are using Nettle's current sha3 code? https://codesearch.debian.net/search?q=sha3_%5B0-9%5D*_update finds only the Haskell bindings. Are there any Haskell people on this list who can comment on any need for bug-compatibility?
Would there be a new definition in the header or should applications check the nettle version number?
For compile-time check, we could add an #define NETTLE_SHA3_NIST 1
That would be best.
in sha3.h. Would that be of any help for applications? For runtime checks, I think the simple (but not very beautiful) way is to hash the empty string and look at the output.
I wouldn't really want applications to do that. The best would be to depend on nettle 3.2 and if they really want compatibility with 3.1 then they should use the nettle_version_xxx() functions.
I'm afraid it will cause confusion to fix this without increasing the version number in some way. Do you think that a nettle-3.2 release (with fixed sha3, and a couple of other smaller changes) is needed soon?
That would be really helpful.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached two patches update SHA3 to the final published version.
--- a/testsuite/sha3-224-test.c +++ b/testsuite/sha3-224-test.c @@ -1,775 +1,1259 @@ #include "testutils.h"
void -test_main(void) +test_main (void) { /* Extracted from ShortMsgKAT_224.txt using sha3.awk. */
- test_hash(&nettle_sha3_224, /* 0 octets */
SHEX(""),SHEX("F71837502BA8E10837BDD8D365ADB85591895602FC552B48B7390ABD"));
Did you create the testcases in the same way, using sha3.awk? Where are the updated ShortMsgKAT_*.txt files? Or did you use some other method?
diff --git a/sha3.c b/sha3.c index 84bc7ea..24581db 100644 --- a/sha3.c +++ b/sha3.c @@ -94,7 +94,7 @@ _sha3_pad (struct sha3_state *state, unsigned block_size, uint8_t *block, unsigned pos) { assert (pos < block_size);
- block[pos++] = 1;
block[pos++] = 6;
memset (block + pos, 0, block_size - pos); block[block_size - 1] |= 0x80;
Looks simple enough ;-) As I understand it, after a quick look at the final spec, message padding used to be the bit pattern 100...001, and now it's 01100..001, where the initial "01" are spcific to using the Keccac permutation for SHA3, for "domain separation".
Have NIST published a summary of their changes?
Regards, /Niels
On Wed, Aug 19, 2015 at 12:24 PM, Niels Möller nisse@lysator.liu.se wrote:
Did you create the testcases in the same way, using sha3.awk? Where are the updated ShortMsgKAT_*.txt files? Or did you use some other method?
I used sha3.awk, and then run indent.
Looks simple enough ;-) As I understand it, after a quick look at the final spec, message padding used to be the bit pattern 100...001, and now it's 01100..001, where the initial "01" are spcific to using the Keccac permutation for SHA3, for "domain separation". Have NIST published a summary of their changes?
Didn't find any.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
On Wed, Aug 19, 2015 at 12:24 PM, Niels Möller nisse@lysator.liu.se wrote:
Did you create the testcases in the same way, using sha3.awk? Where are the updated ShortMsgKAT_*.txt files? Or did you use some other method?
I used sha3.awk, and then run indent.
I'd like to include a link to the testvectors used for input. Where did you get the updated ShortMsgKAT_*.txt?
Regards, /Niels
On Sat, Aug 22, 2015 at 7:33 PM, Niels Möller nisse@lysator.liu.se wrote:
On Wed, Aug 19, 2015 at 12:24 PM, Niels Möller nisse@lysator.liu.se wrote:
Did you create the testcases in the same way, using sha3.awk? Where are the updated ShortMsgKAT_*.txt files? Or did you use some other method?
I used sha3.awk, and then run indent.
I'd like to include a link to the testvectors used for input. Where did you get the updated ShortMsgKAT_*.txt?
I believe I took them from: http://keccak.noekeon.org/files.html
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I believe I took them from: http://keccak.noekeon.org/files.html
The latest testvectors I find there are http://keccak.noekeon.org/KeccakKAT-3.zip, which seem to be the old version, SHA3-256("") == C5D2460186F7233C927E7DB2DCC703C0E500B653CA82273B7BFAD8045D85A470.
Hmm. Looks like the updated testvectors now live at at https://github.com/gvanas/KeccakCodePackage/tree/master/TestVectors
E.g., https://github.com/gvanas/KeccakCodePackage/blob/master/TestVectors/ShortMsg... says that SHA3-256("") == A7FFC6F8BF1ED76651C14756A061D662F580FF4DE43B49FA82D80A4B80F8434A.
Regards, /Niels
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached two patches update SHA3 to the final published version.
Committed and pushed now. Thanks!
I reformatted the testsuite files, to get saner diffs to the previous version. I also added a define NETTLE_SHA3_FIPS202 to sha3.h.
Regards, /Niels
On Tue, Aug 25, 2015 at 9:49 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached two patches update SHA3 to the final published version.
Committed and pushed now. Thanks! I reformatted the testsuite files, to get saner diffs to the previous version. I also added a define NETTLE_SHA3_FIPS202 to sha3.h.
I was wondering whether we should also add an HMAC API for SHA3. While it is easy to do a MAC from SHA-3 only HMAC is defined in FIPS202. Attached you'll find an initial patch, but unfortunately I could find no test vectors to verify.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I was wondering whether we should also add an HMAC API for SHA3. While it is easy to do a MAC from SHA-3 only HMAC is defined in FIPS202.
Technically, it makes more sense to do sha3-based mac without hmac. But if hmac-sha3 is the standardized way, we might need to support that. I guess there aren't any applications of hmac-sha3 yet?
In Sec 7. "Conformance" in FIPS202, it says that HMAC is "One of the approved uses of cryptographic hash functions", and then it specifies the block sizes for the sha3 hashes (Table 3) so that hmac is well defined.
But I don't read that as recommending that anyone should use hmac-sha3. And I think this table was added in response to one of the comments (http://csrc.nist.gov/groups/ST/hash/sha-3/documents/fips202_comments/Rombout...)
Attached you'll find an initial patch, but unfortunately I could find no test vectors to verify.
Maybe implementation of hmac-sha3 could wait until there's some specification of it including test vectors?
Regards, /Niels
On Wed, Aug 26, 2015 at 10:29 AM, Niels Möller nisse@lysator.liu.se wrote:
Attached you'll find an initial patch, but unfortunately I could find no test vectors to verify.
Maybe implementation of hmac-sha3 could wait until there's some specification of it including test vectors?
Yes, let's not delay sha3 being fixed because of hmac.
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se