Real cryptography, and an honest account of its limits.
Signata is built on genuine primitives (Ed25519 signatures, a SHA-256 hard binding, and the official C2PA library) wrapped in tenant isolation and a tamper-evident log. Just as important: we are explicit about what provenance can and cannot tell you, because overclaiming would defeat the point.
Defense that's verifiable, not just asserted.
Each pillar is something you can check rather than take on faith: standard signatures, recomputable hashes, a chained log, and isolation enforced per workspace.
Real cryptography
Signing identities use Ed25519 key pairs. Credentials are produced and verified through the official Content Authenticity Initiative (CAI) C2PA library. This is the real standard, not a lookalike format.
- Ed25519 signatures over the C2PA claim
- Built on the official CAI / c2pa library
- Standard C2PA output interoperates with any compliant reader
Hard binding (SHA-256)
Integrity rests on a hard binding: a SHA-256 hash of the asset bytes recorded inside the signed claim. At verification we recompute the hash and compare. If a single byte changed after signing, the binding no longer matches and the verdict is “altered after signing”.
- Hash computed over the actual bytes received
- Reported explicitly in the response, never inferred
- Mismatch ⇒ tampered; we never guess what the original was
Tamper-evident transparency log
Every credential issued is appended to a hash-chained log: each entry commits to the previous entry's hash. Altering or removing a past entry breaks the chain and changes the log root, so the record is tamper-evident and independently checkable.
- Append-only, each entry chains to the last
- A log root you can publish and reference
- Recover provenance by content hash when metadata is stripped
Tenant isolation & RBAC
Every workspace is isolated. Trust lists, signing identities, policies, and audit history belong to a tenant and never leak across boundaries. Role-based access control governs who can verify, sign, manage trust, and administer the workspace.
- Per-workspace data isolation
- Role-based access control on every privileged action
- Scoped API keys (verify:read, sign:write, …)
Key custody & rotation
Signing keys are held server-side, scoped to a workspace, and revocable. Compromise of one identity is contained to that identity, and revocation takes effect for new verifications immediately.
- Signing identities are revocable and scoped
- Per-identity key IDs surfaced in every receipt
- Revocation is honoured at verification time
Auditability
Privileged actions are recorded. Verifications and signatures carry a source and an event ID, signing identities track their key IDs, and the transparency log gives an independent, append-only account of what was issued.
- Event IDs on verify and sign operations
- Audit trail for privileged workspace actions
- Independent log record, separate from embedded metadata
What provenance can, and cannot, tell you.
Provenance is powerful precisely because it claims something narrow and verifiable. Conflating it with “truth” or “real vs fake” is the mistake this product exists to avoid. Here is the honest boundary.
What it can establish
- Where a piece of media came from: the signing identity that issued its credential.
- Whether it has changed since it was signed, via the SHA-256 hard binding.
- The recorded edit history and ingredients declared in the manifest.
- Any AI generation or editing the signer chose to disclose in the manifest.
What it cannot
- Whether what the content depicts is true. A valid signature proves origin and integrity, not honesty. A signer can sign a misleading image perfectly.
- That unsigned media is fake. “No provenance” is the normal state for most content and is never evidence of manipulation.
- That a file is AI-free. Absence of an AI disclosure is not proof a human made it. Signata surfaces disclosures, it does not detect AI.
- Who deserves your trust. Trust lists are a policy choice you make; recognising a known issuer is a convenience, never an automatic grant.
Metadata gets stripped
Re-encoding and re-uploading often removes the embedded manifest. That's why the transparency log and recovery-by-hash exist: a soft binding when the bytes no longer carry their credential.
Signers can lie within a valid signature
A cryptographically valid credential only attests to who signed and that bytes are unchanged. The claims inside can still be misleading. Trust the signer, not the signature alone.
Trust is a policy, not a fact
Moving a signer onto your trust list is a deliberate choice. It's the difference between “provenance present · untrusted signer” and “verified provenance”.
We keep this boundary documented in detail and link it from every surface. If anything in the product ever reads as “real vs fake”, treat it as a bug.
Responsible disclosure
Security and honesty are the same commitment here. If you find a vulnerability, a way to make a verdict overclaim, or a gap between what we say and what we do, we want to hear it. Email security@signata.dev and we will respond quickly.