§ Independent verification

You don't have to trust LOCUS.
You can verify everything yourself.

Every acquisition is a self-contained, third-party-verifiable package — by the opposing party too, even offline, with open standard tools. This page explains, step by step, how to confirm (or challenge) the authenticity of a LOCUS bundle.

LOCUS — bundle verification: BagIt, triple hashes, RFC 3161 timestamp and Ed25519 signature

The principle

Trust-free verification

The strength of digital evidence cannot rest on the word of whoever produced it. That is why LOCUS does not ask you to believe it: it uses only open, public standards — BagIt (RFC 8493), SHA-256/512 (FIPS 180-4), Ed25519 signatures (RFC 8032), RFC 3161 timestamping, CASE/UCO sidecar — that anyone can recompute with third-party tools, with no LOCUS software at all.

Reproducible

The same checks yield the same result on any computer, today and years from now.

Vendor-independent

The timestamp is issued by a third-party Authority (Sectigo / InfoCert), not by LOCUS.

Tamper-evident

Any change, even a single byte, breaks the seals and is detected on verification.

What you receive

Anatomy of the bundle

The bundle is a plain .zip following BagIt RFC 8493. Inside, every file has a role; two “seals” (manifest and tag-manifest) guarantee integrity and a third-party timestamp fixes the date.

LOCUS-<uuid>.zip BagIt RFC 8493 package SEALS (root) manifest-sha256.txt → hash of every file in data/ tagmanifest-sha256.txt → hash of seal + metadata files tagmanifest-sha256.txt.tsr → RFC 3161 timestamp (3rd-party TSA) verify.sh · verify.bat · tsa-ca.pem data/ (signed payload) manifest.json → Ed25519-signed (device-bound) media.jpg / .mp4 / .wav → the actual evidence content tsa.tsr → RFC 3161 timestamp on the media original.jpg · histogram.png report.pdf · interactive.html → report + in-browser verification camera.json · device.json metadata/ evidence.case.jsonld — CASE/UCO Seal chain: media + files → manifest-sha256 → Ed25519 signature on manifest → tagmanifest → RFC 3161 timestamp. Touching a single byte breaks the next link and makes tampering evident.
Figure 1 — Structure of a LOCUS bundle and seal chain.

Five independent paths

How to validate, from simplest to most rigorous

Three of these tools travel inside the bundle itself: verification depends neither on our website nor on any external software.

online

1 Public verification page

Open /verify/<code> on this site and enter the 6-character code (or the UUID). It recomputes hashes, RFC 3161 timestamps and signature in real time. No tools, accessible to anyone — including a judge from the browser.

in bundle · offline

2 interactive.html

Inside data/. Double-click it in any browser, with no connection: it recomputes the file hashes locally (the browser's Web Crypto, no upload) and compares them with those signed in the manifest. It shows the outcome, details and perceptual fingerprints for each item.

in bundle · offline

3 verify.sh · verify.bat

Self-verification scripts in the bundle. On macOS/Linux ./verify.sh, on Windows double-click verify.bat. They check payload integrity, completeness (undeclared files), seal integrity and — with openssl — the RFC 3161 timestamps. They use system tools (shasum/sha256sum, certutil, openssl), not LOCUS code.

desktop app · offline

4 Locus Validator

Standalone desktop app (macOS · Windows · Linux), no login, no telemetry. Drop the .zip and get a traffic-light report with all checks + a validation PDF. Built for court experts who want a repeatable, documented outcome.

Download the Validator
zero LOCUS software

5 Manual commands (the ultimate proof)

For those who will not trust any tool — ours or anyone's — the seals can be verified by hand with standard utilities. It is the method that removes any doubt about the vendor: see the section below.

What gets verified

The checks, and what each one proves

  • Payload integrityEvery file in data/ matches the SHA-256 declared in the manifest. A change to the media → mismatch.
  • BagIt completenessNo “infiltrated” file: every file present in data/ is listed in the manifest (RFC 8493).
  • Tag integrityThe tagmanifest seals the service files and the CASE/UCO sidecar: it covers everything outside data/.
  • Media hash tripleMD5 + SHA-256 + SHA-512 of the media match those signed in the manifest.
  • RFC 3161 timestamp on mediaA third-party TSA (Sectigo / InfoCert) attests the media existed at that date. Verifiable with its public CA.
  • RFC 3161 timestamp on tagmanifestCloses the chain of custody: fixes the entire sealed package in time, not just the media.
  • Ed25519 signatureThe manifest is signed with a device-bound key (TOFU): it binds content, device and operator.
  • Perceptual hashes + histogramSigned aHash/dHash/pHash and histogram: they represent the media without revealing it and are recomputed from the bundle.
  • CASE/UCO sidecarForensic metadata in CASE 1.3 / UCO standard, consistent with the manifest and inside the seal.
  • Temporal coherenceCapture precedes sealing; NTP time precedes the RFC 3161 timestamp. Inconsistencies → flagged.

By hand, no LOCUS software

Manual step-by-step verification

Extract the .zip and enter the folder. You only need shasum/sha256sum and openssl (on Windows certutil), already present in the operating systems.

  1. Payload integrity
    # recompute and compare the data/ file hashes
    shasum -a 256 -c manifest-sha256.txt # Linux: sha256sum -c manifest-sha256.txt → all OK
  2. Seal (tag) integrity
    shasum -a 256 -c tagmanifest-sha256.txt
  3. RFC 3161 timestamp on the media
    openssl ts -verify -data data/media.jpg \
      -in data/tsa.tsr -CAfile tsa-ca.pem # → Verification: OK
  4. Timestamp on the tagmanifest
    openssl ts -verify -data tagmanifest-sha256.txt \
      -in tagmanifest-sha256.txt.tsr -CAfile tsa-ca.pem
  5. Ed25519 signature and perceptual hashes

    The signed manifest is in data/manifest.json (signature field + device public key). The simplest way to verify it is to open interactive.html or use the Locus Validator, which recompute the signature and perceptual fingerprints and confirm the match.

Note: the media filename (media.jpg/.mp4/.wav) is listed in manifest-sha256.txt. The same commands are wrapped in verify.sh/verify.bat.

Why it holds

The trust chain

Media photo/video/audio SHA-256/512 digital fingerprint Ed25519 device signature RFC 3161 3rd-party TSA · trusted date Anyone recomputes & confirms Every link is verifiable with public standards: trust never concentrates on LOCUS.
Figure 2 — Trust is distributed across open standards and an independent third party.

For the opposing side

If you intend to challenge LOCUS

Good: that is exactly what it is designed for. Here are the most common objections and how anyone can settle them independently.

«The date could have been forged.»

The timestamp is issued by a third-party TSA (Sectigo, or eIDAS-qualified InfoCert) per RFC 3161 and is verified against the Authority's public CA — not material we provide. The eIDAS-qualified timestamp has legal value across the EU (Reg. 910/2014).

«The LOCUS software might lie about the result.»

You can verify without any LOCUS software: shasum/openssl are standard third-party utilities. If their outputs agree, authenticity does not rest on our word.

«The photo could have been retouched.»

Any change to the media breaks the hash triple, the Ed25519 signature and the RFC 3161 timestamp: verification detects it and flags the bundle as altered. There is no “silent” edit.

«The content is not on your servers: how to trust it?»

It is a confidentiality choice (privacy by design): the authority of the evidence is the sealed bundle held by the user, not a copy on a server. The server still keeps the signed histogram and perceptual hashes, which bind the media; full verification is done on the bundle.

«The provenance is not standard C2PA.»

True, and we state it openly: it is a proprietary container “inspired by C2PA/JUMBF”, not readable with c2patool. It is no overclaim: the evidentiary value rests on hashes, signature and timestamp, not on provenance.

«It is a “computational” JPEG, not raw data.»

The capture pipeline is declared and signed in the manifest (capture object): source, capture API, absence of AI editing. Fidelity disclosure is part of the evidence, not hidden.

Try the public verification ↗ Download the Locus Validator Validation manual