What checksums are for: verifying a download with a hash

Next to many download links sits a line of hex like sha256: 9f86d081884c7d65… — published, one suspects, mostly for nobody to ever check. But that string can answer a genuinely useful question: is the file I received exactly the file they published? Here is what it proves, what it cannot, 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. Deterministic. The same file always produces the same hash, on any machine, any OS, any year.
2. Avalanche effect. Change one bit anywhere in the input and the hash changes beyond recognition — there is no “close” in hash space, so comparing hashes is a strict yes/no.
3. One-way and collision-resistant. Nobody can construct a file to match a given hash, or (for unbroken functions) find two files sharing one.

So if the hash you compute matches the hash the site published, you hold a bit-for-bit identical copy of what they hashed. Any corruption in transit — a truncated download, a flipped bit on a failing disk, a proxy that mangled the file — shows up as a completely different hash.

Checking one, practically

Every OS ships the tools:

# 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 have no “near misses”. For hashing text rather than files (an API signature to debug, a string to match against a config), the hash generator here does MD5, SHA-1, SHA-256 and friends locally in the browser, which beats pasting secrets into a random server-side site.

Mismatches are nearly always a truncated or resumed download; re-download before suspecting anything darker. And note the hash covers the exact bytes: unzipping and re-zipping a file produces different bytes and a different hash even when the contents are equivalent.

What a checksum does not prove

A hash on the same page as the download verifies integrity, not authenticity. If an attacker can replace the file on the server, they can replace the published hash beside it in the same edit — the two travel together, so the check proves only that you got what the page currently offers, corrupted by nobody in between.

Authenticity — the publisher really produced this — needs the hash (or the file) to be signed: PGP signatures, OS code-signing, package-manager signatures. That is a different mechanism with its own key management, and it is why serious projects publish signatures alongside checksums rather than instead of them. For everyday use the practical hierarchy is: 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 — colliding files can be manufactured at will — and SHA-1 followed in 2017. Yet both still appear beside downloads, and this is less scandalous than it sounds, because broken is specific: an attacker can create two files that share a hash, but still cannot create a file matching a given hash of a file they did not choose.

Against accidental corruption — the truncated download, the failing disk — MD5 works exactly as well as it ever did, and it is fast. As protection against a capable attacker it is worthless, but as shown above, an unsigned checksum was never protecting you from that attacker anyway. The rule: for integrity, any hash; for anything security-flavoured, SHA-256 or newer; for authenticity, signatures.

Other places the same idea appears

Once you recognise the fingerprint pattern it turns up constantly: git identifies every commit by a hash of its contents (which is why history cannot be silently edited); package lockfiles pin dependencies by hash so a compromised registry cannot substitute code; sync tools and deduplicators compare hashes instead of whole files; and password systems store hashes so that a stolen database reveals fingerprints rather than passwords — with the crucial extra ingredients of salt and deliberate slowness, which is a story of its own.

All of them are the same three properties — deterministic, avalanche, one-way — pointed at different problems. The published checksum by a download link is simply the smallest, most user-facing member of the family.