sha3 vs tiny-keccak

I noticed in sn_api Cargo.toml there are 2 different crates for the same thing, sha3 and tiny-keccak both provide the same hash functionality. Turns out there’s a good reason for it, but I got curious if we did have the chance to consolidate which one to use.

In the end, tiny-keccak was the faster lib.

100 bytes input, 10K tests. Values are nanoseconds per hash

crate min median average max
sha3 602 670 714.6 21224
tiny-keccak 554 618 653.74 48502

Using the median, tiny-keccak is about 7.8% faster. Not a lot, but that’s about 1h51m difference over 24h of hashing, so it’s not completely unimportant.

1 MB input, 10K tests. Values are nanoseconds per hash

crate min median average max
sha3 3255550 4157527.5 4259370.89 9443800
tiny-keccak 3152116 4151925.5 4235831.5 10022048

The median has tiny-keccak at about 0.13% faster so that’s pretty close, about 1m56s difference over 24h of hashing.

I did remove one of the libraries for the fun of it (turned out tiny-keccak was much easier to remove so I did that) and the difference in file size was about 90K, but increased in size after removal. Probably to do with adding in sha3_512 which must be much smaller in tiny-keccak than sha3.

When testing bls performance in this post, blst (which does hashes with assembly) is much faster than threshold_crypto (which does hashes with tiny-keccak), so I hoped to be able to test the blst hashing too. But it’s a difficult library to hack on, so I didn’t get to it. I’m also not sure if blst is using sha2 or sha3, anyone able to compare the sources? Here’s a link to blst/sha256.h and blst/ if anyone’s keen. I’m pretty sure it’s sha2, judging from their use of Intel SHA Extensions, which would also explain the speed of blst compared to threshold_crypto.