What a Forensic Hash Actually Guarantees

A forensic hash proves one thing: that the data you are holding is bit-for-bit what it was when the digest was computed. It does not prove the acquisition was faithful, that the content is authentic, that nobody altered the original before you arrived, or that a mismatch means tampering. And the much-cited weakness of MD5 and SHA-1 — collisions — is not the attack that would matter if someone did try to swap your evidence.

What is a hash doing in a forensic workflow?

A cryptographic hash function maps input of any length to a fixed-length digest. MD5 produces 128 bits, SHA-1 produces 160, SHA-256 produces 256. The property forensics relies on is that changing the input, by any amount, changes the digest unpredictably — so comparing two digests is a cheap, reliable test for whether two byte streams are identical.

That test does four distinct jobs, and conflating them is where most of the trouble starts:

1. Acquisition verification. Hash the source, hash the image, compare. A match shows the image is a faithful copy of what the tool read.
2. Custody verification. Re-hash the image at each transfer and each analysis. A match shows nothing has changed in your hands.
3. Production verification. Hash a produced file and the file it came from. A match shows the recipient got exactly what you sent.
4. Known-file identification. Compare file hashes against a reference set to eliminate or flag files. The NSRL Reference Data Set is the canonical corpus for this.

Only the first two are about integrity in the sense courts care about. The fourth is a filtering technique whose failure modes are completely different, and it is the one where collision resistance actually becomes relevant.

Why is a collision not the risk people think it is?

The distinction is between three attacks, and only one of them has been demonstrated against MD5 and SHA-1.

• A collision is two inputs, both chosen by the attacker, that produce the same digest.
• A second preimage is: given a specific existing input, find a different input with the same digest.
• A preimage is: given only a digest, find any input that produces it.

MD5 collisions have been practical since the mid-2000s and are now trivial. SHA-1 collisions were demonstrated in 2017, and chosen-prefix SHA-1 collisions — a considerably stronger result, allowing meaningfully different documents rather than near-identical blobs — followed in 2019. NIST has announced a phase-out of SHA-1 for federal use.

None of that is an attack on forensic verification, because forensic verification depends on second-preimage resistance, not collision resistance. To substitute a forged image for a genuine one without detection, an adversary would need to construct a different disk image matching an already-published digest of the real one. That is a second-preimage attack, and no practical second-preimage attack exists against MD5 or SHA-1. The gap between the two attack classes is enormous, and it is the entire answer to "your report used MD5, which is broken".

Where collisions do bite

Three places, and they are real:

Known-file filtering. If a party controls a file's construction, they can build two files that hash identically. Feed one to a hash-set-based deduplication or elimination step and the other slips through or is wrongly discarded. Anything that makes a decision from a hash match on files an interested party may have authored inherits this weakness.

Credibility theatre. An opposing expert who produces two visibly different documents with the same MD5 has not undermined your verification, but they have created a demonstration a jury may find persuasive. The defence is to have used two algorithms from the start, so the demonstration is unavailable.

Reused digests as identifiers. Any system that treats a hash as a unique key — content-addressed storage, dedupe in a review platform — is trusting collision resistance whether it says so or not.

The mitigation is cheap and should be automatic: compute two digests in the same pass. Imaging tools have supported simultaneous MD5 and SHA-1 or SHA-256 for years, and there is no known technique for producing a collision in two different hash functions at once. Where you have a choice, use SHA-256 as the primary. Where you have inherited MD5 from a legacy workflow, keep it for continuity with the earlier records and add a second.

What does a hash not establish?

It does not prove the image is a faithful copy of the original device. It proves the image matches whatever the imaging tool read. If a write blocker failed, if a host-protected area was never presented, if a hardware fault made the controller return different data, the digest will match a flawed read perfectly. Fidelity comes from a tested tool, a working blocker, and a contemporaneous log — see SWGDE's acquisition best practices and the tool testing programmes at CFTT.

It says nothing about authenticity of content. A fabricated document hashes exactly as well as a genuine one. Authentication of content is an evidentiary question with its own machinery — Lorraine v. Markel American Insurance walks through the whole set of rules and is worth reading once in full — and no digest participates in it. In Rossbach v. Montefiore Medical Center the exhibit was destroyed by forensic analysis showing the device could not have produced it. A matching hash would have changed nothing.

It does not prove authorship, custody before your involvement, or that the original was unaltered. Hash coverage begins when you compute the first digest. Everything before that is chain of custody.

A mismatch is not proof of tampering. There is a long list of benign causes, and an examiner who cannot recite it will be made to look careless:

• Unreadable sectors, which imagers substitute with padding — and different tools pad differently, so two correct images of the same failing drive can legitimately differ.
• Re-imaging a solid-state drive. Wear levelling, internal garbage collection and TRIM mean the logical content an SSD reports can change while powered even with no host writes. Do not promise a reproducible whole-device hash for an SSD.
• Re-imaging a live or mounted volume, where the filesystem is being modified as you read it.
• A volume mounted read-write at any point, including accidentally by the examination host.
• Hashing different things and calling them the same thing — a physical device hash and a logical volume hash of the same drive will never match, and neither is wrong.

Whole-device and file-level hashes answer different questions. A device hash covers every sector, allocated and not. A file hash covers content, and depending on the tool may or may not include metadata that lives outside the data stream. Interchanging them in a report is a straightforward error that an opponent will find.

Fuzzy and similarity hashes are not verification tools. Context-triggered piecewise hashing of the ssdeep kind, and other similarity digests, are built to say "these two files resemble each other". That is useful for clustering and for finding variants. It is meaningless as an integrity check, and a similarity score should never appear in a verification section.

Presence in or absence from a reference set means less than people assume. A file matching the NSRL RDS matched a known, distributed file. That is not the same as "benign", and it is certainly not the same as "not relevant". Absence from the RDS means only that the file was not in the collection — which covers a vanishing fraction of all software in existence.

What does verification that survives challenge actually look like?

Hashing is one line in a record that has to hold together. The record needs:

• The source's identity — make, model, serial, capacity in sectors — read from the device, not from the label.
• The tool and version, and evidence you have tested that version. SWGDE's minimum requirements for testing tools sets out what to record; Federated Testing gives you a way to do it without building a lab programme; CFReDS provides images with known answers to test against. ISO/IEC 27041 is the standard that frames all of this as showing a method is fit for purpose, and it explicitly addresses folding vendor and third-party testing into your own assurance argument.
• Two digests, computed in one pass, with the algorithms named.
• A source-side digest where one is feasible, and an explicit statement where it is not. On a live system, a failing drive or an SSD, source hashing may be impossible or non-reproducible. Say that in advance, in the log. Explaining it afterwards, when the numbers do not match, reads very differently.
• Every read error, with its offset and extent. An image with 137 documented unreadable sectors is a good image. An image with an unexplained digest mismatch is not.
• Per-chunk integrity where the format offers it. The Expert Witness format family used by libewf and ewfacquire stores a checksum per data chunk alongside the stored acquisition hash, which means a corrupted region can be localised rather than invalidating the entire image. Raw dd output has no internal integrity at all, so a raw image needs its digest and log kept as carefully as the image itself.
• Re-verification at every transfer, recorded each time.

Bruce Nikkel's Practical Forensic Imaging is the best single treatment of this chain end to end, and it is written around tools you can inspect. FTK Imager remains the most widely used free imaging and verification tool on Windows and is worth knowing because opposing experts will use it.

How does this land in evidence?

Rule 902(14) permits a copy of data from an electronic device or storage medium to be self-authenticated by certification, where the copy is authenticated by a process of digital identification. Hash comparison is the paradigm case of such a process, and 902(14) is the reason a well-documented imaging and verification record can carry authentication without the examiner appearing. Rule 901(b)(9) is the general route for output of a process or system, requiring evidence describing the process and showing it produces an accurate result.

Courts have been consistently unwilling to demand more of digital evidence merely because digital evidence is theoretically alterable. In People v. Goldsmith the California Supreme Court declined to impose a heightened authentication showing on digital images on that basis, and held that testimony from a technician expert in the system's operation was not a prerequisite. But the flip side is in United States v. Durham: where evidence is not readily identifiable and is susceptible to alteration, the foundation required is a chain of custody complete enough to make exchange, contamination or tampering improbable. A disk image is exactly that kind of evidence, and your hashing record is the largest part of how you make that showing.

One last habit. Keep the language precise in the report. "The image was verified" invites the question. "The SHA-256 digest of the acquired image, computed at acquisition on 14 March and recomputed on 2 April, is identical, and matches the digest computed from the source device during acquisition" answers it. Casey's paper on error and uncertainty in digital evidence argued the general case two decades ago and it has not aged: state what you measured, state what it bounds, and do not let a strong number stand in for a claim it cannot support.