A File Hash Checks Bytes, Not the Truth of a Claim

A matching file hash can help answer a narrow question: does this copy agree with the reference at the byte level? It cannot, by itself, tell you whether a statement inside the file is true.

That distinction matters when sharing reports, retaining downloads or comparing document versions. A file can remain unchanged while containing an incorrect date, a mistaken conclusion or an unsupported claim.

What the hash operation does

A cryptographic hash algorithm calculates a digest from input data. SHA-256 produces a 256-bit digest, commonly displayed as 64 hexadecimal characters. Calculate both values with the same algorithm before comparing them.

NIST’s Secure Hash Standard describes secure digests as a means of detecting changes. Different inputs can theoretically produce the same digest; secure algorithms are designed to make finding such collisions computationally infeasible. A matching SHA-256 digest provides strong practical evidence for a byte comparison, rather than an absolute guarantee that collisions cannot exist. NIST FIPS 180-4, Secure Hash Standard

This operation concerns the file’s data. It does not evaluate the meaning of a sentence or verify the events described in a photograph.

A simple example of the limit

Imagine a fictional workshop note that says a parcel arrived on Tuesday. The parcel actually arrived on Wednesday, but the writer entered the wrong day.

The owner saves the note and records its SHA-256 digest. A later copy produces the same digest.

The comparison supports that the later copy agrees with the recorded file. It does not correct the arrival date. Investigating that date would require other evidence, such as the relevant delivery record.

The reverse also matters. If two versions produce different digests, the comparison establishes a difference in the hashed input. It does not explain whether the change was a correction, a new export, an accidental edit or deliberate interference. Do not assign a motive from a mismatch alone.

The reference digest needs its own context

A comparison depends on the reference you compare against. Ask who supplied it, which exact version it describes and how you obtained it.

If someone replaces both a file and its unauthenticated reference digest, those two values can still agree. The agreement alone does not establish that either came from the expected publisher. A digest copied from the same untrusted location as the file does not independently resolve that concern.

For a routine record, keep the algorithm, file/version identifier, reference source, comparison result and the date you performed the check. That date records your check; it is not cryptographic proof of when the document was created.

A local SHA-256 check in PowerShell

Microsoft’s Get-FileHash command can calculate a file’s digest. This example explicitly selects SHA-256 and treats the supplied path literally. Replace the sample path with the file you intend to inspect:

Get-FileHash -LiteralPath '.\example.txt' -Algorithm SHA256

The command reads the file and returns the algorithm, digest and path. It does not upload the file or compare the result with a trusted reference for you. Match the returned value against the reference for the intended version, using the same algorithm. Microsoft Learn — Get-FileHash

A rename alone does not change file contents. A document export can change underlying bytes even when the visible pages look similar. A changed hash therefore calls for an explanation of what changed, not an automatic conclusion that the visible information is false.

A bare hash is not a digital signature

A digital signature adds functions beyond digest comparison. NIST’s Digital Signature Standard describes modification detection and signatory authentication. Interpreting a signature also depends on the relevant key and identity verification context. A bare SHA-256 value does not provide those functions on its own. NIST FIPS 186-5, Digital Signature Standard

Neither this file comparison nor the presence of a signature is, by itself, a review of a document’s factual claims. Questions about provenance, authorship, timing and legal use require evidence appropriate to those questions.

Describe the result precisely

A useful record might say:

The SHA-256 digest calculated for this copy matched the reference recorded for the stated version. The comparison did not assess the accuracy of the document’s contents.

This is an illustrative result statement, not a report of a check on a real customer file. Keep the comparison result separate from any later factual or provenance review.

When packaging and reporting are useful

For a one-off comparison, the free PowerShell command above may be all you need. If you repeatedly preserve a selected file set and need an inventory plus readable PDF records, review SIGMA PROOFKIT’s packaging and reporting workflow. That additional workflow does not change what matching hashes can establish.

Sources

• NIST FIPS 180-4 — Secure Hash Standard: digest behavior and security properties.
• Microsoft Learn — Get-FileHash: command syntax and file-content hashing.
• NIST FIPS 186-5 — Digital Signature Standard: signature functions beyond a bare hash.

The workshop note and result wording are original illustrations. This article does not establish forensic certification, legal admissibility or a complete chain-of-custody procedure.