September 13, 2026 · Updated October 8, 2026 · Hash Verification & Integrity
How to Prove a File Has Not Been Altered
Calculate and record a hash digest of a file at a known time; then independently recompute the hash and compare. If both digests match, that is strong evidence the file has not been altered since the reference hash was recorded. The showing rests on three elements: a cryptographic hash function, a fixed-time reference, and a documented record connecting them.
The Three-Part Test
To prove a file has not been altered, you must establish three things: a hash digest calculated at a known moment and recorded in custody documentation; independent recomputation of that digest from the file as it exists now; and a match between the two. If those elements align, you have strong evidence that the file has not been modified since the reference hash was recorded. That conclusion follows from how cryptographic hash functions work, and it remains open to challenge on how and when the reference hash was made.
A hash function is a one-way mathematical operation. It accepts a file of any size and produces a fixed-length output, called a digest, that is derived from the digital content of that file. [1] Any change to the file—one byte altered, one bit flipped—will, with overwhelming probability, produce a different digest. [1] A match is therefore strong evidence that the file is unchanged. The comparison itself involves no subjective judgment: the values either match or they do not.
The Hash Function and the Digest
The hash function used in digital forensics and legal proceedings must be cryptographic—that is, collision-resistant. [1] A cryptographic hash is designed such that it is computationally infeasible for an attacker to alter a file and deliberately produce the same digest; the computational cost is so high as to be, for practical purposes, impossible. This is why collision resistance matters in evidence. A non-cryptographic hash, or a weak one, can be deliberately manipulated. For a strong cryptographic hash, no practical way to do so is known.
Cryptographic hash functions specified in the NIST Secure Hash Standard include SHA-256, which is widely used in digital forensics. [1] The output is presented as a hexadecimal string—a sequence of letters and numbers that looks like nonsense to the untrained eye but is, in fact, a precise mathematical fingerprint of the file's contents.
It is this precision that gives the hash its evidentiary power. If the file has been changed, the digest will, with overwhelming probability, be different. If the digest is the same, it is computationally infeasible, with a current algorithm such as SHA-256, that the content differs.
The Critical Moment: When the Hash Is Made
Timing is where custody enters the analysis. A hash digest is only useful if it is recorded at a known moment—ideally, the moment the file enters the hands of the investigator or is copied from a device. [2] That moment creates a fixed reference point. After it, matching hashes are strong evidence that the file is unchanged, and a mismatch shows that something changed.
This is why the digest must be documented in the chain of custody record, not calculated afterward from memory or reconstructed months later. The earlier in the process the hash is recorded, the stronger the inference that no intervening alteration occurred. If a hash is calculated and recorded immediately upon seizure, there is little opportunity for tampering. If a hash is calculated weeks later, the question becomes: what happened in between? The hash comparison addresses whether the file was altered; it does not answer when, by whom, or how. The custody record answers those questions.
The timing also limits what the hash can say about the file's history. The hash does not show the file was not altered before you took control of it—only that it has not been altered since. At the moment you take possession and record the hash, you establish the baseline for your custody; questions about what happened before that moment have to be answered, if at all, by other evidence. What exists after the hash must match the hash or you have evidence of change.
Independent Recomputation and Comparison
The proof is completed by recomputing the hash. You take the file as it exists now—in your digital evidence storage, on your forensic image, in the evidence repository—and run it through the same hash function. The function produces a new digest. You compare this new digest to the original digest recorded in your custody documentation.
If the digests are identical, that is strong evidence the file is unchanged since the reference hash was recorded. [2] Both digests are produced by the same algorithm applied to the same file at different moments in time. Unless a compliant Rule 902(14) certification with notice is used, a witness will ordinarily need to explain how the hashes were computed and recorded.
This is the classical forensic test: verification by independent means. You are not relying on the original calculation being correct; you are verifying it by performing the calculation again. [5] Any alteration or corruption in storage will, with overwhelming probability, change the result, and the comparison will reveal it.
The recomputation can be performed by anyone with access to the file and the hash algorithm. It need not be the original examiner. It need not be done in real time or in court. It is a reproducible, objective test, which is its power as evidence.
The Record That Connects Them
The three elements—original hash, recomputation, comparison—must be documented. FRE 902(14) makes data copied from an electronic device, storage medium, or file self-authenticating if it is authenticated by a process of digital identification, shown by a qualified person's certification, with Rule 902(11) notice. [2][3] The Advisory Committee Note identifies hash comparison as the usual method. In practice, the certification is where the original hash, the custody record, and the identity of the person who made the hash are set out.
The Advisory Committee Note to Rule 902(14) explains that identical hash values for the original and copy reliably attest that they are exact duplicates, because a match makes it highly improbable that they differ. [2][4]
Where Rule 902(14) does not apply, or as an alternative, Rule 901(b)(9) permits authentication through "evidence describing a process or system and showing that it produces an accurate result." [5] A hash function, properly documented and explained by a knowledgeable witness, can meet this requirement. You establish that the hash function is a recognized cryptographic algorithm, that it was applied to the file, that it was reapplied to the same file, and that the values matched. You have described a process that produces an accurate result—the identification of unchanged files.
Why a Match Is Strong Evidence of No Alteration
If the hashes match, it is computationally infeasible, with a current algorithm such as SHA-256, that the file was changed after the reference hash was recorded. That is a probabilistic conclusion, but the probability of error is negligible.
This works because of two properties of cryptographic hash functions. First, they are one-way: you cannot reverse-engineer a file from its digest. Second, they are collision-resistant: two different files will not produce the same digest except through computational effort so vast as to be impractical. [1] Together, these properties mean that if the digest matches, a realistic challenge is less likely to be to the mathematics than to how and when the reference hash was recorded.
If someone claims the file was altered after the reference hash was recorded, they are in effect claiming that it was changed in a way that left a strong cryptographic hash identical. No practical method of doing that is known for SHA-256, which is why challenges usually focus on the record of the reference hash instead.
A matching hash is strong evidence of integrity. The opponent may still challenge how and when the hash was recorded, and the weight of the evidence remains for the fact-finder.
Authentication in Federal Court
The Federal Rules of Evidence recognize hash-based verification as a means of authenticating digital evidence. [2][3] If the proponent uses a compliant Rule 902(14) certification and gives the notice Rule 902(11) requires, a witness may not need to be called to explain how the hash was made. Otherwise, a witness will ordinarily need to explain how the hashes were computed and recorded.
Nonetheless, in contested cases, a brief explanation of the hash function and the matching process is usually needed, both to show how the test was performed and to explain to the court or jury what the matching digests mean. The explanation is straightforward: matching hashes are strong evidence that the content is identical, and different hashes show that the content changed.
A matching hash does not shift the burden of proof. The party challenging the file's integrity may still question whether the reference hash was recorded when and as claimed, whether the right file was hashed, or whether the custody record is accurate. Because hash functions are well-established, publicly available, and mathematically vetted, those challenges usually target the record rather than the algorithm.
Worked Example
Suppose a digital forensic examiner acquires data from a mobile device. At the moment of acquisition, the examiner calculates the SHA-256 hash of the device's storage: a7f3e8c2d1b9... (illustrative). This hash is recorded in the chain of custody documentation, with the date and time. The examiner's name, badge number, and certification are noted. Six months later, at trial preparation, a second examiner independently recomputes the SHA-256 hash of the same data from secure storage: a7f3e8c2d1b9... (illustrative). The hashes match.
This match is evidence that the data has not been altered between the moment of acquisition and the moment of recomputation. Unless a compliant Rule 902(14) certification with notice is used, the examiners will ordinarily testify to how each hash was computed and recorded. An opposing party may challenge whether one of the hashes is wrong, whether the function was applied correctly, or whether the custody record is accurate, and the weight of the evidence remains for the fact-finder.
Conclusion
Proving a file has not been altered requires the same rigor as proving anything else in forensics: a method, a baseline measurement, independent verification, and documentation. The hash function provides the method. The custody record provides the baseline. The recomputation provides the verification. The match is the evidence. This is how digital evidence demonstrates integrity.
Common questions
This is general information about evidence-handling practice, not legal advice, and it does not create an attorney–client relationship. Whether any record is admissible is determined by a court under the applicable rules of evidence. Consult qualified counsel about your own matter.
- How do you prove a file is unchanged?
- Calculate a cryptographic hash of the file and record it in custody documentation at a known time. Later, independently recompute the hash. If both digests are identical, that is strong evidence the file is unchanged since the first hash was recorded. This works because cryptographic hash functions are one-way and collision-resistant: with a current algorithm such as SHA-256, a different file producing the same hash is computationally infeasible. The opponent may still challenge how and when the original hash was recorded. [1][2]
- What does an independent verification require?
- Independent verification requires that you recompute the hash using the same hash function applied to the file as it exists now, then compare the result to the original hash recorded in custody. The comparison must be documented. Both digests should be identical if the file is unchanged. [2][5]
- Why does the timing of the original hash matter?
- The original hash creates a fixed reference point at a known moment. Recording it in custody documentation immediately upon taking control of the file establishes that baseline before any opportunity for alteration. A later match is strong evidence that the file has not changed since that moment; alteration after the hash is recorded will produce a different digest when recomputed. [2][4]
Sources
- [1] Federal Information Processing Standard (FIPS) 180-4, Secure Hash Standard (SHS) — National Institute of Standards and Technology (NIST)
- [2] Rule 902. Evidence That Is Self-Authenticating — U.S. Courts / Legal Information Institute
- [3] U.S.C. Title 28 - Federal Rules of Evidence Rule 902 — U.S. Government Publishing Office
- [4] Self-Authentication of Electronic Evidence: New Rules 902(13)-(14) — U.S. Courts (Southern District of Texas)
- [5] Rule 901. Authenticating or Identifying Evidence — U.S. Courts / Legal Information Institute
CustodyTrack creates tamper-evident chain-of-custody records that any third party can verify. See how it works →
For this audience: Chain of Custody Software for Private Investigators