What is a hash function: the cryptographic hash explained
A hash function is a calculation that turns an input of any size into a fixed-length value, and a cryptographic hash function does so in a way that makes it computationally infeasible to work backwards to the input or to find two different inputs sharing one output.
The fixed-length output is called a hash, a digest, or a message digest. In evidence work it is often called a digital fingerprint, which describes the role rather than the mathematics.
What does a hash function do?
SHA-256, the function most integrity work runs on, is standardised by the US National Institute of Standards and Technology in FIPS 180-4, the Secure Hash Standard. It produces a 256-bit value, written as 64 hexadecimal characters, from an input of any length. A two-word text file and a two-hour 4K video both come out at exactly that size.
Four properties make a cryptographic hash function usable as a control rather than a curiosity.
- Deterministic. The same input produces the same output on any machine, in any implementation, years apart.
- Fixed length. Output size is independent of input size, so storage and comparison costs are constant.
- Preimage resistant. Given a digest, finding an input that produces it is computationally infeasible. Publishing the value discloses nothing about the content.
- Collision resistant. Finding any two distinct inputs that produce the same digest is computationally infeasible.
Collision resistance, and why it is the property that matters
Collisions exist as a matter of arithmetic. Inputs are unlimited in length and outputs are 256 bits, so infinitely many inputs map to every possible digest. Collision resistance is not a claim that collisions do not exist. It is a claim that nobody can find one.
Why it matters for evidence: if an attacker can construct two files with the same digest, they can present one for hashing and substitute the other later, and the stored value still checks out. The control does not fail loudly. It quietly stops meaning anything.
This is not hypothetical. In February 2017 researchers at CWI Amsterdam and Google announced SHAttered, the first collision for full SHA-1: two visibly different PDF files with an identical SHA-1 digest, produced at a cost Google described as roughly 6,500 CPU-years plus 110 GPU-years. NIST has since set the end of 2030 as the completion date for transitioning away from SHA-1 across all applications. No comparable practical collision has been produced against SHA-256, which is why it remains the working default. Treat any system still quoting SHA-1 or MD5 values for integrity as out of date.
The avalanche effect explained
The avalanche effect is the property that a tiny change to the input produces a completely unrelated output. Flip one bit and roughly half the output bits change.
Explain this to a claims or audit team before anything else, because intuition runs the other way. People expect a small edit to produce a small difference, the way a resized photograph still looks like the photograph. Digests do not work that way at all. Re-saving an image at a marginally different compression level produces a value with no visible relationship to the original.
The practical consequence is the useful part. There is no partial match and no "close enough" reading. Two digests are identical or they are not, and no judgement call sits in between.
Hash function example: which file did we actually decide on?
A vehicle is photographed at intake and the claim is settled three weeks later. Eight months on, the file is reopened and three versions of the same image sit across two folders and an email thread, two of them resized for a report. Recomputing SHA-256 on each and comparing against the value recorded at receipt identifies which one is the file the system received.
Anyone can run that check without special software. On macOS or Linux, shasum -a 256 filename. On Windows, certutil -hashfile filename SHA256. That independence is the point: a digest verifiable only inside the system that produced it asks the other side to trust that system.
What a hash proves, and what it never will
Be exact here, because this is the sentence that gets stretched.
A matching hash proves a file is unchanged. It proves nothing about what the file depicts. The digest is computed over bytes. It has no view on whether the damage was genuine, staged, photographed on a different vehicle, or generated entirely. A fabricated image hashes just as cleanly as an honest one.
Three further boundaries follow from the same fact.
- It does not identify an author. Attribution needs a cryptographic signature, because a hash anyone can recompute is a hash anyone can produce.
- It does not date anything. Pair it with a timestamp and you get existence of that exact content at that moment, no more.
- It does not detect an edit made before hashing. The digest fixes the content from the moment of calculation onwards.
Used within those limits, a hash is one of the few controls in the evidence integrity toolkit that holds up under any amount of cross-examination, precisely because the claim it makes is so narrow. Stretch it into a claim about authenticity and it becomes the weakest thing in the file. The tamper evident entry covers how hashing combines with signing and session records to close the gaps a digest leaves open on its own.