What a file hash proves, and what it doesn't

“The hashes match” sounds like a verdict of safe. It is narrower than that. A hash answers one question precisely, and several others not at all.

What a match proves

A hash function reads every byte of a file and produces a short fingerprint. Change one bit of the file and the fingerprint changes beyond recognition. So when the file hash checker reports that your file’s SHA-256 equals the one you pasted, you know one thing for sure: the two files are identical.

That property is called integrity. It protects against a connection that dropped, a disk that failed, a file cut short or corrupted in transit.

What a match does not prove

Authenticity, meaning who made the file, is a separate question. The hash tells you the file matches a hash. Whether that hash came from the person you trust depends on where you got it.

Suppose you download a program and its hash from the same website. If an attacker has taken over that site, they can replace the file and the hash together. Your check will say they match, because both were changed. The match is real, and it proves very little.

Better practice:

• Get the hash from the publisher’s official page, over a secure connection, and ideally by a different route than the download itself.
• Prefer a digital signature where one is offered. A signature is made with the publisher’s private key and checked with their public key, so an attacker who swaps the file cannot make a valid signature for it. OpenPGP, described in RFC 9580, is one common system. You need the right public key from a trustworthy source for this to mean anything.

Even then, a verified file proves it came from the publisher, not that the publisher’s software is free of faults. And hashes don’t scan for viruses.

Collisions, MD5 and SHA-1

A hash has fewer possible outputs than there are possible files, so in principle two different files can share one. That is a collision. A good hash makes them impossible to find on purpose.

MD5 and SHA-1 no longer meet that standard. Researchers have shown how to build two different files with the same MD5, and RFC 6151 sums up the weaknesses and advises against using MD5 where collision resistance matters, such as signatures. SHA-1 has also had collisions produced in practice. SHA-256, from the same standard family as SHA-512 (FIPS 180-4), has no known collision attack.

That doesn’t make MD5 and SHA-1 useless. For spotting a broken download, an accidental error is overwhelmingly unlikely to produce a matching hash, and they do that job fine. The risk is a deliberate swap, where an attacker prepares two files to match. When a publisher offers a choice, use SHA-256. The hash checker accepts all four so that you can compare with whatever a page lists.

A hash is not encryption

Encryption scrambles content so that someone with the key can turn it back. A hash is one-way. A 4 GB file and a one-word file both become the same short length, and nothing in the output lets you rebuild the input. You can’t “decrypt” a hash, and a hash doesn’t protect a file’s contents from anyone who holds the file. (To understand real encryption, see encryption explained.)

Small, guessable inputs can be found

One-way doesn’t mean unbreakable when the input is short or predictable. If a hash of a password is stolen, an attacker can hash a long list of likely passwords and see which one matches. That is guessing, not reversing, but for a weak password it works in moments. This is why sites should protect passwords with slow, salted functions rather than a plain SHA-256, and why your own passwords should be long and random.

The same applies to short files. Hashing a short, known-format value such as a phone number invites the same guess-and-check.

A quick rule of thumb

• Matching hash from the official page: the file is intact and is what they published.
• Matching hash from the same place you downloaded the file: intact, but an attacker who controls the place could have changed both.
• Valid signature from a key you trust: intact and from the signer.