PeterWhittaker
15 hours ago
I’ve read the first several paragraphs and skimmed the article a few times, and the motivation still eludes me: given the existence of cryptographic hash functions that are well designed and thoroughly tested, why spend so much time on non-cryptographic hash functions?
What benefits do they provide that are not provided by their secure “brethren”?
twiss
15 hours ago
Better performance. For a hash table, a cryptographic hash function is overkill (i.e. spends a lot of time to provide security properties that are not needed).
bsder
15 hours ago
> For a hash table, a cryptographic hash function is overkill (i.e. spends a lot of time to provide security properties that are not needed).
Except, as we quickly find out, attackers can often exploit a non-cryptographic hash to create a denial of service attack.
The problem is that if my hash function is really a performance bottleneck, I'm probably better off using a really shitty hash function that exploits some feature of the data being stored that is "good enough" but super fast. In that case, even a non-crypto hash function won't be fast enough.
Finally, hash tables result in "random-ish" memory access patterns. On a modern processor, random memory access is so horrifically slow that you may get superior performance by changing data structures to something with a much more linear access pattern and dumping the idea of hash tables altogether.
twiss
14 hours ago
There is a middle ground possible as mentioned in the paper, e.g. SipHash is a non-cryptographic hash function that provides security against DoS against attacks.