3 ms·

How does it compare to SipHash, which is designed against hash-flooding DOS attacks? https://www.youtube.com/watch?v=wGYj8fhhUVA https://www.youtube.com/watch?

• rurban 11y ago
  SipHash is the worst of all slow hashes. Please forget about it.
  • DiThi 11y ago
    Why is it the worst? Also I don't have my question answered, which in other words is: Is it flood DOS resistant?
    • rurban 11y ago
      Hash functions cannot be made flush DOS resistant. Who told you that? Your local python or perl guru? Well, they are wrong. Read the note at https://github.com/rurban/smhasher#security https://github.com/rurban/smhasher#security "Such an attack avoidance cannot not be the problem of the hash function, but the hash table collision resolution scheme. You can attack every single hash function, even the best, if you detect the seed, e.g. from the sort-order, so you need to protect your collision handling scheme from the worst-case O(n), i.e. separate chaining with linked lists. Linked lists chaining is also very cache-unfriendly." You can flood even crypto hashes if used in a bad hash table based on linked lists, like perl, ruby, php or python and you can detect the seed. Read also https://github.com/rurban/perl-hash-stats#number-of-collisions-with-crc32 https://github.com/rurban/perl-hash-stats#number-of-collisio... on some hints how to attack them. Only uhashes (pairs of random hashfuncs) would be resistant, but I count this as hash table scheme, not a hash function per se. Why the worst? It's the slowest by far and has no other benefit. Look at the table overview. Those hash functions need to be fast.
      • DiThi 11y ago
        I just watched the video linked above. I'd love to see their response to this, as well as looking at a comparison between hash tables with SipHash vs. hash tables with a faster hash and better collision handling scheme, both being attacked.