Hash Values Explained

What a hash value actually is

A hash is a fixed-size fingerprint of a file or drive. Feed a 500GB hard drive into a hash algorithm and you get a 64-character string. Change one bit anywhere on that drive and the hash changes completely. This makes hashes perfect for proving nothing changed between seizure and trial.

Think of it like this: You seal a box with wax. Break the seal and you know someone opened the box. Hash values are the digital version. Break the hash (by changing the file) and you know someone messed with the evidence.

The algorithms: Which to use

Four hash algorithms show up in forensics. Two are dead. Two are alive. Use the alive ones.

MD5 (dead)

128-bit hash. Fast. Produces a 32-character hexadecimal string. Problem: researchers can create two different files with the same MD5 hash (called a collision). This breaks the fundamental promise of hashing. Courts know MD5 is broken. Defense will challenge it.

You still see MD5 in old reports from the 2000s. Some tools still compute it for backwards compatibility. Do not use it for new cases. If someone hands you evidence with only an MD5 hash, compute a SHA-256 hash yourself and document both.

SHA-1 (dead)

160-bit hash. 40-character string. Better than MD5 but also broken. Google demonstrated practical SHA-1 collisions in February 2017 (SHAttered attack). NIST officially deprecated SHA-1 in 2017 per NIST Special Publication 800-57 Part 1 Revision 5, prohibiting its use for digital signature generation. Some agencies still use it because "that is what we have always done." Do not be that agency. Move to SHA-256.

SHA-256 (use this)

256-bit hash. 64-character string. Current standard for law enforcement and forensics. Fast enough for practical use. Strong enough that no known attacks exist. NIST approved. Every forensic tool supports it. Courts accept it without question. This is your baseline.

Example SHA-256 hash: 3a5f8c9b2e1d4f6a8b3c9e2f1a5d7b9c4e8f2a6d3b7e1c5a9f4d8b2e6a1c5f9b

SHA-512 (use this for long-term storage)

512-bit hash. 128-character string. Slower than SHA-256 but more resistant to future attacks. Use this for evidence you will store 10+ years. Criminal cases with long appeal periods. Cold cases that might not go to trial for years. The extra security is worth the extra compute time.

How hashing works (simple version)

You run a program (FTK Imager, sha256sum on Linux, certutil on Windows). Point it at a file or drive. The program reads every byte and runs it through a mathematical function. The function spits out a fixed-length string. That is your hash.

Key properties: Same input always produces same output. Different inputs (even by one bit) produce completely different outputs. You cannot reverse the hash to get the original file. Finding two different inputs with the same hash is practically impossible for SHA-256/SHA-512.

When to compute hashes

Right after you create the forensic image. Before you transfer the image between systems. Before you analyze it. Before trial. Basically any time someone could argue tampering occurred. Hash it and prove tampering did not happen.

Seizure

You image the suspect's drive using FTK Imager. The tool computes a hash of the original drive and the image file automatically. Write both hashes in your report. Now you have proof the image matches the original.

Transfer

You copy the image file from the seizure laptop to the analysis workstation. Hash the file on the source laptop before copying. Hash it again on the destination after copying. Hashes match? Copy was successful with no corruption.

Analysis

Before you open the image in EnCase or FTK, hash it. After analysis, hash it again. Matching hashes prove your analysis tools did not modify the image. Most forensic tools verify hashes automatically when loading images.

Pre-trial

Prosecutor needs the evidence for trial next week. Pull the image from archive storage. Hash it. Compare to the original hash from your seizure report. Match? Evidence is intact. Mismatch? Find out why before you get to court.

How to compute hashes

FTK Imager (Windows)

Free tool from Exterro. Add the evidence file as an image. Click "Verify Drive/Image." FTK computes MD5, SHA-1, and SHA-256 automatically. Results show in a pop-up. Copy the hashes to your report. Takes about an hour for a 1TB image on a modern system.

Command line (Windows)

Built-in tool certutil. Open PowerShell or Command Prompt. Run: certutil -hashfile C:\Evidence\image.dd SHA256. Replace the path with your file. Output shows the SHA-256 hash. Copy it. Free, simple, works on any Windows machine.

Command line (Linux/Mac)

Built-in tools sha256sum and sha512sum. Open terminal. Run: sha256sum /evidence/image.dd. Output shows hash and filename. Pipe to a file to save the hash: sha256sum /evidence/image.dd > image-hash.txt.

EnCase and other forensic suites

Commercial tools hash evidence automatically when you add it. EnCase computes MD5 and SHA-1 by default (legacy behavior). You can configure it to use SHA-256. Check your tool's settings and enable SHA-256 or SHA-512.

Verifying hashes

You have the original hash from seizure. You compute a new hash before trial. Now compare them.

Manual comparison

Copy the original hash: 3a5f8c9b2e1d4f6a8b3c9e2f1a5d7b9c4e8f2a6d3b7e1c5a9f4d8b2e6a1c5f9b. Copy the new hash. Put them side by side. Do they match exactly, character for character? Yes? Evidence is unchanged. No? Something is wrong.

Do not rely on visual comparison alone. Copy-paste both hashes into a text file. Use your text editor's find function. If it highlights both strings, they match. If it only highlights one, they differ.

Automated verification

Save the original hash in a text file: 3a5f8c9b2e1d... image.dd. Use verification tools. Linux: sha256sum -c hash.txt. Output says "OK" if the hash matches. Windows: compare manually or use PowerShell scripting.

What to do when hashes do not match

First, check you are hashing the right file with the right algorithm. Hash the wrong file? Easy mistake. Used MD5 instead of SHA-256? Also easy. Verify both before panicking.

Still mismatch? The file changed. Could be corruption (bad hard drive, transmission error). Could be modification (someone altered the evidence). Investigate immediately.

Corruption vs. tampering

Check file metadata. Last modified date. If it changed recently, someone or something touched it. Check access logs. Who opened the file? Check backups. Do you have an older copy with a matching hash?

Document everything. When you discovered the mismatch. What you checked. Who had access. Whether you can recover from backups. Notify your supervisor and the prosecutor. This might derail the case. Better they hear it from you than defense counsel.

Presenting hash values in court

Judges and juries do not understand cryptography. Explain hashes in simple terms.

The fingerprint analogy

"A hash is like a fingerprint for digital files. Just like every person has a unique fingerprint, every file has a unique hash. If the file changes, even by one letter, the hash changes completely. I computed this hash when we seized the evidence. I computed it again yesterday. They match. This proves the file is unchanged."

Demonstrate it live

Bring a laptop to court. Open a simple text file. Hash it. Show the hash value on the screen. Change one letter in the file. Hash it again. Show the completely different hash value. This visual demonstration makes the concept clear.

Address defense challenges

"Could the hash be wrong?" Explain the algorithm is mathematical and deterministic. Same input always produces same output. NIST approves it. Every forensic tool uses it. "Could you have copied the wrong hash?" Show your documentation. Original hash written in the seizure report. New hash computed in front of the court. They match.

Hash values for individual files

So far we talked about hashing entire drives. You can also hash individual files.

When to hash individual files

You extract a suspicious PDF from the drive image. Hash the PDF. Include the hash in your report. Defense claims you altered the PDF. You hash it again. Same hash. Proof you did not change it. This is common for documents, images, and videos used as evidence.

Hash lists for collections

You have 500 files to analyze. Create a hash list: filename and hash for each file. Save the list. After analysis, rehash all files and compare to the list. Any mismatches? Those files changed. Tools like md5deep and hashdeep automate this for large file sets.

Known file hash databases

Some databases contain hashes of known files. NIST has a database of known good files (operating system files). Also databases of known bad files (malware, child exploitation material). You hash files from the suspect drive and compare to these databases.

How this helps investigations

You find a suspicious file. Hash it. Check the hash against the malware database. Match found? You just identified the malware without reverse engineering it. Hash matches known contraband? You have proof what the file is without examining content.

Related resources

Related pages:Digital Evidence Guide | Documenting Digital Evidence | Social Media Evidence | Email Evidence Collection | Mobile Device Forensics | Cloud Evidence Preservation

See also:Digital Signatures & Authenticity | Audit Trails & Chain of Custody

Tools:Forensic Hash Calculator | All DFIR Tools