3 ms·
> I will quickly explain some of the basics of hash function security and then show how easy it is to break this security for some commonly used non-cryptograph
by TacticalCoder 2y ago
> I will quickly explain some of the basics of hash function security and then show how easy it is to break this security for some commonly used non-cryptographic hash functions.
OK so non-cryptographic hashes pretend to have security now?
> A lot of problems don’t necessarily require secure hash functions, and people would much prefer a faster hash speed.
Ah wait: no you're saying that instead of using a cryptographic hash, one may not require a secure hash so may pick a non-cryptographic hash. So now you're saying that non-cryptographic hashes aren't secure.
So which one is it? Are non-cryptographic hashes secure or not?
Because if they're not secure, I don't see which security there is to be broken there.
I was there when all the Java and PHP webservers could be DoS due to collisions. I don't dispute it's doable to find collision in a non-cryptographic hash.
But I'm not sure I'd define finding collisions in a non-cryptographic hash as "breaking its security".
- rcxdude 2y agoI think the point is "here's the desired properties for a cryptographic hash, and here's a practical demonstration of how non-cryptographic hashes don't have them". I don't think this is meant to be a surprising outcome if you know about the definition of cryptographic hashes, more just an interesting demonstration of how specifically non-cryptographic hashes are non-cryptographic.
- jnwatson 2y agoI think you have to give the author a little credit. Sometimes developers pick a non-cryptographic hash and they don't realize they actually need collision resistance, e.g. because an attacker-controlled input can cause an O(1) hash table operation to go O(n). These kinds of articles are great for red teams, since they actually have to demonstrate the problem instead of just switching out the algorithm.