Forensic verification report

The audit-grade extension of Verify

Run a structured 10-step forensic verification on a file, a certificate PDF, a SHA-256 hash, or an attestation id. The pipeline produces a deterministic, byte-identical Verification Report (PDF + JSON) suitable for legal, audit, and forensic use.

Your input never leaves the browser. Files are hashed locally with WebCrypto; only the resulting SHA-256 (32 bytes) transits via the proxy to the public ExistBefore registry.

Provide the input to verify

Verification result

Forensic checklist

Comparison result

How Verify Pro differs from Verify

The public Verify page is built for one job: tell the user, in seconds, whether a file or a certificate is recognised by the ExistBefore registry. Verify Pro is built for a different audience — legal, audit, and forensic professionals who need a structured, reproducible verification record.

• Same cryptography, more transparency. Verify Pro runs the exact same offline ECDSA verification and registry cross-checks as the basic Verify flow, but exposes every intermediate step (10 entries, codes VR01–VR10) with a per-step status, evidence, and reason code.
• Deterministic Verification Report. The report is byte-identical across runs, browsers, and time zones for the same input + the same registry response. The PDF and JSON include a self-hash so any later edit to the file is detectable.
• Frozen catalog. The 10-step catalog is versioned (existbefore-verifyreport-v1) and pinned by an inline-stability test. Adding, renaming, or reordering a step requires a version bump — the report stays mappable years later.
• Privacy invariant preserved. Files never leave the browser. Only the SHA-256 transits via the proxy to the public registry, exactly as in the basic Verify flow.

What this report guarantees — and what it does not

Forensic verification is a chain of statements made under specific conditions. Verify Pro is explicit about which statements it can make and which it cannot.

What an Authentic verdict establishes

• The cryptographic signature embedded in the certificate validates against the public key the certificate also embeds.
• The fingerprint of the embedded key matches the fingerprint declared inside the certificate (no key swap).
• The public ExistBefore registry recognises the hash and returns the same attestation id and signing-key fingerprint embedded in the certificate.
• No tamper indicator was raised by any step of the pipeline.

What no Verify Pro report ever claims

• It does not claim the input was authored, owned, or controlled by any specific person or organisation. Cryptographic integrity is not attribution.
• It does not claim the input is unique, original, or first-of-its-kind. SHA-256 collisions are infeasible, but two parties may legitimately attest the same content.
• It does not grant any intellectual-property right. ExistBefore is a proof-of-existence layer, not a registry of rights.

How the 10-step pipeline runs

1. VR01 — Input parsed. The input is recognised and routed to the correct path (file, certificate PDF, hash, or attestation id).
2. VR02 — Hash computed. For files, the SHA-256 is computed locally with WebCrypto. For pre-supplied hashes and attestation ids, this step is not applicable.
3. VR03 — Hash matches embedded. For certificate PDF input, the lookup hash is the same value embedded in the certificate. Internal divergence would already be a tamper indicator.
4. VR04 — Embedded fingerprint matches embedded key. The SHA-256 of the embedded SPKI must equal the fingerprint declared in the certificate, otherwise the embedded key has been swapped.
5. VR05 — Embedded signature is valid. The embedded ECDSA signature is verified against the embedded public key over the canonical signed payload.
6. VR06 — Registry recognises the hash. The proxy forwards the hash to the public ExistBefore registry; an unrecognised hash means no attestation exists.
7. VR07 — Registry attestation id matches embedded id. The certificate must not have been re-pointed at a different attestation.
8. VR08 — Registry signing-key fingerprint matches embedded fingerprint. The same key must have signed the certificate and registered the attestation.
9. VR09 — Current registry level vs generation level. The attestation may have been upgraded (T0 → T1 → T2) since the certificate was issued; this step reports the current level.
10. VR10 — Embedded forensic findings. The producer-side forensic-findings snapshot embedded in the certificate is rendered verbatim and never re-computed at verification time.