Archivehashing
Hash Tables vs Cryptographic Hashes
Same word, opposite requirements: one optimizes for speed and spread, the other for unpredictability.
- Published
- Reading time
- 1 min read
Hash tables want a function that is fast, distributes keys evenly, and can be computed incrementally. Cryptographic hashes want a function that is slow to invert, changes every output bit on any input change, and resists collisions found by adversaries. Using one for the other is a category error.
What each needs
| Property | Hash table | Crypto hash |
|---|---|---|
| Speed | nanoseconds | deliberately slow-ish |
| Adversary model | none (unless DoS) | full |
| Output | bucket index | fixed-size digest |
| Determinism | per-process seed is fine | global |
A hash table with SipHash and a random per-process seed is the safe default in languages that expose one: it kills collision-flooding attacks while staying fast.
The interesting overlap
Both care about collision behavior, but for different reasons. In a table, collisions cost probe time. In a digest, a collision breaks the security property. That is why the birthday bound shows up in both places — in one as a performance cliff, in the other as a security limit.
Takeaway: reach for hash() in a map and SHA-256 in a signature. If you find yourself swapping them, stop and ask which adversary you are defending against.