Hash vs digital signature: what each proves, and why content credentials need both

A hash and a digital signature answer two different questions. A hash answers "is this file exactly the one the value was computed from?" A signature answers "who approved this file?" When the hash matches, people often assume they have answered both. They have answered only the first.

This guide explains what each one proves, how to check each, and why the checksum files on download pages and the content credentials on images both use the two together. It sits in the checksums section beside the guides on hashing and verifying files.

What a hash proves

A cryptographic hash such as SHA-256 condenses a file into a short, fixed-length value. NIST's Secure Hash Standard, FIPS 180-4, describes these digests as a way to detect whether a message has been changed, and notes that the property is useful in generating and verifying digital signatures.

So a matching hash proves integrity: your copy is byte for byte the same as the file the published value came from. It does not prove origin. Anyone can compute a hash. There is no secret involved, which means anyone who can edit a download page can publish a new file and a new hash that match each other perfectly.

The strength of that integrity check depends on the algorithm. SHA-256 has no known practical collisions, while MD5 and SHA-1 do, so an attacker can craft two different files that share one of those older values. Our comparison of hash algorithms and which ones still hold up covers the details.

What a signature proves

A digital signature adds a secret. The signer hashes the file, then uses a private key, which only they hold, to produce a signature over that hash. Anyone with the matching public key can check the signature, but nobody without the private key can make a new one.

NIST's Digital Signature Standard, FIPS 186-5, lists what that achieves: a signature can be used to detect unauthorised modifications to data and to authenticate the identity of the signatory. The recipient can also use it as evidence, for a third party, that the signer really did sign the data.

That gives you three things a bare hash cannot:

• Origin. The file was approved by whoever controls the private key.
• Integrity with a source attached. Any change to the file breaks the signature, and the attacker cannot re-sign without the key.
• Evidence you can show others. Anyone with the public key can repeat your check and reach the same result.

A signature has its own limit. It proves who signed, not whether the signer deserves trust. A valid signature from a stolen key, or from a publisher who shipped a bad file, still checks out. That is why you confirm that the key belongs to the publisher you expect, usually by comparing its fingerprint with the one on their website.

How to check each

Checking a hash. Compute the hash of your file and compare it with the published value. On Linux:

sha256sum example-1.0.iso

c398c2a60b8aa61ba2b801a36606c5bd4864d81b5e7d2a42e67b9a6491045ba2  example-1.0.iso

Windows uses Get-FileHash and macOS uses shasum -a 256. The full routine for each system is in the guide to verifying a download with a checksum.

Checking a signature. For a signed checksum file, GnuPG does the work. Ubuntu's download verification tutorial uses this command:

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

Here is the result from a run on Ubuntu 22.04 with a demonstration key. The first block is the untouched file. The second is the same file after one file name inside it was edited.

gpg: Signature made Fri Oct 30 22:52:36 2026 EDT
gpg:                using EDDSA key 4B414A0AE1C708CF642D68C9334040EEC5B2FA54
gpg: Good signature from "Example Release Signing <release@example.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4B41 4A0A E1C7 08CF 642D  68C9 3340 40EE C5B2 FA54

gpg: Signature made Fri Oct 30 22:52:36 2026 EDT
gpg:                using EDDSA key 4B414A0AE1C708CF642D68C9334040EEC5B2FA54
gpg: BAD signature from "Example Release Signing <release@example.org>" [unknown]

"Good signature" means the file is exactly what the key holder signed. The warning only means you have not marked the key as trusted yourself, which is why you check the printed fingerprint against the publisher's. "BAD signature" means the file changed after signing.

Many other signatures are checked for you without a command. Operating systems check the signatures on apps and updates before they install them, and PDF readers check signatures on signed documents.

Why a checksum file needs a signature

Large downloads usually come with a checksum file, and the checksum file itself is what gets signed. This is efficient: one signature over a small text file vouches for every hash in it, and each hash vouches for one large image.

The order of checks follows from that:

1. Verify the signature on the checksum file. Now you know the hashes in it came from the publisher.
2. Check your download against that file. Now you know your file matches a hash the publisher vouched for.

Skip step 1 and you are back to trusting the web page. Skip step 2 and you have a trustworthy list of hashes but no idea whether your file is on it.

The key you check against has to come from somewhere you already trust. Publishers list their signing key's fingerprint on their own website, and some operating systems ship the keys for their own releases preinstalled. A key fetched from the same place as a suspicious download proves very little, because whoever swapped the download could swap the key too.

Method and sources

This comparison is built from the standards that define each mechanism: NIST FIPS 180-4 for SHA-256 and NIST FIPS 186-5 for digital signatures, plus the C2PA specification for how content credentials combine the two. No product is ranked here; the table compares what each mechanism can prove.

Hash vs signature at a glance

The same check for content: credentials use both

The same pairing now protects images and documents. A content credential, defined by the C2PA specification, is a signed record attached to a file. Inside it, a hard binding holds one or more cryptographic hashes of the asset, and a claim signature, made with the signer's private key, covers the record that contains those hashes.

The two parts do the same jobs they do for a download. The hash shows whether the picture changed after the credential was made. The signature shows which camera, app or organisation issued the credential. Remove either one and the credential proves much less.

To see both parts in a real file, follow the guide to reading a C2PA manifest with c2patool, which points out the hash, the signer and the validation result in the tool's output.

Sources

1. NIST FIPS 186-5, Digital Signature Standard
2. NIST FIPS 180-4, Secure Hash Standard
3. Ubuntu tutorial, How to verify your Ubuntu download
4. C2PA Specification 2.5

Questions

• Is a checksum a kind of digital signature?+

  No. A checksum anyone can compute from the file; a signature can only be made by whoever holds the private key, which is what lets it say who approved the file.

• If a file is signed, do I still need to check its hash?+

  Not separately. Checking the signature includes hashing the file and comparing, so a valid signature already tells you the bytes are unchanged.

• What does a signature not prove?+

  It does not prove the signer is honest or the file is safe. It proves that whoever controls the signing key approved these exact bytes.

• Can a signature be valid but the file still be wrong?+

  Yes, if the signing key was stolen or the signer approved a bad file. That is why keys get revoked and why you check that the key belongs to the publisher you expect.