Hash functions are used in four completely different contexts in computing — data integrity verification, password storage, digital signatures, and hash tables — and the properties required for each are so different that a function ideal for one context is completely wrong for another
The previous articles on this site covered hash function basics, Merkle trees and Git/blockchain, password storage mistakes, file hash verification, and SHA-3 vs SHA-2. This article addresses hash function selection by use case — the specific properties each context requires, why using the wrong hash type creates real vulnerabilities, and the current recommendations for each domain.
The four hash contexts and their requirements
Context 1: Data integrity verification
Goal: detect accidental corruption or tampering of data.
Required properties:
- Deterministic (same input always produces same hash)
- Fast to compute (checking large files quickly)
- Practically collision-resistant (different data shouldn't produce the same hash)
Current recommendations: SHA-256 or SHA-3-256 for most use cases. MD5 and SHA-1 are acceptable for non-security integrity checks (checking for file corruption, not tampering) where collision attacks aren't a concern — though SHA-256 is preferred even here.
What's NOT required: resistance to length-extension attacks (generally not exploitable in integrity checking contexts), slowness (speed is desirable).
Context 2: Password storage
Goal: make it computationally expensive to reverse hashes if the database is stolen.
Required properties:
- Slow to compute (more computation per guess reduces brute-force speed)
- Memory-hard (requires significant RAM, defeating GPU parallelism)
- Salted (unique per-user random prefix prevents rainbow table attacks)
Current recommendations: Argon2id (OWASP primary recommendation), bcrypt (still secure at cost factor 12+), scrypt (acceptable, parameterisation is tricky).
What is WRONG here: SHA-256, SHA-3, MD5 — all fast cryptographic hashes. These are completely wrong for password storage because their speed is a vulnerability in this context. A GPU can compute billions of SHA-256 hashes per second; bcrypt at cost factor 12 allows ~100 hashes per second by design.
Context 3: Digital signatures and HMACs
Goal: prove that data was signed by a specific party and hasn't been modified.
Required properties:
- Collision resistance (an attacker shouldn't be able to find two messages with the same hash)
- Second preimage resistance (given a message and its hash, can't find another message with the same hash)
- Resistance to length-extension attacks (for HMACs)
Current recommendations: SHA-256, SHA-384, SHA-512 for digital signatures. For HMAC, SHA-256 is standard — but note that SHA-2 (unlike SHA-3) has length-extension vulnerability that HMAC's construction specifically avoids.
The length-extension vulnerability: SHA-2 (SHA-256, SHA-512) is vulnerable to length-extension attacks — given H(message), an attacker can compute H(message || extension) without knowing the original message. This is exploitable in "naive" HMAC implementations like H(secret || message). HMAC-SHA256 specifically avoids this through its construction: HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), which wraps the hash with the key applied twice. SHA-3 is not vulnerable to length-extension — it uses a different internal construction (sponge function) — which is one reason some systems prefer SHA-3.
Context 4: Hash tables (data structures)
Goal: distribute keys evenly across buckets for O(1) average-case lookup.
Required properties:
- Fast to compute (millions of lookups per second)
- Good distribution (keys spread evenly across buckets)
- Low collision rate in practice
What's used: MurmurHash, xxHash, SipHash — non-cryptographic hash functions optimised for speed and distribution. Cryptographic hash functions (SHA-256) are far too slow for hash table use.
The hash table DoS attack: if a hash table uses a predictable hash function, an attacker who knows the function can craft inputs that all map to the same bucket — degrading O(1) lookup to O(n). Python, Ruby, and Perl have all added randomised hash seeds to prevent this.
SHA-256 output size and truncation
SHA-256 produces a 256-bit (32-byte) hash, typically displayed as a 64-character hexadecimal string or a 43-character Base64 string.
Truncation: SHA-256 can be truncated to shorter outputs when the full 256 bits of security isn't needed and space is constrained. SHA-256/128 (first 128 bits) has approximately 2^64 collision resistance — less than full SHA-256 but adequate for many non-adversarial integrity checks.
Why truncation of SHA-256 is safer than using MD5 (128-bit): MD5's 128-bit output isn't just "smaller" than SHA-256's 256-bit — MD5 has known collision vulnerabilities (practical collision attacks exist). Truncated SHA-256 has no such structural weaknesses; it simply has fewer bits to maintain security.
Keyed hash functions: HMAC vs BLAKE3 KDF
HMAC (Hash-based Message Authentication Code) converts a regular hash function into a keyed authentication function — producing a code that can only be reproduced by someone with the same key.
HMAC-SHA256 structure:
- Inner hash: H(K XOR ipad || message)
- Outer hash: H(K XOR opad || inner_hash)
BLAKE3 (the 2020 successor to BLAKE2) has native support for keyed hashing — BLAKE3(key, message) — without the HMAC wrapper construction. BLAKE3 is also significantly faster than SHA-256 on modern hardware (typically 3-5× faster) and has a larger security margin.
Current position: HMAC-SHA256 is ubiquitous and safe; BLAKE3 is modern, faster, and gaining adoption in new systems. SHA-3/SHAKE also supports keyed hashing natively via the XOF (Extendable Output Function) construction.
How to use the Hash Generator on sadiqbd.com
- For integrity checksums: generate SHA-256 hashes for files or content blocks to create verifiable checksums — paste the file content (or relevant data) and record the output alongside the data
- For HMAC preparation: if you need to understand what a specific input hashes to before implementing HMAC in code, use the tool to verify the SHA-256 component
- For multi-algorithm comparison: generate MD5, SHA-1, SHA-256, and SHA-512 for the same input to see how output lengths differ — useful for understanding why MD5's shorter output reflects less collision resistance, not just less data
Frequently Asked Questions
When should I use SHA-512 instead of SHA-256? SHA-512 is useful on 64-bit systems processing large data, where its internal 64-bit word operations can be faster than SHA-256's 32-bit operations on 64-bit CPUs. For most web and application developers, SHA-256 provides adequate security and is the more widely supported choice. The security difference between SHA-256 (128-bit collision resistance) and SHA-512 (256-bit collision resistance) is academic for nearly all practical applications — finding SHA-256 collisions is computationally infeasible with any foreseeable technology. Use SHA-256 as the default for compatibility and reasonable performance; consider SHA-512 if you're on a 64-bit server processing large files and benchmarks show a performance advantage.
Is the Hash Generator free? Yes — completely free, no sign-up required.
Try the Hash Generator free at sadiqbd.com — generate MD5, SHA-1, SHA-256, SHA-512, and SHA-3 hashes for any input instantly.
