How to check a file's checksum, and what it proves

The command

macOS or Linux:

shasum -a 256 ubuntu.iso

Windows PowerShell:

Get-FileHash ubuntu.iso -Algorithm SHA256

Both print a 64-character hexadecimal string. Compare it with the one the publisher printed.

Compare all of it. Checking that the first and last few characters match is a habit worth breaking: those are exactly the characters an attacker constructing a lookalike would arrange to match, and eyeballing the middle is what the comparison is for. Paste both strings somewhere and let the computer do it.

What a matching hash actually proves

This is where people get it wrong in both directions.

If the hash came from the same page as the download link, a match proves the file arrived intact: no truncated transfer, no corrupted byte, no mirror serving a stale build. That is genuinely useful and it is the common case.

It does not prove the file is what the publisher intended, because anyone who could replace the download could replace the hash next to it. The two travelled together.

If the hash came from somewhere else — the publisher’s signed checksum file, their announcement mailing list, a repository you already trust, a second independent mirror — then a match starts proving something about authenticity too, because an attacker would have had to compromise both.

This is why serious projects publish a signed SHA256SUMS file rather than a hash on the download page. The signature is the part that matters; the hash is just what the signature covers.

When a hash is worth taking yourself

Publishers are not the only reason to compute one.

• Before and after a move. Hash the source, hash the destination, compare. That is the whole of verified copying.
• Before archiving something. Record the hashes of a folder now; in three years you can prove nothing in it has moved a byte, including the bytes that rot silently on a disk nobody has read in three years.
• When two files should be identical and you want to stop wondering. Two hashes settle it in seconds, without opening either.

A whole folder, not one file

For a directory, what you want is a manifest: one line per file, path and hash, written at a moment you trust. Then verifying is comparing the tree against the manifest, and the output is the list of files that changed rather than a yes or no.

By hand:

find . -type f -exec shasum -a 256 {} + | sort > manifest.txt
# later
find . -type f -exec shasum -a 256 {} + | sort | diff - manifest.txt

Fine for a project folder. It gets unhelpful at scale, because diff on thousands of lines does not distinguish “this file changed” from “this file moved” from “this file is new”.

Which algorithm

Use SHA-256. It is the default nearly everywhere and there is no practical reason to choose otherwise.

MD5 and SHA-1 are still printed by some publishers. Both are broken for the purpose of proving a file has not been deliberately replaced — constructing two different files with the same MD5 is a laptop exercise now. They are still adequate at catching accidental corruption, which is why they linger. If both are offered, use the SHA-256.

The programs for this

• BootForge writes a manifest of every file in a tree and verifies the tree against it later, reporting what changed rather than a single verdict.
• CopySure does the copy and the verification together: it re-reads every file off the destination disk and checks it byte for byte. diff compares two trees that already exist.
• PackSafe splits a large archive into volumes with a manifest, so if a piece goes bad later you can prove which one.
• DeviceDriver seals a folder into a manifest of every file’s SHA-256 and proves months later that not one byte moved. It is explicit that this checks file integrity against your own manifest, and does not verify code signatures.

Free while we are in preview, one file each, Windows and Mac.

If the hash does not match

Download it again, from a different mirror if there is one, before assuming anything sinister. Failed transfers are common and attacks are not.

If it fails twice from two mirrors, stop and tell the publisher. Do not run it.