[HN Gopher] Questioning the Criteria for Evaluating Non-Cryptogr...
       ___________________________________________________________________
        
       Questioning the Criteria for Evaluating Non-Cryptographic Hash
       Functions
        
       Author : fanf2
       Score  : 6 points
       Date   : 2024-09-21 20:35 UTC (2 hours ago)
        
 (HTM) web link (queue.acm.org)
 (TXT) w3m dump (queue.acm.org)
        
       | PeterWhittaker wrote:
       | I've read the first several paragraphs and skimmed the article a
       | few times, and the motivation still eludes me: given the
       | existence of cryptographic hash functions that are well designed
       | and thoroughly tested, why spend so much time on non-
       | cryptographic hash functions?
       | 
       | What benefits do they provide that are not provided by their
       | secure "brethren"?
        
         | twiss wrote:
         | Better performance. For a hash table, a cryptographic hash
         | function is overkill (i.e. spends a lot of time to provide
         | security properties that are not needed).
        
           | bsder wrote:
           | > For a hash table, a cryptographic hash function is overkill
           | (i.e. spends a lot of time to provide security properties
           | that are not needed).
           | 
           | Except, as we quickly find out, attackers can often exploit a
           | non-cryptographic hash to create a denial of service attack.
           | 
           | The problem is that if my hash function is really a
           | performance bottleneck, I'm probably better off using a
           | really shitty hash function that exploits some feature of the
           | data being stored that is "good enough" but super fast. In
           | that case, even a non-crypto hash function won't be fast
           | enough.
           | 
           | Finally, hash tables result in "random-ish" memory access
           | patterns. On a modern processor, random memory access is so
           | horrifically slow that you may get superior performance by
           | changing data structures to something with a much more linear
           | access pattern and dumping the idea of hash tables
           | altogether.
        
       ___________________________________________________________________
       (page generated 2024-09-21 23:02 UTC)