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
| Output | 64, 128, or 256 bits |
|---|---|
| Key | 256 bits (mandatory for security claims) |
| Throughput | ~7-12 GiB/s on AVX-2 |
| Year | 2016 |
| Project | google/highwayhash |
| Status | Keyed non-cryptographic; resists hash flooding |
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.