4 ms·
Yes, but! Many libraries have migrated to cryptographic hash functions even for non-cryptographic use cases such as hash tables. They choose a random key. Th
by less_less 5y ago
Yes, but! Many libraries have migrated to cryptographic hash functions even for non-cryptographic use cases such as hash tables. They choose a random key. This mitigates problems where the algorithm performs much worse on pathologically bad, perhaps adversarially chosen, data sets.
- marginalia_nu 5y agoIf you are worried about adversarial data, it's probably better to choose a more suitable data structure instead (or change the way you deal with hash collisions: linear probing is probably not a good idea if the data is sketchy). Hash tables are only performant if the hash function is fast, and cryptographic hash functions are anything but.
- tyingq 5y agoChecksums might be a better example. People often use cryptographic hashes for check summing in non-security related scenarios. And, depends on the implementation, but MD5 or SHA-1 is often the same or better performance than a CRC checksum. That shouldn't be the case, but it often is.
- TillE 5y agoA library should absolutely not be using a cryptographic hash for something like a hash table unless they have very particular requirements. You don't want to force a significant performance penalty on all your users when there are good general-purpose hashes like XXH3 out there.
- barsonme 5y agoCounterpoint: SipHash. Also, in general I disagree. For most people, safe defaults like hash tables with safe hashes and CSPRNG for random numbers are fast enough. And they have the important property of keeping people from shootings themselves in the feet. People who have more stringent perf requirements will know and shouldn’t have a problem choosing a different implementation.