What checksums are for: verifying a download with a hash

Next to a lot of download links sits a line of hex like sha256: 9f86d081884c7d65…, published (one suspects) mostly for nobody to ever check. That string answers a genuinely useful question, though: is the file I received exactly the file they published?

Here’s what it proves, what it doesn’t, and how to actually use it.

What a hash is

A cryptographic hash function condenses any input into a fixed-size fingerprint. SHA-256 produces 256 bits, written as 64 hex characters. Three properties make it useful:

1. It’s deterministic. The same file always produces the same hash, on any machine, any OS, any year.
2. It has an avalanche effect. Change one bit anywhere in the input and the hash changes beyond recognition. There’s no such thing as “close” in hash space, so comparing two hashes is a strict yes or no.
3. It’s one-way and collision-resistant. Nobody can construct a file to match a given hash, or (for the functions that aren’t broken) find two files that share one.

So when the hash you compute matches the hash the site published, you’re holding a bit-for-bit identical copy of whatever they hashed. Corruption in transit shows up as a completely different hash, whether that’s a truncated download, a flipped bit on a failing disk, or a proxy that mangled the file.

Checking one, practically

Every OS ships with the tools already:

# Windows (PowerShell)
Get-FileHash installer.iso -Algorithm SHA256

# macOS
shasum -a 256 installer.iso

# Linux
sha256sum installer.iso

Compare the output against the published value. The first and last few characters are enough in practice, since hashes don’t have near misses. For hashing text instead of files, say an API signature you’re debugging or a string to match against a config, the hash generator here does MD5, SHA-1, SHA-256 and the rest locally in the browser, which beats pasting secrets into some server-side site.

When there’s a mismatch, it’s nearly always a truncated or resumed download. Re-download before you suspect anything darker.

One thing to note: the hash covers the exact bytes. Unzip a file and re-zip it and you get different bytes and a different hash, even though the contents are the same.

What a checksum doesn’t prove

A hash sitting on the same page as the download verifies integrity, not authenticity. An attacker who can replace the file on the server can replace the published hash beside it in the same edit. The two travel together, so all the check really proves is that you got what the page currently offers, uncorrupted by anyone in between.

Authenticity, meaning “the publisher really produced this”, needs the hash or the file to be signed: PGP signatures, OS code-signing, package-manager signatures. That’s a different mechanism with its own key management, and it’s why serious projects publish signatures alongside checksums instead of in place of them.

For everyday use the pecking order is straightforward. A matching checksum beats no check. A verified signature beats both.

Why MD5 is still everywhere despite being “broken”

MD5’s collision resistance fell in 2004, so colliding files can now be manufactured at will, and SHA-1 followed in 2017. Both still turn up beside downloads, and that’s less scandalous than it sounds, because “broken” here is specific. An attacker can create two files that share a hash. They still can’t create a file matching a given hash of a file they didn’t choose.

Against accidental corruption, the truncated download and the failing disk, MD5 works exactly as well as it ever did, and it’s fast. As protection against a capable attacker it’s worthless. But as we just established, an unsigned checksum was never protecting you from that attacker anyway.

The rule: for integrity, any hash will do. For anything security-flavoured, SHA-256 or newer. For authenticity, signatures.

Other places the same idea appears

Once you recognise the fingerprint pattern you start seeing it everywhere. git identifies every commit by a hash of its contents, so history can’t be silently edited. Package lockfiles pin dependencies by hash, so a compromised registry can’t substitute code. Sync tools and deduplicators compare hashes instead of whole files. Password systems store hashes so a stolen database gives up fingerprints instead of passwords, with the crucial extra ingredients of salt and deliberate slowness, which is a story of its own.

Every one of those is the same three properties, deterministic, avalanche, one-way, pointed at a different problem. The published checksum by a download link is just the smallest and most user-facing member of the family.