The 2024 discovery of a backdoor deliberately planted in the xz compression library — one that shipped in several Linux distribution packages before a developer noticed anomalous SSH login latency — is a reminder of why checksum verification matters even for trusted-looking downloads. A tampered file and its accompanying checksum can both be swapped by an attacker at the source; checksum verification only proves your download matches what the publisher put out, not that the publisher's own build was clean.
How a checksum detects corruption
Because of the avalanche effect in hash functions, even a single corrupted byte during transfer completely changes the computed hash of the file. So any mismatch between the expected and computed checksum unambiguously means the file differs from the original — byte for byte.
What a checksum doesn't guarantee
A matching hash only confirms the file is identical to the one the published hash was computed from — not that the original is safe or genuinely comes from the claimed source. This is exactly the gap the xz incident exploited: the checksums matched perfectly, because the backdoor was in the "official" source all along.
Checksum vs. digital signature
Unlike a checksum, a digital signature is created with a private key and can only be verified with the matching public key — confirming not just integrity but also the source's authenticity. That's why security-conscious projects (the Linux kernel, Debian, most package managers) pair a checksum file with a GPG signature over that checksum file, so tampering with the mirror alone isn't enough.
Why you'd need this
- Confirming a downloaded archive or OS image wasn't corrupted during download.
- Quickly comparing two large files without a byte-by-byte diff.
- Verifying a backup copy of a file is identical to the original.
Why CRC32 is sometimes used instead of SHA-256
CRC32 is much faster than cryptographic hash functions, but it's trivially easy to forge on purpose — not a problem for detecting accidental corruption during transfer (what CRC32 was designed for), but unsuitable protection against an attacker who wants to tamper with a file undetected. That's why CRC32 still shows up in archivers and network protocols for error checking, not in places where security is actually required.