MetroHash: Faster, Better Hash Functions
jandrewrogers.com
jandrewrogers.com
5x faster depends on the context with such benchmarks. They are only useful for file or big buffer digests, but not for the general usage in a hash table, with small buffers and needed small code size. FNV1 still beats all those bigger hash functions, based on the new crc32c or aes intrinsics.
So, CityHash is deprecated. If you want to ask, ask about FarmHash, its successor. MetroHash beats it. MetroHash also beats xxHash64 in all aspects.
https://www.youtube.com/watch?v=wGYj8fhhUVA https://www.131002.net/siphash/
"Such an attack avoidance cannot not be the problem of the hash function, but the hash table collision resolution scheme. You can attack every single hash function, even the best, if you detect the seed, e.g. from the sort-order, so you need to protect your collision handling scheme from the worst-case O(n), i.e. separate chaining with linked lists. Linked lists chaining is also very cache-unfriendly."
You can flood even crypto hashes if used in a bad hash table based on linked lists, like perl, ruby, php or python and you can detect the seed. Read also https://github.com/rurban/perl-hash-stats#number-of-collisio... on some hints how to attack them. Only uhashes (pairs of random hashfuncs) would be resistant, but I count this as hash table scheme, not a hash function per se.
Why the worst? It's the slowest by far and has no other benefit. Look at the table overview. Those hash functions need to be fast.