SHA-3 in GNU/Linux
Looks like rhash(1) has finally made the necessary adjustment for
"--sha3-*" to fit the FIPS 202 standard draft as of version
1.3.3.
The hashes of the empty string according to the draft:
SHA3-224("") 0x 6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7
SHA3-256("") 0x a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
SHA3-384("") 0x 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004
SHA3-512("") 0x a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26
And, using rhash(1), they come out the same:
$ for H in sha3-224 sha3-256 sha3-384 sha3-512; do echo -n '' | rhash --$H -; done
6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7 (stdin)
a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a (stdin)
0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004 (stdin)
a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26 (stdin)
The hashes of the empty string according to the draft:
SHA3-224("") 0x 6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7
SHA3-256("") 0x a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
SHA3-384("") 0x 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004
SHA3-512("") 0x a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26
And, using rhash(1), they come out the same:
$ for H in sha3-224 sha3-256 sha3-384 sha3-512; do echo -n '' | rhash --$H -; done
6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7 (stdin)
a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a (stdin)
0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004 (stdin)
a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26 (stdin)
Looks like rhash(1) is twice as slow as the SHA-2 tools:
$ ls -lh cm-10.2.1-d2spr.zip
-rw-r--r-- 1 aaron aaron 183M May 22 21:56 cm-10.2.1-d2spr.zip
$ time sha256sum cm-10.2.1-d2spr.zip
757c0d65c29fdff36d6083710803dcf313a922d476ac4a8f67c4ab15e22017ea cm-10.2.1-d2spr.zip
sha256sum cm-10.2.1-d2spr.zip 1.95s user 0.16s system 72% cpu 2.929 total
$ time rhash --sha3-256 cm-10.2.1-d2spr.zip
f375e211b151a248e527f53de3b4a90f7498614674810917f79dcee38e632f8c cm-10.2.1-d2spr.zip
rhash --sha3-256 cm-10.2.1-d2spr.zip 3.83s user 0.19s system 79% cpu 5.077 total
This is pretty consistent. This is unfortunate, because SHA-3 should be using less cycles per byte per the original Keccak specification. Looks like a patch should be submitted to rhash(1).