It seems that the "Keccak" algorithm is now SHA-3: http://www.nist.gov/itl/csd/sha-100212.cfm
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It seems that the "Keccak" algorithm is now SHA-3: http://www.nist.gov/itl/csd/sha-100212.cfm
I've had a look at the paper and the reference implementation (http://keccak.noekeon.org/Keccak-reference-3.0.pdf and http://keccak.noekeon.org/KeccakReferenceAndOptimized-3.2.zip).
I think it may be easiest to write some new code based on the pseudocode description at http://keccak.noekeon.org/specs_summary.html.
I've also downloaded the test vectors http://keccak.noekeon.org/KeccakKAT-3.zip and I'll see if I can make sense of them. It would have been nice if the zip files had included a readme file...
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I think it may be easiest to write some new code based on the pseudocode description at http://keccak.noekeon.org/specs_summary.html.
I just commited an initial implementation. With this code, sha3-256 is about an order of magnitude slower than either sha1 or sha2. I haven't yet thought carefully on how to optimize it; I think the current indexing can be simplified a bit, and it would make sense to unroll some of the shorter loops inside the round loop (not sure it makes sense to completely unroll everything except the outer loop).
For naming: I called it sha3_256 (since in nettle "sha256" is sha2. I guess we should have named it sha2_256 back then). Any other suggestions?
I haven't looked into other types of uses. E.g, does hmac-sha3 make sense? The Keccak paper mentions keyed modes of operation, maybe that would be preferable.
I put the interface declarations in sha3.h. I think it makes for better consistency if we split the current sha.h into sha1.h and sha2.h (and then we can keep a deprecated sha.h including both, for backwards compatibility).
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
I think the current indexing can be simplified a bit, and it would make sense to unroll some of the shorter loops inside the round loop
I've now done some microoptimizations along those lines, doubling the performance on x86_64. I now get
Algorithm mode Mbyte/s sha224 update 68.82 sha256 update 68.83 sha384 update 105.55 sha512 update 105.56 sha3_256 update 29.04
(before I had 12 Mbyte/s).
Not sure how to go about assembly implementation, some, but far from all, of the steps can make use of SSE2 SIMD instructions.
Regards, /Niels
On Mon, Nov 12, 2012 at 10:21 PM, Niels Möller nisse@lysator.liu.se wrote:
nisse@lysator.liu.se (Niels Möller) writes:
I think it may be easiest to write some new code based on the pseudocode description at http://keccak.noekeon.org/specs_summary.html.
For naming: I called it sha3_256 (since in nettle "sha256" is sha2. I guess we should have named it sha2_256 back then). Any other suggestions?
sha3_256, sounds clear enough.
I haven't looked into other types of uses. E.g, does hmac-sha3 make sense? The Keccak paper mentions keyed modes of operation, maybe that would be preferable.
Maybe it is better to wait and see how it is used as a MAC in protocols then.
I put the interface declarations in sha3.h. I think it makes for better consistency if we split the current sha.h into sha1.h and sha2.h (and then we can keep a deprecated sha.h including both, for backwards compatibility).
Sounds good.
regards, Nikos
nisse@lysator.liu.se (Niels Möller) writes:
I just commited an initial implementation.
Just a warning, it appears not to work at all on big-endian (in particular it failed when I tested a 32-bit sparc build). No big problems, so I think I'll check in fixes soon.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se