Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

nobody? This exact problem was a massive issue within the year.

https://www.securityweek.com/hash-table-collision-attacks-co...



Using a slower hash would make the issue worse (linearly): the collisions would still be there, but now each insertion would take even more time due to the extra computational cost of the hash.


[deleted]


EDIT: parent basically said "use a cryptographic hash".

You need some kind of random salt, too - it's not that hard to find a decent number of near-collisions even in cryptographic hashes. (E.g. if your hash table doubles in size whenever two keys end up in the same bucket, an attacker needs to spend O(2^n) operations to find two keys that agree in the first n bits, which will make you do O(2^n) operations and use O(2^n) memory.)


> No, using a slower cryptographic hash would produce better distribution

That absolutely isn't an intrinsic property of cryptographic hashes.


Using a faster cryptographic hash would be better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: