MD5 vs SHA1 vs SHA256

Both MD5 and SHA-1 followed the same pattern: a theoretical weakness in collision resistance was published first, followed years later by a fully practical, demonstrated attack, followed by formal industry deprecation. For MD5: Wang's team's 2004 collision-finding technique, refined chosen-prefix collisions by 2008-2009, and real-world exploitation (Flame malware) by 2012. For SHA-1: Wang's 2005 theoretical weakening, NIST's 2013 formal deprecation recommendation (ahead of a practical attack existing), and the 2017 'SHAttered' practical collision from Google/CWI.

This timeline matters practically: a hash function doesn't need a demonstrated practical attack to be worth abandoning — SHA-1's deprecation began years before SHAttered, based on the trajectory of published cryptanalysis. Waiting for a practical attack before migrating away from a theoretically-weakening hash function means migrating under pressure rather than on your own schedule.

SHA-256 has no equivalent timeline entry — no theoretical collision weakness of the kind that preceded both MD5's and SHA-1's breaks has been published against it, which is exactly why it remains the current baseline recommendation rather than a function on a similar deprecation trajectory.

Being 'broken' specifically means collision resistance has failed: an attacker can find two different inputs producing the same hash, in practical time, using real hardware. It does not mean the hash can be reversed (none of these three functions are reversible in the sense of computing the original input from the digest alone) — preimage resistance and collision resistance are different properties, and MD5/SHA-1's breaks are specifically collision breaks.

This distinction matters for scoping the actual risk: a broken collision-resistance property is a serious problem for anything relying on two parties being unable to produce matching hashes for different content (digital signatures, certificate issuance, deduplication systems that trust hash equality as identity) — exactly the property Flame and SHAttered exploited. It's a non-issue for a use case that never needed collision resistance in the first place, like detecting accidental (not adversarial) file corruption during a download.

Non-adversarial integrity checks — confirming a downloaded file wasn't corrupted in transit, verifying two local copies of a file match — don't require collision resistance against a deliberate attacker, only against accidental bit-flips, which MD5 and SHA-1 still detect reliably and quickly. This is why MD5 checksums still appear alongside many software downloads today: nobody is trying to forge a matching-hash malicious file in that specific context (and where they might, SHA-256 checksums are increasingly offered alongside for exactly that reason).

A genuinely interesting real-world case: Git uses SHA-1 internally as its object content-addressing scheme (the ID that identifies every commit, tree, and blob). This is a well-known, actively-discussed tension in the Git project — SHA-1's collision break is a real theoretical concern for Git's content-addressing model, which is precisely why Git has an ongoing, in-progress transition path to SHA-256 as an alternative object format, rather than treating the issue as irrelevant.

MD5's 128-bit digest is the smallest and fastest to compute of the three; SHA-1's 160-bit digest is a modest step up in both size and computation cost; SHA-256's 256-bit digest is the largest and costs somewhat more CPU time to compute than either predecessor. For virtually all modern applications, this performance difference is negligible in absolute terms (all three hash typical payloads in microseconds to low milliseconds) — security properties, not raw speed, should drive the choice whenever the hash is protecting anything against a deliberate adversary.