The non-cryptographic hash functions (NCHFs[1]) are hash functions intended for applications that do not need the rigorous security requirements of the cryptographic hash functions (e.g., preimage resistance) and therefore can be faster and less resource-intensive.[2] Typical examples of CPU-optimized non-cryptographic hashes include FNV-1a and Murmur3.[3] Some non-cryptographic hash functions are used in cryptographic applications (usually in combination with other cryptographic primitives); in this case they are described as universal hash functions.[4]
SuperFastHash was created by Paul Hsieh using ideas from FNV and lookup3, with one of the goals being a high degree of avalanche effect. The hash is used in WebKit (part of Safari and Google Chrome).
DJBX33A ("Daniel J. Bernstein, Times 33 with Addition"). This very simple multiplication-and-addition function was proposed by Daniel J. Bernstein. It is fast and efficient during initialization. Many programming environments based on PHP 5, Python, and ASP.NET use variants of this hash. The hash is easy to flood, exposing the servers.
BuzHash was created by Robert Uzgalis in 1992. It is designed around a substitution table and can tolerate extremely skewed distributions on the input.
DEK is an early multiplicative hash based on a proposal by Donald E. Knuth and is one of the oldest hashes that is still in use.
Non-cryptographic hash functions optimized for software frequently involve the multiplication operation. Since in-hardware multiplication is resource-intensive and frequency-limiting, ASIC-friendlier designs had been proposed, including SipHash (which has an additional benefit of being able to use a secret key for message authentication), NSGAhash, and XORhash. Although technically lightweight cryptography can be used for the same applications, the latency of its algorithms is usually too high due to a large number of rounds.[3] Sateesan et al. propose using the reduced-round versions of lightweight hashes and ciphers as non-cryptographic hash functions.[2]
Many NCHFs have a relatively small result size (e.g., 64 bits for SipHash or even less): large result size does not increase the performance of the target applications, but slows down the calculation, as more bits need to be generated.[8]
Mittelbach, Arno; Fischlin, Marc (2021). "Non-cryptographic Hashing". The Theory of Hash Functions and Random Oracles. Cham: Springer International Publishing. pp. 303–334. doi:10.1007/978-3-030-63287-8_7. ISBN978-3-030-63286-1.
This article needs additional or more specific categories. Please help out by adding categories to it so that it can be listed with similar articles.(May 2023)