I have been considering some improvements to ddumbfs which will make the on-disk format incompatible with the current code. As a result, I have also been considering other hashing functions and libraries to use. Below are a set of tables to show different hash functions, libraries and the speed that I was getting when running them on a Xeon E5-2609 CPU:
One thing that I discovered is that the mhash implementation of the TIGER has algorithm does not generate the correct hash value for a blank string (as shown on Wikipedia
4kb Block size:
| Library | SHA1 | TIGER128 | TIGER192 | SHA256 | SHA512/256 | SHA3-256 |
| mhash | 180 MB/s | 277 MB/s | 277 MB/s | 99 MB/s | ||
| libssl | 420 MB/s | 140 MB/s | 218 MB/s | |||
| rhash | 408 MB/s | 298 MB/s | 139 MB/s | 77 MB/s | ||
| sodium | 102 MB/s |
8kb Block size:
| Library | SHA1 | TIGER128 | TIGER192 | SHA256 | SHA512/256 | SHA3-256 |
| mhash | 184 MB/s | 284 MB/s | 285 MB/s | 99 MB/s | ||
| libssl | 425 MB/s | 141 MB/s | 220 MB/s | |||
| rhash | 420 MB/s | 304 MB/s | 140 MB/s | 78 MB/s | ||
| sodium | 103 MB/s |
16kb Block size:
| Library | SHA1 | TIGER128 | TIGER192 | SHA256 | SHA512/256 | SHA3-256 |
| mhash | 185 MB/s | 288 MB/s | 288 MB/s | 101 MB/s | ||
| libssl | 430 MB/s | 142 MB/s | 222 MB/s | |||
| rhash | 426 MB/s | 305 MB/s | 142 MB/s | 79 MB/s | ||
| sodium | 103 MB/s |