Witness Camera

Trusted timestamp for video: how RFC 3161 time-stamping works

Why your phone's clock proves little, and what an independent signature adds.

A timestamp written by a phone proves little, because a device's clock can be changed. An RFC 3161 trusted timestamp is different: an independent authority signs a statement that a particular hash existed at a particular moment. This page explains how it works and how to check one. Written by the developer of Witness Camera, so read it with that in mind; where another approach is better, it says so.

Short answer. An RFC 3161 time-stamp authority receives a hash, signs it together with the current time and returns a token. Anyone can verify the token later with openssl ts -verify. Witness hashes each 15-second piece, writes a manifest of the hashes, hashes the manifest and sends only that hash to a public authority, which returns a signed .tsr token. The chain shows the footage existed in this form before the stated time and has not changed. The authority learns nothing about the footage. If the authority is unreachable when a session ends, there is no token, which is a gap in corroboration, not a sign of tampering.

The problem it solves

A manifest of hashes written on the phone is a self-attested log. The person with the phone could change the clock, or rewrite the log. A third party who has no stake in the matter and signs the hash at a moment they attest to closes that gap: the manifest cannot be older than the signature, and cannot have changed since.

How Witness uses it

  1. Each 15-second piece is hashed with SHA-256 on the phone.
  2. The hashes, UTC capture times and locations are written into a session manifest.
  3. When the session finishes, Witness takes a SHA-256 of the finished manifest and submits that hash to an RFC 3161 time-stamp authority. By default it uses FreeTSA, a long-standing public authority that needs no account.
  4. The authority returns a signed token, saved as timestamp_<session-id>.tsr beside the footage.

Only the hash is sent. The authority learns that some document existed at a moment in time. It never learns what the document said, where it was made or who made it.

How to verify a token

openssl ts -verify \
  -data manifest_<session-id>.json \
  -in timestamp_<session-id>.tsr \
  -CAfile <authority-ca-cert>.pem

openssl ts -reply -in timestamp_<session-id>.tsr -text

The first command should print Verification: OK. The manifest names the authority in its timestampAuthority field, and the CA certificate comes from that authority's website. A failure is most often a missing or wrong certificate, so read the token with the second command and check that its digest equals the SHA-256 of the manifest.

What it shows, and what it does not

Compare hash stamping and the manifest. The full steps are on how to verify footage.

Questions

What is an RFC 3161 timestamp?

A signed statement from an independent time-stamp authority that a particular hash existed at a particular moment. It is verifiable later with standard tools such as OpenSSL.

What does Witness send to the time-stamp authority?

Only a SHA-256 hash of the session manifest. The authority learns nothing about the footage, its location or who recorded it.

Which time-stamp authority does Witness use?

By default FreeTSA, a long-standing public authority that requires no account. The manifest records the authority used.

Why is there no .tsr file for my recording?

The authority was probably unreachable when the session ended. The hashes can still be checked against the manifest, but there is no independent proof of time.

Try it free

The free app includes this. Set it up and test it before you need it.

Get Witness Camera for Free Get it on Google Play

More Witness features explained

Written on 27 October 2026. Features and prices change. This is not legal advice.