4 ms·

Even when I've not needed a cryptographic hash, I've still used one, because why not? I've never not needed one so bad as to resort to some barely studied, home

Even when I've not needed a cryptographic hash, I've still used one, because why not? I've never not needed one so bad as to resort to some barely studied, homemade hashing algorithm. > A hash collision wouldn't matter that much. Interesting. What was the use for the hash function then?

ticki_ 10y ago
In hash tables, you never use cryptographic hash functions. Why? Because they're slower. Take SHA3, which is around 50x slower than SeaHash. That is really really bad for hash tables. When hash collisions happen in hash tables, they're resolved through collision-resolution strategy, such a linear proping. Fingerprints are one very narrow usecase for hash functions, and there are tousands of other uses.
jjaredsimpson 10y ago
> Even when I've not needed a cryptographic hash, I've still used one, because why not? To avoid wasting cpu cycles preserving a property you don't need. Seahash should be 50x faster than sha3
matt4077 10y ago
Caching often relies on hash functions. If you run the Cloudflare cache, you'll start caring, considering hashing is usually >50% of the CPU workload and an optimized non-cryptographic hash function can be 20x faster.
falcolas 10y ago
A trade off between collision potential vs. speed. Sometimes you need speed more than you need cryptographic levels of collision avoidance. For example, finding unique files on the file system. After looking at size, first and last bytes, it would be better to filter quickly on an imperfect hash (with, say, a 1 in 1^56 chance of collision) than slowly on a perfect hash (with a 1 in 1^256 chance).
- mdergosits 10y ago
  I hope you mean 2^56 and 2^256 :)
  - stcredzero 10y ago
    We can increase that by one to the fourth power! http://aperiodical.com/2013/05/the-maths-of-star-trek-the-original-series-part-iii/ http://aperiodical.com/2013/05/the-maths-of-star-trek-the-or...
zeveb 10y ago
> Even when I've not needed a cryptographic hash, I've still used one, because why not? Performance. Take a look at djb's (non-cryptographic) hash, with a constant multiplier chosen to be implemented with a shift and an add — that's the level of performance a non-cryptographic hash (e.g. for hash tables & similar purposes) needs. https://gist.github.com/hmic/1676398 https://gist.github.com/hmic/1676398
- ticki_ 10y ago
  Please don't. DJB2 is a poor hash function. It's similar to FNV: Entropy only moves upwards, so flipping higher bits doesn't affect lower bits. In other words, you risk mapping `n` and `-n` to the same value under some modulus.

ticki_ 10y ago

In hash tables, you never use cryptographic hash functions. Why? Because they're slower. Take SHA3, which is around 50x slower than SeaHash. That is really really bad for hash tables. When hash collisions happen in hash tables, they're resolved through collision-resolution strategy, such a linear proping. Fingerprints are one very narrow usecase for hash functions, and there are tousands of other uses.

jjaredsimpson 10y ago

> Even when I've not needed a cryptographic hash, I've still used one, because why not? To avoid wasting cpu cycles preserving a property you don't need. Seahash should be 50x faster than sha3

matt4077 10y ago

Caching often relies on hash functions. If you run the Cloudflare cache, you'll start caring, considering hashing is usually >50% of the CPU workload and an optimized non-cryptographic hash function can be 20x faster.

falcolas 10y ago

A trade off between collision potential vs. speed. Sometimes you need speed more than you need cryptographic levels of collision avoidance. For example, finding unique files on the file system. After looking at size, first and last bytes, it would be better to filter quickly on an imperfect hash (with, say, a 1 in 1^56 chance of collision) than slowly on a perfect hash (with a 1 in 1^256 chance).

mdergosits 10y ago
I hope you mean 2^56 and 2^256 :)
- stcredzero 10y ago
  We can increase that by one to the fourth power! http://aperiodical.com/2013/05/the-maths-of-star-trek-the-original-series-part-iii/ http://aperiodical.com/2013/05/the-maths-of-star-trek-the-or...

zeveb 10y ago

> Even when I've not needed a cryptographic hash, I've still used one, because why not? Performance. Take a look at djb's (non-cryptographic) hash, with a constant multiplier chosen to be implemented with a shift and an add — that's the level of performance a non-cryptographic hash (e.g. for hash tables & similar purposes) needs. https://gist.github.com/hmic/1676398 https://gist.github.com/hmic/1676398

ticki_ 10y ago
Please don't. DJB2 is a poor hash function. It's similar to FNV: Entropy only moves upwards, so flipping higher bits doesn't affect lower bits. In other words, you risk mapping `n` and `-n` to the same value under some modulus.