fingerprint File Checksum Verifier star

Why Software Publishers Publish Checksums

When you download a Linux ISO, an open-source binary, or a signed installer, the download page usually lists a checksum next to the file — a short string like a94a8fe5ccb19ba61c4c0873d391e987982fbbd. That string is the output of a cryptographic hash function run over every single byte of the file. Change even one bit anywhere in the file and the hash comes out completely different. Publishers list it so that after you download the file, you can run the same hash function yourself and compare your result against the one they published. If the two strings match exactly, you can be confident the copy sitting on your disk contains precisely the same bytes the publisher built and uploaded — nothing added, nothing missing, nothing altered.

A checksum catches two very different kinds of problems. The first is mundane: network connections drop mid-transfer, proxies truncate large files, and disks occasionally write bad sectors — any of these can leave you with a file that looks complete (right size, opens without an obvious error) but differs from the original by a handful of corrupted bytes, which is often enough to crash an installer or silently corrupt data later. The second is adversarial: if an attacker compromises a mirror server or intercepts a download in transit and swaps in a modified binary bundled with malware, comparing the checksum against the value published on the official, trusted page is one of the few checks that would actually catch it — a file name and file size are trivial to fake, but reproducing an exact hash requires possessing the exact original bytes.

Checksums Are Not Encryption

It is worth being precise about what a checksum verifies, because the terminology gets confused. Hashing is a one-way, irreversible operation: SHA-256 turns a file into a fixed 64-character hex string, but there is no operation that turns that string back into the file. That alone tells you this is not encryption — encryption is designed to be reversible with the right key, hashing is designed never to be reversible at all. A checksum verifies integrity, not confidentiality: it confirms the bytes you have are the bytes that were hashed. Anyone with access to the file can still read every byte of it in plain sight; hashing does nothing to hide the content. What it guarantees is that if a single byte were changed — deliberately or by accident — the hash you compute would no longer match the one published, and you would know immediately that something is different.

This distinction matters for algorithm choice too. SHA-1 was formally broken for cryptographic security in 2017, when researchers at Google and CWI Amsterdam published the "SHAttered" attack: two different PDF files engineered to produce the identical SHA-1 hash, proving a sufficiently motivated attacker could construct a malicious file that shares a checksum with a legitimate one. That result retired SHA-1 for anything security-critical — TLS certificates, digital signatures, defending against a hostile actor deliberately engineering a collision. But for the far more common case this tool addresses — confirming a download was not corrupted by a flaky connection — SHA-1 still works fine in practice, because nobody is engineering your specific corrupted download to match a target hash; accidental corruption is random bit-flipping, not intentional collision construction. That said, when a publisher offers a choice, SHA-256 costs nothing extra to compute and closes the gap entirely, so it is the safer default.