Back to wiki menu

Buyer primers

C2PA and a Truth Packet

Last updated: October 22, 2026 at 11:36

C2PA and a Truth Packet

Audience: anyone comparing a Content Credentials pin with a Verified Reality file.

We use the C2PA standard. A Truth Packet is built to go further, on a smartphone, at the moment of capture.

C2PA is an open technical standard, not an app and not an automatic authenticity badge. The commercial name is Content Credentials, often shown with a CR pin. It puts a signed label on a file: who claimed what, and whether the bound bytes still match that signature.

Where a Content Credential stops

Most Content Credentials are signed after the picture exists. Photoshop, a batch tool, or a platform account can take a finished file, attach claims, and sign them. That proves who certified the file, and that it has not changed since that signature. It does not prove the file was untouched before the signature, and it does not interrogate the camera that took it.

Some high-end cameras sign inside the body when the shutter fires. That is capture-time signing, and it lives in cameras built for it.

A public viewer checks the signature against a trust list. A certificate on that list usually comes from a paid authority, or from a product that signs with one it already holds. The specification is free. A pin that viewers treat as trusted is usually not.

A valid pin can show that this certificate signed these claims and that the bound bytes still match. It cannot show that the scene was honest, and it cannot turn the file into a Truth Packet.

What we add

Capture runs in the Verified Reality app, on a phone you already have. You do not join the coalition, buy a signing camera, or rent a certificate to make the record.

On supported phones, the app attests the hardware at the shutter: the sensor, the device, and live-camera signals from the pipeline while the picture is made. A photograph of a screen can still receive a perfectly valid Content Credential, because the new photo is a new file. Those live-camera signals are how a Truth Packet treats a replay as different evidence from a live capture. They are not on every phone, and they do not prove the scene was unstaged. The packet shows what that device attested.

The session is then sealed. Time, device, and location signals ride with the media, and the chain of custody runs through the capture, not only through a later edit history. If the sealed file changes, the seal no longer matches. When a verifier makes the capture, their attestation is part of the record. A signing certificate does not do that job.

On supported capture paths, the packet also carries a C2PA manifest, signed with Verified Reality's own certificate, so other tools can read a familiar label. We do not attach C2PA to every capture. A viewer that only trusts large-vendor certificates may show ours as outside that list. That is a fact about the list. The Truth Packet is what you re-check, in the free Desktop Auditor, on your own machine.

Side by side

  • Where it runs. Content Credentials: an editor, a signing service, or a high-end camera. A Truth Packet: the Verified Reality app on a phone you already own.

  • What a match shows. Content Credentials: this certificate signed these claims, and the bound bytes still match. A Truth Packet: the packet still matches the record sealed at capture.

  • Hardware. Content Credentials: only if that camera signed in the body. A Truth Packet: sensor, device, and live-camera signals on supported phones.

  • People. Content Credentials: a certificate. A Truth Packet: a verifier's attestation when a verifier made the capture.

  • What you need first. Content Credentials: usually a trust-listed certificate, or a product that holds one. A Truth Packet: the app. No coalition seat and no signing camera.

  • Long-term signature. Content Credentials: an X.509 certificate, using RSA or elliptic-curve math. A confirmed Truth Packet: the capture hash, plus a hash-based signature over that hash.

We provide mathematical proof of provenance for the sealed file. The judge, adjuster, or editor decides the context.

A second signature, on the hash

A Content Credentials pin is an X.509 signature. That certificate uses RSA or elliptic-curve math. A large quantum computer is expected to be able to forge signatures of that kind. The pin is still a useful label today. It is not the long-term check on the file's bytes.

The phone still seals the Truth Packet with SHA-256 at capture. This upgrade does not change that seal. After upload, Command Centre hashes the stored packet again. When that digest matches the phone's seal, Verified Reality signs the digest with SLH-DSA, a hash-based signature. Its security rests on the hash, not on the math a quantum computer is expected to break. The signature says Verified Reality attested this exact hash. It is an extra layer on packets confirmed from this upgrade forward. It does not replace the capture-time seal, and it does not replace the C2PA manifest on supported paths. It is an integrity check on these bytes, not a warranty that every future attack is impossible.

If the client opts in, the hash and that signature — not the media — can be written to a public ledger as a small receipt. The check is designed to run in the Desktop Auditor against a public key carried in the app, so it does not depend on our website. A match shows these bytes still agree with the signed hash. It does not show the depicted scene was honest, complete, or unstaged.

Where to go next