Video evidence that holds: integrity, timestamp, audit

Engineering By Juliano Baladão · 4 September 2026 · 6 min read

What does a cryptographic hash actually prove?

A hash turns a file of any size into a value of fixed size. In SHA-256 that value is 256 bits long, usually written as 64 hexadecimal characters.

FIPS 180-4, published by NIST in August 2015, declares the algorithms secure because it is computationally infeasible to find a message that corresponds to a given digest and to find two different messages that produce the same digest. It is the second property that supports evidentiary use: nobody can manufacture a second file, with different content, that shows the same code.

In forensic practice that becomes a narrow, strong claim: this file is bit for bit the same as the one that existed when the code was computed. Cropping, brightening, recompressing or saving again in another program breaks the match.

What the hash does not prove

The most expensive confusion in any argument about digital evidence is treating integrity as authenticity. They are different things, and the hash settles only the first.

The last row deserves a note. A hash is not a signature: a hash is public and anyone can compute it; a signature involves a private key and binds the result to a holder. A system can have perfect integrity and no demonstrable authorship — acceptable, as long as it is stated clearly.

Why the visual stamp has to sit inside the pixels the hash covers

Every item of video evidence carries information about itself: date, time, camera identification, place, and in our case the speed measured. What decides whether that information is worth anything is where it lives.

If it lives outside what was measured — editable metadata, the file name, a spreadsheet alongside — the date can be changed without breaking the hash: the code still matches and the claim about time still has nothing holding it up. If it is drawn inside the pixels themselves, altering it changes the image, changes the hash, and the conflict shows up immediately.

This is a general principle, not an implementation trick: what the hash does not cover, the hash does not protect. It holds for the date stamp, the camera identification and any annotation someone intends to use as a statement of fact.

Who guarantees the time?

Nobody, if the only source is the clock of whoever produced the file. The clock in a video recorder runs slow, gets reconfigured, loses its battery and returns to a factory date. And it is controlled by one of the parties to the argument.

The internet's standard answer is the time-stamping authority of RFC 3161: a trusted third party that provides proof of existence of a piece of data at an instant in time, required to use a trustworthy time source. Two details in the same standard say where that stops: the authority stamps only a hash representation of the data, never the data itself; and it is required not to examine what it stamps, beyond checking the length of the value.

In other words: the outside witness attests to the instant and declares complete disinterest in the content. That is a virtue, because it preserves confidentiality, and it is a limit, because no timestamp says the image is true. It says the image is old.

At what moment should the hash be computed?

As close to the origin as possible. Every interval between the instant the image was formed and the instant the digest was computed is a period the hash does not cover — and it is in that period that a file swap would go unnoticed.

The architectural consequence is direct: computing the digest on the central server, after the file has crossed the network, the recorder and the management system, protects far less than computing it at the edge. The algorithm is the same, but the claim shrinks — from “nothing changed since the record was made” to “nothing changed since it reached the server”.

That is why integrity does not replace the chain of custody. It documents one stretch of the file's life with mathematical precision; who answers for each earlier stretch remains a matter of organization, contract and access logging.

Independent verification is what gives you strength in a dispute

An evidence system has two possible architectures. In the first, the vendor keeps the truth and issues reports: whoever doubts either believes the vendor or hires an expert. In the second, the vendor publishes enough for anyone to redo the check with ordinary tools, and the answer does not depend on anybody acting in good faith.

The difference shows up the moment the system is attacked. At an HOA meeting or in a hearing, the question is not whether the vendor is serious — it is whether the other side can check on their own. Independent verification trades trust for arithmetic, and arithmetic takes no side.

From which follow three design requirements, all of them verifiable by the buyer.

1. A public, standardized algorithm.
2. A reference value published with the evidence or through a separate channel.
3. A check that works with tools already present on anybody's computer.

How do you check the integrity of a file yourself?

If you have received a file and its corresponding SHA-256 value, the check takes less than a minute and requires installing nothing.

1. Download the original file, without opening and saving it again. Forwarding it through an app that recompresses images already invalidates the check — that is not a defect in the method, it is the method working.
2. Compute the digest. On macOS or Linux: shasum -a 256 file.jpg. On Windows, at the Command Prompt: certutil -hashfile file.jpg SHA256.
3. Compare it with the stated value. There are 64 characters: compare all of them, not just the start and the end.
4. Write down what you did. The date of the check, the command used and the value obtained. That is what makes your check citable by someone else.

For OpenRadar evidence there is a short route: the page verify an item of evidence recomputes the signature of the photo inside your own browser, without sending the image to any server. And the warning holds: a positive result says the file is unaltered, not that the record is right. Integrity is the floor of the argument, not the ceiling — which is why it has to come with a stated method, as in measuring speed from video.