Non-cryptographic

HighwayHash

Designed at Google by Jyrki Alakuijala, Bill Cox, and Jan Wassenberg (2016). HighwayHash targets a niche between cryptographic and pure non-cryptographic hashes: SIMD-tuned for AVX-2 throughput, but with a stated security goal against chosen-input collisions when used with a 256-bit secret key.

At a glance

The niche

SipHash is keyed, hash-flooding-resistant, but slower per byte (~2-3 GiB/s). xxHash3 is much faster but non-cryptographic in the chosen-input sense. HighwayHash sits between: as fast as xxHash3 with SIPI-style chosen-input resistance, at the cost of needing a key and AVX-2 to hit peak.

Construction

HighwayHash maintains a 1024-bit internal state organized into four 256-bit lanes. Each input block updates the lanes via multiply-add operations matched to AVX-2 / NEON SIMD instructions. After absorbing the input, a finalization phase mixes the lanes and squeezes the requested output size.

Where it shows up

• Google’s internal services , the original deployment context.
• Bazel , experimental option for content addressing.
• JPEG XL , uses HighwayHash internally.
• Some database engines , chosen-input-resistant hash tables.

Caveats

• HighwayHash’s security claims are not based on a formal proof; they rest on the design’s ARX-like mixing and the secret key.
• It is not a cryptographic hash , do not use it for content addressing where collisions must be hard.
• Hash output stability across versions has changed; pin a version if interoperability matters.

References

• Alakuijala, Cox, Wassenberg , Fast keyed hash/pseudo-random function using SIMD multiply and permute (2016)
• google/highwayhash on GitHub
• SipHash · xxHash3