MD5 vs SHA-256: Why One Is Broken and the Other Isn’t

In December 2008, a team of security researchers used a real, practical MD5 weakness to forge a certificate authority signature — creating a fraudulent SSL certificate that any browser would have trusted, capable of impersonating any HTTPS site as a man-in-the-middle. SHA-256’s full algorithm, despite two decades of dedicated cryptanalysis, has never suffered an equivalent break. Both are “hash functions.” Only one is safe to rely on for security.

What a Hash Function Is Supposed to Guarantee

A cryptographic hash function needs three specific properties to be trustworthy for security purposes: preimage resistance (you can’t recover the original input from its hash), second-preimage resistance (you can’t find a different input that produces the same hash as a given one), and collision resistance (you can’t find any two different inputs that produce the same hash at all). Generate and compare hashes for text or files directly with the MD5 Hash Generator and SHA-256 Hash Generator.

MD5: The Real Attack That Broke Trust

MD5’s collision resistance failed first theoretically, then practically, then catastrophically. Researchers Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu announced the first full MD5 collisions in August 2004, findable in roughly an hour on period hardware. That escalated in December 2008, when researchers published a working “chosen-prefix collision” attack: they constructed a legitimate certificate and a malicious one engineered to share an identical MD5 hash, so that a trusted certificate authority’s signature on the legitimate certificate also validated the malicious one.

That’s why MD5 is described as “cryptographically broken” — not a theoretical weakness in a lab, but a demonstrated real-world attack against the exact trust infrastructure the web depends on.

SHA-256: Why It’s Held Up

SHA-256 is part of the SHA-2 family, producing a 256-bit output (double MD5’s 128 bits) with a structurally different internal design. Despite extensive, ongoing cryptanalysis, no successful collision attack against the full 64-step algorithm has ever been published. Recent research has pushed practical collision attacks to cover 35 of SHA-256’s 64 internal steps, with theoretical results reaching 36–37 steps — genuine academic progress, but nowhere near threatening the complete algorithm actually used in practice. NIST continues to recommend SHA-2 (alongside SHA-3) as of 2026.

CRC: A Completely Different Job

Here’s a common point of confusion: CRC checksums (CRC-8, CRC-16, CRC-32, CRC-64) are not cryptographic hashes at all, and were never meant to be. CRC was designed to catch accidental data corruption — a bit flipped during transmission or storage — not to resist a deliberate adversary. Structurally, CRC is linear: an attacker can append or alter data and recompute matching trailing bits that preserve the exact same CRC value, meaning it offers essentially no protection against intentional tampering. Calculate and verify CRC checksums across all standard presets with the CRC Checksum Calculator — just don’t reach for it when you actually need tamper resistance.

Where Hashing Meets Real Infrastructure: JWTs and SSL

This distinction shows up constantly in real systems. JSON Web Tokens are typically signed with algorithms like HMAC-SHA256 or RSA — inspect any token’s header, payload, and signing algorithm with the JWT Token Decoder. And the exact mechanism the 2008 MD5 attack exploited — a certificate authority’s hash-based signature — is why modern certificate authorities now require SHA-256 or stronger. Check any HTTPS certificate’s issuer, validity, and details directly with the SSL Certificate Checker.

Encoding Is Not Hashing: The Base64 Confusion

One more common mix-up worth clearing up: Base64 is encoding, not hashing or encryption. It’s fully reversible by design — anyone can decode it instantly back to the original data — and exists purely to represent binary data safely as text, not to provide any security at all. Encode or decode Base64 (standard or URL-safe) with the Base64 Encoder / Decoder.

Frequently Asked Questions

Is MD5 still safe to use for anything?
It’s fine for non-security purposes like detecting accidental file corruption, but it must never be used anywhere collision resistance matters — digital signatures, certificates, or password hashing.

What actually happened with the MD5 rogue CA attack?
In 2008, researchers crafted a legitimate and a malicious certificate that shared an identical MD5 hash, so a trusted CA’s signature on the legitimate one also validated the malicious one — allowing forged SSL certificates for any HTTPS site.

Has SHA-256 ever been broken?
No — no successful collision attack against the full 64-step algorithm has ever been published, despite two decades of dedicated cryptanalysis; recent progress only reaches reduced, partial-round versions.

What’s the difference between CRC and a cryptographic hash?
CRC is designed to catch accidental data corruption and is structurally linear, meaning an attacker can forge matching values deliberately; cryptographic hashes like SHA-256 are specifically designed to resist that kind of intentional manipulation.

Is Base64 a form of encryption?
No — it’s fully reversible encoding with no security properties at all; anyone can decode Base64 data instantly without any key or password.

Related Calculators

Generate and compare hashes with the MD5 Hash Generator and SHA-256 Hash Generator, and use the CRC Checksum Calculator specifically for accidental-corruption detection, not security. Inspect real-world applications with the JWT Token Decoder and SSL Certificate Checker, and don’t confuse hashing with the Base64 Encoder / Decoder’s fully reversible encoding.

External Resources

• MD5 — Wikipedia — full collision history including the 2008 rogue CA certificate attack
• NIST — the official U.S. body maintaining cryptographic hash function standards, including SHA-2