File Integrity & Hashing: Fingerprints, Checksums, and Tamper Detection

You download an installer, copy a backup across the network, or hand a file to a teammate — and later you need to answer one question: is this the exact same file, byte for byte, that I expected? Comparing whole files is slow and usually impossible (you don't have the original handy). The practical answer is a hash.

A cryptographic hash function takes any input — one byte or ten gigabytes — and produces a fixed-size fingerprint called a digest (or checksum). Three properties make it useful:

• Deterministic — the same input always produces the same digest.
• Avalanche effect — change a single bit and the digest changes completely. There is no 'close'; it either matches or it doesn't.
• One-way — you can't work backwards from a digest to the original data.

So instead of shipping a whole file to prove it's unchanged, you ship its tiny digest. If two files share the same SHA-256 digest, they are — for all practical purposes — identical.

The standard tools are named after their algorithms — md5sum, sha1sum, sha256sum, sha512sum. Each prints the digest, two spaces, then the filename.

To grab just the digest (for scripting or to store in a variable), keep the first field: sha256sum report.pdf | awk '{print $1}'.

The algorithms differ in digest size and, crucially, in security:

• MD5 and SHA-1 are broken. Attackers can craft two different files with the same MD5 (or SHA-1) digest — a 'collision'. A matching MD5 therefore no longer proves a file is authentic. You'll still see MD5 used as a cheap non-adversarial change detector, but never trust it against a motivated attacker.
• SHA-256 (and SHA-512) are the current standard for integrity and authenticity. When a project publishes checksums for its releases, they're almost always SHA-256.

Rule of thumb: reach for `sha256sum` unless something explicitly requires otherwise.

The most common real task: you downloaded a file and the project lists its SHA-256. Recompute locally and compare — if even one character differs, the file is not what the project released (corrupted, truncated, or tampered), so don't run it.

Doing that by eye across dozens of files is error-prone. Instead, save the digests to a manifest (conventionally SHA256SUMS) and let the tool do the comparison.

Here's the subtlety that trips people up, and it's worth getting right. A checksum answers *"does this file match this digest?" — that's integrity. It reliably catches accidental corruption, and it catches tampering if you trust where the digest came from*.

But think about the attacker. If someone can replace the file on a download server, they can usually replace the checksum on the same page too — and make the two match. Your sha256sum -c would happily print OK, because the file really does match the (attacker-supplied) digest. So a checksum sitting next to the download proves integrity, not authenticity — it proves the bytes match a digest, not that the digest is genuinely the project's.

Closing that gap needs a cryptographic signature. Projects sign their SHA256SUMS file with their private key; you verify it with their public key using gpg --verify. That gives a chain of trust:

• you trust the project's public key (obtained once, out-of-band), →
• the signature proves the SHA256SUMS manifest is genuinely theirs and unaltered, →
• the manifest (via sha256sum -c) proves each file matches.

A valid signature is what turns "these bytes match a number on a web page" into "these bytes are really what the project published."

The transcript below is the verification half. The GnuPG Essentials lesson (gpg-essentials) picks up from here: you make a key, sign a SHA256SUMS of your own, verify it, and learn to read the four different verdicts gpg can give.

You have a real shell. These commands create a throwaway file, fingerprint it, baseline a manifest, and prove verification catches a change — nothing here touches the rest of the system.