The Hash Function Family Tree

All hash functions take arbitrary input and produce fixed-size output. They differ in output length, internal construction, speed, and (most importantly for security) whether they have been broken.

Designed by Ron Rivest in 1992, MD5 produces a 128-bit output. It became the most widely deployed hash function of the 1990s. Used in TLS certificates, package managers, file integrity checks, password storage, and roughly everything else.

In 2004, Wang et al. published a method to produce MD5 collisions in hours on a laptop. In 2008, researchers used a cluster of 200 PlayStation 3 consoles to create a rogue certificate authority certificate that browsers accepted as valid. In 2012, the Flame malware used MD5 collisions to forge Microsoft Windows Update signatures and infect Iranian government systems.

MD5 is broken not in the abstract but in the concrete. Anyone with a few minutes and a laptop can produce two files that share the same MD5 hash. Despite this, MD5 still appears in:

• Legacy file integrity checks where collision resistance does not matter (you only care if a corrupted download has the same hash as the good one, which won't happen by accident).
• Non-security contexts: cache keys, deduplication, ETags.
• Cisco device password hashing, embarrassingly, into the 2020s.

SHA-1 was designed by the NSA and published by NIST in 1995. It produces a 160-bit output and shares the same Merkle-Damgard construction as MD5, just with more rounds and a larger state.

The first significant attack came in 2005 (Wang et al.), reducing collision cost from 2^80 to 2^69. Computing power and algorithmic improvements made the attack progressively cheaper.

In February 2017, Google and CWI Amsterdam announced SHAttered: two distinct PDF files with the same SHA-1 hash. The attack cost about $110,000 of cloud GPU time. The browser industry had been preparing for this: by 2017, all major browsers had already announced SHA-1 certificate rejection. The CA/Browser Forum had banned issuing new SHA-1 certs since 2016.

SHA-1 still appears in git (as content-addressing, where collision resistance against arbitrary attackers is less critical than collision resistance against random changes), but git is transitioning to SHA-256 as well. Anywhere SHA-1 is still used for security, plan a migration.

The SHA-2 family arrived in 2001, also from NIST. It includes SHA-224, SHA-256, SHA-384, SHA-512, and a few less common variants. SHA-256 and SHA-512 are by far the most used. The internal structure is similar to SHA-1 (Merkle-Damgard with a compression function over fixed-size blocks) but with significantly larger state and more rounds.

Despite sharing structural DNA with broken predecessors, SHA-2 has resisted all serious attacks for 25 years. The best known attack on SHA-256 reduces collision search from 2^128 to roughly 2^123, a marginal weakening that does not threaten practical security.

SHA-2 is the default in essentially every modern cryptographic protocol:

• TLS certificates use SHA-256 signatures (SHA256withRSA, SHA256withECDSA).
• Bitcoin uses SHA-256 for its proof-of-work and address derivation.
• git is moving from SHA-1 to SHA-256.
• Linux kernel module signing, package managers (apt, dnf), Docker image digests all use SHA-256.

After the SHA-1 attacks of 2005, NIST started worrying that SHA-2 might be next. Both share the same internal construction; a breakthrough against the construction would affect both. NIST ran a public competition from 2007 to 2012 to find a successor. The Keccak design by Bertoni, Daemen, Peeters, and Van Assche won, and was standardized as SHA-3 in 2015.

SHA-3 uses a completely different internal structure called the sponge construction. Whatever attack might one day break SHA-2 would not apply to SHA-3, because the math underneath is unrelated.

SHA-3 is not faster than SHA-2 on most CPUs, and SHA-2 is not broken, so most software still uses SHA-2. SHA-3 sits in the wings: a vetted, standardized alternative that can be deployed quickly if SHA-2 ever falls. Some newer protocols (Ethereum 2.0, some post-quantum signatures) use Keccak/SHA-3 by default.

BLAKE2 (2012) and BLAKE3 (2020) are modern hash functions designed for speed without sacrificing security. BLAKE2 was a SHA-3 competition finalist that lost to Keccak but was later released independently. BLAKE3 is a redesign that exploits modern CPU features (SIMD, parallelism) to hit speeds of multiple gigabytes per second per core.

• BLAKE2: Used by Argon2 password hashing internally, by ZFS for checksums, by WireGuard.
• BLAKE3: Used by IPFS, by some new content-addressed stores, increasingly in build systems (Bazel) for caching.

Both are secure. Neither is mandated by any major standard. They live in performance-sensitive niches where SHA-256 is fast enough but BLAKE3 is faster.

Same input, four different hash functions. Notice the output lengths and how unrelated they look to each other.

If you find yourself reaching for MD5 or SHA-1 in new code, stop and ask whether collision resistance matters. If yes, use SHA-256. If no (cache keys, deduplication, ETags), MD5 is technically fine but SHA-256 truncated to 64 bits is a better habit.