Editing Fowler–Noll–Vo hash function (section)

==Non-cryptographic hash==

The FNV hash was designed for fast [[hash table]] and [[checksum]] use, not [[cryptography]]. The authors have identified the following properties as making the algorithm unsuitable as a [[cryptographic hash function]]:<ref>{{Cite journal|last1=Eastlake|first1=Donald|last2=Hansen|first2=Tony|last3=Fowler|first3=Glenn|last4=Vo|first4=Kiem-Phong|last5=Noll|first5=Landon|date=29 May 2019|title=The FNV Non-Cryptographic Hash Algorithm|url=https://tools.ietf.org/html/draft-eastlake-fnv-17.html|archive-url=|archive-date=|access-date=2021-01-12|website=tools.ietf.org|language=en}}</ref>

* '''Speed of computation''' – As a hash designed primarily for hashtable and checksum use, FNV-1 and FNV-1a were designed to be fast to compute. However, this same speed makes finding specific hash values (collisions) by brute force faster.
* '''Sticky state''' – Being an iterative hash based primarily on multiplication and XOR, the algorithm is sensitive to the number zero. Specifically, if the hash value were to become zero at any point during calculation, and the next byte hashed were also all zeroes, then the hash would not change. This makes colliding messages trivial to create given a message that results in a hash value of zero at some point in its calculation. Additional operations, such as the addition of a third constant prime on each step, can mitigate this but may have detrimental effects on [[avalanche effect]] or random distribution of hash values.
* '''Diffusion''' – The ideal secure hash function is one in which each byte of input has an equally-complex effect on every bit of the hash. In the FNV hash, the ones place (the rightmost bit) is always the XOR of the rightmost bit of every input byte. This can be mitigated by XOR-folding (computing a hash twice the desired length, and then XORing the bits in the "upper half" with the bits in the "lower half").<ref name="FNV_prime"/>

A structural weakness of FNV-1a arises from its use of XOR before multiplication, which can cause predictable relationships between hashes of related inputs. For example, the following identity holds in both the 32-bit and 64-bit variants:

 fnv1a("some-string-a") [[XOR]] fnv1a("some-id-1231") = fnv1a("some-string-b") [[XOR]] fnv1a("some-id-1232")

because the differing characters ('a' vs 'b', and '1' vs '2') differ by the same bit pattern. This illustrates how certain bitwise symmetries in input can lead to unintended hash correlations. XOR-folding does not remove this weakness.