What a cryptographic hash actually proves
A hash answers exactly one question: is this file still the one it was before? It doesn't say who wrote it. It doesn't say when. It only says whether it changed — and it says so in a way nobody can fake. Knowing precisely what it promises, and what it doesn't, is the difference between using it well and treating it as a superstition.
What it is, in one line
A cryptographic hash is a function that takes any sequence of bytes — a 4 KB PDF, a 30 GB video — and returns a fixed-length sequence called a digest, or fingerprint. SHA-256 returns 256 bits: 64 hexadecimal characters. Always 64, whether you feed it a word or an entire disk.
The function is public: the algorithm is written down in a standard, anyone can implement it, there is no secret inside. That is precisely what makes it useful in court — the opposing party can redo the computation with their own software and get the same number, or not.
The four properties that matter
1. It is deterministic
The same input always produces the same digest, on any machine, with any software, today and twenty years from now. No randomness, no clock, no internal state carried over from the previous run.
2. It is one-way
Going from file to digest takes milliseconds. Going back does not happen. Not because it is «forbidden», but because the only known method is to try every possible file until one produces that digest — a job that does not finish before the heat death of the universe. This property is called preimage resistance.
3. It has the avalanche effect
Flip a single bit of the input and roughly half the bits of the digest change. Not «a few»: half. There is no notion of «nearby digests» for similar files — two files differing by one comma produce fingerprints with nothing in common.
4. It resists collisions
A collision is a pair of different files with the same digest. Collisions must exist mathematically — inputs are unbounded, 256-bit digests are «only» 2256 — but a good algorithm makes it infeasible to find one. This is the property MD5 and SHA-1 lost, and it deserves its own guide.
What a hash does not prove
The digest proves that this file is identical to that file. It does not prove who created it, does not prove when it existed, does not prove it told the truth.
This is the most common misconception, and it is expensive in an expert report. If you compute a document's digest today and write it on a sheet of paper, you have proven exactly one thing: that tomorrow's document, if it has the same digest, is bit-for-bit today's. But the sheet with the digest on it could have been written at any time.
Answering the other two questions takes different tools, which lean on the hash:
- When → an RFC 3161 timestamp: a third-party authority signs your digest together with the time. Note that the authority only ever sees the digest, never the content.
- Who → a digital signature: the signer encrypts the digest with a private key that never leaves the smart card.
Both sign the digest, not the file. That is the deep reason the hash sits at the bottom of the whole chain of custody: it is the hook everything else hangs from.
Why compute several at once
Probatio computes 18 algorithms and lets you select as many as you like in a single pass. This is not a flourish: it is a defence and an insurance policy.
The defence: no technique is known for building two files that collide simultaneously under MD5 and under SHA-256. Forging an exhibit verified with a battery of hashes would mean breaking two algorithms with different internal structures at the same time.
The insurance: the case file you produce today will be reopened in ten years, possibly by software that does not exist yet, possibly by an examiner who asks for whatever algorithm is standard then. Recording six of them costs what recording one costs.
«Costs what one costs» is literal. Probatio reads the file once, in 1 MiB blocks, and feeds every selected algorithm the same block before moving on. The bottleneck is the disk, not the CPU: computing MD5, SHA-1, SHA-256 and BLAKE3 together takes roughly as long as computing one.
In practice
- Compute the digest the moment the file comes into your hands, before opening, copying or renaming it. Some formats modify themselves on open.
- Always record SHA-256, and add MD5 or SHA-1 when you must interoperate with legacy catalogues or tools.
- Do not trust a digest written in a plain text file: without a timestamp, its date is whatever your clock says.
- Recompute before you hand over. If the digest doesn't match, something happened between acquisition and now — better that you find out first.
A hash is not a bureaucratic formality to append to a report. It is the reason a piece of digital evidence can be challenged by anyone, with any software, and survive the challenge.