How to share a checksum with someone

Somebody is waiting on a 4 GB video, a disk image, a database dump or a set of raw camera files. You put it on a transfer service, you paste the link into an email, and because you are conscientious you paste the checksum underneath it. Your recipient runs it, the value matches, everybody feels better.

What they have actually established is that the bytes that left the transfer service are the bytes that reached their disk. That is worth having — truncated downloads, a dying cable and a flaky network share are all real and all common, and this catches every one of them. What it cannot establish is that the file is the one you made, because anything with the power to change the file in flight can change the line of hexadecimal sitting next to it.

So there are two different jobs here with two different answers, and knowing which one you are doing takes about five seconds. This page covers both: what to send, in what form, and when the channel has to change. If you need the underlying reasoning in more depth, what a digest proves about tampering is the page that goes all the way down.

What a digest in the same message proves

Be concrete about who you are worried about. Almost nobody sharing a file has an adversary; they have a flaky upload and a recipient who is going to open a half-downloaded archive and blame them for it. For that, a digest in the same email is the right amount of effort and the asterisks below do not apply.

The asterisks start when a third party sits in the middle. A transfer service, a shared drive, a forum post, a compromised mail account, a support ticket system — in each case, whoever controls that channel controls both the file and the number you published beside it. Changing both is not a sophisticated attack; it is the obvious move. A digest defends against accident everywhere, and against intent only when it reaches the reader by a route the attacker does not hold.

Send a checksum somebody can actually use

1. Hash the file you are really sending

   Not the folder you zipped it from, not the original before you re-exported it. If you compress, encrypt or re-save anything, every one of those steps produces new bytes and therefore a new digest, so the hash has to come last. Drop the finished file into the Files tool and take the digest from the row's copy button rather than selecting 64 characters by hand.

2. Write down four things, not one

   A digest alone makes your recipient guess. Send the algorithm's name, the digest in full, the exact filename, and the size in bytes. The algorithm stops them computing the wrong function; the filename stops them checking the wrong file; the size catches a truncated transfer in one glance, before anybody hashes anything at all.

3. Send it on a different route if it matters

   If the stakes are “don't open a corrupt file”, one message is fine. If they are “prove this is what I sent”, the digest has to arrive somewhere the file did not: a text message, a phone call, a page on your own site, a note you handed over in person last month. The rule of thumb is that the two should not be forgeable by the same person.

4. Tell them how to check it

   Most people receiving a checksum have never used one, and an unexplained block of hex is an invitation to ignore it. One line of instruction is enough — what to do with the file, and what a match means. Checking a file means reading the file, so on a Mac the short answer is the Verify tool: they leave the segmented control on Against a Checksum, paste the value you sent, hand over their copy, and read a green seal and a sentence instead of comparing two 64-character strings by eye. The algorithm is detected from the digest they paste, so there is nothing for them to choose. This is the step that decides whether your effort was worth anything.

5. Keep your own copy

   Paste the digest into the note, ticket or job folder where the delivery is recorded, next to the filename and the date. You cannot get the value back later: once the original has been edited, re-exported or cleared off your own disk, there is nothing left to compare a complaint against. Thirty seconds now, against re-uploading 4 GB on a guess.

The message to write

Short, plain, and formatted so nothing mangles the hex. Something close to this:

File:     shoot-final-v3.zip
Size:     4,183,440,892 bytes
SHA-256:  ba7816bf…f20015ad   (64 characters, case does not matter)

To check it: hash the file with a SHA-256 tool and compare
the result with the line above. A match means your copy is
identical to mine, byte for byte.

Write the digest out in full in the real message — it is abbreviated above only so the example stays readable. Put it in a code block or on its own line if the tool you are using allows it: email clients insert line breaks into long unbroken strings, chat apps sometimes turn a 64-character token into a link, and a digest that arrives with a space in the middle produces a mismatch that has nothing to do with your file. Copying a digest without mangling it covers what goes wrong in transit and how to spot it.

Send the route along with the value. Checking a file means reading the file, which has to happen on the machine holding it: on a Mac that is Rocket Hash and its Verify tool, which takes the value you sent and their copy and returns a verdict rather than a second string to read. Point a first-timer at verifying a SHA-256 checksum and you have covered the whole job in one link. If they are on Windows rather than a Mac, warn them that the tool built into it reports digests in uppercase — hexadecimal is case-insensitive, so an uppercase copy of your value is still your value.

Reading a digest out loud

Sixty-four characters is about a minute of careful speech and an excellent way to introduce an error. Read it in groups of four, say “alpha, bravo, charlie” rather than the letter names, and agree the case convention first — or skip the heroics and read the first eight characters and the last eight.

An abbreviated comparison is perfectly sound against accidental damage. Flip one bit of a file and about half of the 256 bits of its SHA-256 change, which works out at roughly 60 of the 64 hexadecimal characters — damage has no way to rearrange the middle of a digest and leave both ends alone. It is not a proof against somebody deliberately constructing a near-match, which is far cheaper to do than forging the whole value. Use the short form for “did this copy survive the courier”, the full value for anything you might have to stand behind.

When a digest is not enough

There is a hard limit to what sharing a number can do: a checksum has no author. Whoever publishes one can publish a new one for a new file, and nothing in the mathematics objects. If the recipient needs to prove months later that the file came from you — contracts, evidence, anything legal, software other people will run — you need a signature, which binds the digest to a key somebody can check independently.

For a file going to one person you already have a relationship with, that is usually overkill and a phone call is not. For a release going to strangers, it is the baseline, and publishing checksums with a release covers how the two fit together.

One more honest limit: none of this says anything about whether the file is safe. A digest proves a match, not innocence. A virus-laden installer with a correct checksum is an authentic virus-laden installer.

Troubleshooting

They say it does not match

Re-hash your own copy before you re-upload anything. If your value has moved, you sent one file and hashed another — usually the original rather than the archive that went up. If it has not moved, ask for the size in bytes of the file they are holding: anything short of yours means the transfer stopped early and neither digest is at fault. Only when those two agree is the file itself worth suspecting. What to do when a checksum does not match has the rest in order of likelihood.

The digest arrived with a space or a line break in it

Mail clients wrap long strings, and some chat clients insert zero-width characters or capitalize the first letter. Resend it inside a code block, or as a small attached text file, and tell them to count the characters after pasting: 64 for SHA-256, no spaces anywhere.

I zipped the file after hashing it

Then the digest you sent describes something your recipient will never see. Compression and archiving produce entirely new bytes, and even re-zipping identical contents a second time usually gives a different digest because the archive records timestamps. Hash whatever you upload, at the moment you upload it.

They do not know what to do with it

This is the commonest failure of all, and it is a copywriting problem rather than a technical one. Give them one place to do it and one sentence of what a match means. If they are verifying a file you sent rather than a download from a website, verifying a file after a transfer is the page to send them to.

I need digests for two hundred files, not one

Then stop sending messages and send a manifest: one text file, one line per file, in the format every checksum tool already reads. Exporting a checksum manifest covers producing one and what to call it.