MurmurHash is a non-cryptographic hash function suitable for general hash-based lookup. It was created by Austin Appleby in 2008 and is currently hosted on GitHub along with its test suite named 'SMHasher'. It also exists in a number of variants, all of which have been released into the public domain. The name comes from two basic operations, multiply and rotate, used in its inner loop. Unlike cryptographic hash functions, it is not specifically designed to be difficult to reverse by an adversary, making it unsuitable for cryptographic purposes.
Variants
MurmurHash3
The current version is MurmurHash3, which yields a 32-bit or 128-bit hash value. When using 128-bits, the x86 and x64 versions do not produce the same values, as the algorithms are optimized for their respective platforms. MurmurHash3 was released alongside SMHasher—a hash function test suite.
MurmurHash2
MurmurHash2 yields a 32-bit or 64-bit value. It came in multiple variants, including some that allowed incremental hashing and aligned or neutral versions.
MurmurHash2 - The original version; contains a flaw that weakens collision in some cases.
CMurmurHash2A - MurmurHash2A but works incrementally.
MurmurHashNeutral2 - Slower, but endian and alignment neutral.
MurmurHashAligned2 - Slower, but does aligned reads.
MurmurHash64A - The original 64-bit version. Optimized for 64-bit arithmetic.
MurmurHash64B - A 64-bit version optimized for 32-bit platforms. Unfortunately it is not a true 64-bit hash due to insufficient mixing of the stripes.
The person who originally found the flaw in MurmurHash2 created an unofficial 160-bit version of MurmurHash2 called MurmurHash2_160.
MurmurHash1
The original MurmurHash was created as an attempt to make a faster function than Lookup3. Although successful, it hadn't been tested thoroughly and wasn't capable of providing 64-bit hashes as in Lookup3. It had a rather elegant design, that would be later built upon in MurmurHash2, combining a multiplicative hash with a Xorshift.
Hash functions can be vulnerable to attack if a user can choose input data in such as way to intentionally cause hash collisions. Jean-Philippe Aumasson and Daniel J. Bernstein were able to show that even implementations of MurmurHash using a randomized seed are vulnerable to so-called HashDoS attacks. With the use of differential cryptanalysis they were able to generate inputs that would lead to a hash collision. The authors of the attack recommend to use their own SipHash instead.
Algorithm
algorithm Murmur3_32 is // Note: In this version, all arithmetic is performed with unsigned 32-bit integers. // In the case of overflow, the result is reduced modulo. input:key, len, seed
c1 ← 0xcc9e2d51 c2 ← 0x1b873593 r1 ← 15 r2 ← 13 m ← 5 n ← 0xe6546b64
hash ← seed for each fourByteChunk of keydo k ← fourByteChunk k ← k × c1 k ← k ROL r1 k ← k × c2 hash ← hash XOR k hash ← hash ROL r2 hash ← + n with any remainingBytesInKey do remainingBytes ← SwapToLittleEndian // Note: Endian swapping is only necessary on big-endian machines. // The purpose is to place the meaningful digits towards the low end of the value, // so that these digits have the greatest potential to affect the low range digits // in the subsequent multiplication. Consider that locating the meaningful digits // in the high range would produce a greater effect upon the high digits of the // multiplication, and notably, that such high digits are likely to be discarded // by the modulo arithmetic under overflow. We don't want that.
