What is a checksum and why every download page shows one

A cryptographic hash function takes input of any length and produces output of one fixed length. SHA-256 always returns 256 bits — 32 bytes, written as 64 hexadecimal characters — whether you feed it an empty file or a 40 GB virtual machine image. The compression is brutal and one-way: there is no procedure that turns those 64 characters back into the file, and for any sensible input size an enormous number of different files share every possible digest.

The words digest, hash and checksum get used interchangeably here, though they are not historically the same thing. A checksum in the strict sense is a simple error-detecting code such as CRC32 or Adler-32, designed to catch transmission noise cheaply. What download pages publish is a cryptographic digest, which is far stronger and far slower. The habit of calling it a checksum stuck, so this site uses both words for the same string.

The fingerprint comparison is accurate in the ways that matter. A fingerprint is short, easy to write down and compare, effectively unique in practice, and completely useless for reconstructing the person it came from. A SHA-256 digest is all four.

Two properties make a digest useful for verification. The first is determinism: the same bytes always produce the same digest, on any machine, in any operating system, today or in ten years. A digest computed by a build server in 2019 will still match the one your laptop computes now, because the algorithm has no clock, no randomness and no hidden state.

The second is the avalanche effect. Flip a single bit anywhere in the input and roughly half of the output bits flip too, in a way nobody can predict without running the function. Change one comma in a 5 GB ISO and the new digest looks entirely unrelated to the old one. There is no such thing as two digests being nearly the same: they either match exactly or they are strangers.

That has a practical consequence for how you compare them. Checking that the first eight and the last eight characters agree feels like enough, and for catching a corrupted download it usually is — but it is a much weaker check than it looks, and it is exactly the shortcut an attacker would rely on. Compare the whole string, or let something compare it for you.

Nothing magical happens on the publisher's side. After a release is built, someone runs the same hash function you would run — sha256sum *.iso on Linux, typically — and saves the output into a plain text file. Ubuntu, for example, ships a file literally called SHA256SUMS next to every image on releases.ubuntu.com, with one line per file in the format <digest> <filename>.

The split matters. A 5 GB image is served by whichever mirror or CDN node is closest to you, because bandwidth is expensive; the 64-byte digest is served from the project's own domain over HTTPS, because 64 bytes cost nothing. The checksum is therefore a small, cheap, trustworthy anchor for a large, cheap, untrusted transfer — that is the whole design.

It follows that a checksum is only as good as the place you got it from. If you copy both the file and the digest from the same random mirror, and that mirror has been tampered with, the two will agree perfectly and tell you nothing. Fetch the expected value from the project's canonical site, over HTTPS, ideally from a different host than the one that served the file.

These are two different questions and a checksum only answers one. Integrity asks: are the bytes I have the bytes this digest describes? Authenticity asks: did this digest come from the people I think it came from? Recomputing a hash settles the first completely and the second not at all.

The usual answer to the second question is a signature. Projects publish a detached OpenPGP signature over the checksum file — SHA256SUMS.gpg next to SHA256SUMS — and you run gpg --verify SHA256SUMS.gpg SHA256SUMS. If it validates, the list of digests really was signed by the holder of that key, and the chain becomes: trusted key signs the list, the list pins the digest, the digest pins the file.

That just moves the trust to the key, which you then have to obtain honestly — from the distribution's documentation, a key server cross-checked against a fingerprint printed in several places, or a keyring package you already have installed. For most people, most of the time, fetching the checksum over HTTPS from the project's own domain is a reasonable stopping point. It is worth knowing that it is a stopping point and not a proof.

Most of the time it catches boring accidents rather than attacks. Downloads get truncated when a connection drops, a proxy rewrites content, or a disk fills up silently. Removable media is worse: a cheap USB stick or an aging SD card will hand back bytes that were never written, and a corrupted installer usually fails an hour into a long install rather than at the start.

The same mechanism does long-term work. Store the digest alongside an archive and you can re-check it years later to detect silent bit rot on the drive that holds it. Two files with the same SHA-256 can be treated as the same file for deduplication. Backup tools, content-addressed stores and version control systems are all built on exactly this identity.

And it shows up in places you may not think of as verification at all. Lock files pin a dependency by its hash so a re-install cannot quietly get different code. Container images are referenced by digest rather than by tag when you want reproducibility. The integrity attribute on a <script> tag carries a base64-encoded SHA-384 digest, so the browser refuses a script a CDN has altered.