How to Prove a File Has Not Been Altered

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, the file is presumed unmodified. This is not conjecture or probability—it is the direct logical consequence of how cryptographic hash functions work.

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 uniquely corresponds to 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] The match itself proves the file unchanged. There is no intermediate step, no expert judgment required. The function either produces identical values or it does 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. A strong cryptographic hash cannot.

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. The digest is not an estimate, an assessment, or an inference. It is a computational fact. If the file has been changed, the digest will be different. If the digest is the same, the file content is the same.

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. Everything before it is the original. Everything after it is either unchanged (if hashes match) or altered (if they do not).

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 alone answers whether the file was altered; it does not answer when, by whom, or how. The custody record answers those questions.

The timing also defeats arguments about the file's history before the hash was made. The hash does not prove the file was not altered before you took control of it—only that it has not been altered since. That is sufficient, because at the moment you take possession and record the hash, you are establishing the baseline for your custody. What existed before is not your responsibility. 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, the file is unchanged. [2] This comparison requires no expert testimony about hash functions, no esoteric explanation. The values either match or they do not. Both digests are produced by the same algorithm applied to the same file at different moments in time. Identical results mean identical file content.

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 error, any alteration, any corruption in storage will change the result. The hash detects it immediately.

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. This is its power as evidence—it is as close to mathematical proof as forensic science comes.

The Record That Connects Them

The three elements—original hash, recomputation, comparison—must be documented. Federal Rule of Evidence 902(14) provides that a digital copy of data taken from an electronic device or system is self-authenticating if accompanied by a certification by a qualified person stating that the certification requirements of Rule 902(11) or (12) are met. [2][3] The certification requirement ensures that the original hash, the custody record, and the identity of the person who made the hash are all part of the evidence file.

Judicial commentary on Rule 902(14) indicates that identical hash values for the original and copy demonstrate that they are exact duplicates. [4] This recognition reflects the mathematical nature of the proof rather than an opinion-based determination.

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, meets 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 This Proves No Alteration Occurred

The proof is not probabilistic. It is not an expert's opinion about whether the file "appears" unchanged or "is consistent with" not having been altered. The matched hashes are mathematical evidence that the file's content is identical.

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, the file content must be identical. There is no reasonable alternative explanation.

If someone claims the file was altered, they are claiming that the same file was changed in such a way that the hash remained identical. For a strong cryptographic hash, this claim is equivalent to claiming perpetual motion or a violation of the laws of thermodynamics. It is not that it is unlikely. It is that it is computationally infeasible—outside the realm of practical possibility under known mathematics.

Therefore, if the hash matches, the file is proven unchanged. Not suspected. Not likely. Proven.

Authentication in Federal Court

The Federal Rules of Evidence recognize hash-based verification as a means of authenticating digital evidence. [2][3] This means you may not necessarily need to call a witness to explain how the hash was made or why it proves the file is unchanged. The certification can provide the foundation for authentication. This reflects judicial recognition that the hash serves as mathematical verification of file integrity.

Nonetheless, in contested cases, a brief explanation of the hash function and the matching process may be helpful—not to establish that the test was performed correctly, but to explain to the court or jury what the matching digests mean. The explanation is straightforward: identical hashes mean identical file content. Different hashes mean the file was altered.

The burden of proof on alteration shifts once the hashes match. The party challenging the file's integrity must produce evidence—not speculation—that the hash itself was altered, the function was flawed, or some other technical failure occurred. Because hash functions are well-established, publicly available, and mathematically vetted, this burden is significant.

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. No witness is required to establish that the data is unchanged through this particular verification method. The matched hashes provide the evidence. If an opposing party wishes to challenge this, they must produce evidence that one of the hashes is wrong, that the function is flawed, or that the custody record is fabricated—not merely that alteration is theoretically possible.

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 proof. This is how digital evidence demonstrates integrity.