Cryptographic hash algorithm reference
A cryptographic hash function maps an arbitrary-length input to a fixed-length digest. A good hash is deterministic, fast to compute, and resistant to preimage, second-preimage and collision attacks. This reference lets you search and filter the common families — MD5, SHA-1, SHA-2, SHA-3, BLAKE2 and BLAKE3 — by digest size, internal block size, and current security status so you can pick the right one for your use case.
Security status explained
Each algorithm in the table carries one of three status labels:
- Secure — no practical attacks known; safe for digital signatures, integrity checks, and cryptographic commitments.
- Weak — theoretical breaks or borderline-practical attacks exist; avoid for any new design, even if no real-world exploit has been demonstrated yet.
- Broken — practical collision attacks have been demonstrated. MD5 was broken in practice by 2005; SHA-1 fell to the public SHAttered collision attack in 2017. Never use broken algorithms where an adversary can choose or influence inputs.
A digest of n bits gives roughly n/2 bits of collision resistance due to the birthday bound. SHA-256, for example, has a 256-bit output but only about 128 bits of collision security — still far beyond what is practically attackable.
Algorithm families at a glance
MD5 (128 bits, broken) — Produces a 16-byte hex digest. Widely used in the 1990s for file checksums and password hashing. Practical collision attacks have been demonstrated repeatedly. Safe only for non-security checksums such as detecting accidental corruption where an adversary is not present.
SHA-1 (160 bits, broken) — 20-byte output; long deprecated by NIST but still found in legacy systems. The SHAttered attack demonstrated a practical chosen-prefix collision. Remove SHA-1 from any security-sensitive code path.
SHA-2 family (224, 256, 384, 512 bits, secure) — The workhorses of modern cryptography. SHA-256 and SHA-512 are the most common; SHA-224 and SHA-384 are truncated variants. All use the Merkle-Damgård construction and remain secure, though plain SHA-256 and SHA-512 are vulnerable to length-extension attacks when used naively as MACs.
SHA-3 family (224, 256, 384, 512 bits, secure) — Based on the completely different Keccak sponge construction. Standardised by NIST in FIPS 202 as a hedge against future attacks on SHA-2. Immune to length-extension attacks by design. Note: SHA3-256 differs from Ethereum’s Keccak-256 only by the domain-separation padding byte.
BLAKE2 (up to 512 bits, secure) — Defined in RFC 7693. BLAKE2b (64-bit optimised, up to 512 bits) and BLAKE2s (32-bit optimised, up to 256 bits) are both faster than SHA-2 on most CPUs while remaining cryptographically secure. Widely used in password hashing (as the core of Argon2) and file integrity.
BLAKE3 (256 bits, secure) — The successor to BLAKE2 with a tree structure enabling hardware parallelism. Significantly faster than SHA-2 and BLAKE2 in multi-threaded contexts. 256-bit output only, but can be extended to arbitrary length.
Choosing the right hash
| Use case | Recommended |
|---|---|
| General file integrity / checksums | SHA-256 or BLAKE3 |
| Digital signatures (TLS, code signing) | SHA-256 or SHA-384 |
| Password hashing | Argon2 (uses BLAKE2 internally) |
| Ethereum / EVM development | Keccak-256 (not SHA3-256) |
| Embedded or constrained devices | BLAKE2s |
| High-throughput data pipelines | BLAKE3 |
| Legacy interoperability only | SHA-1 (verify there is no adversary) |
Common mistakes
Using MD5 or SHA-1 for passwords — Fast hashes are the wrong tool even without collision attacks; brute-force guessing is trivial on modern hardware. Use Argon2, scrypt, or bcrypt.
Confusing SHA3-256 with Keccak-256 — They differ only by one padding byte but produce completely different digests. Ethereum tools expect Keccak-256 (padding 0x01); FIPS 202 SHA3-256 uses 0x06.
Length-extension attacks on SHA-256 — If you compute HMAC = SHA256(secret || message) naively without HMAC, an attacker who knows the digest can append data and compute a valid new digest without knowing the secret. Always use HMAC or a sponge-based function for message authentication.