Trust & verification
Verify a deletion receipt
Paste a CIPH4 Proof-of-Deletion Receipt below to verify its Ed25519 signature against our published JWKS. No login required — the whole point of a portable receipt is that anyone who holds the bytes should be able to independently confirm that CIPH4 issued it.
Accepts either the raw envelope {payload, signature, kid, alg} or the wrapper returned by GET /api/dead-drops/{id}/receipt (which nests the envelope alongside receiptId, dropId, and the decoded chainAnchor).
What a Proof-of-Deletion Receipt proves
Every drop destruction event on an Enterprise account (burned, revoked, expired, or cap-hit) produces a signed attestation that captures the drop id, the burn timestamp, the SHA-256 of the ciphertext that was destroyed, and an anchor into CIPH4's hash-chained audit log. The attestation is signed with an Ed25519 private key that lives only on the CIPH4 server.
A valid receipt tells you three things at once: (1) CIPH4 signed this exact payload, (2) the payload names a specific ciphertext by cryptographic hash, and (3) the referenced audit-chain link pins the moment to a tamper-evident log. Paste the receipt into the verifier above to confirm all three.
How verification works
- The verifier base64url-decodes the payload field and parses it as JSON.
- It re-canonicalizes the parsed payload with the same sorted-keys-v1 encoder CIPH4 used when signing, and confirms the re-encoded bytes match the original payload exactly. This catches any tampering that would preserve JSON validity but alter key order.
- It looks up the signing key by kid and verifies the Ed25519 signature over the original payload bytes. Historical keys from past rotations stay resolvable so older receipts remain verifiable after key rollover.
- A valid receipt returns the parsed payload; any of the above failing returns a specific reason so the caller can diagnose the failure class.