Skip to main content

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.

Ed25519 + sorted-keys-v1No account requiredRate-limited: 30/min/IP

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).

Rate-limited: 30 verifications per minute per IP

What a Proof-of-Deletion Receipt proves

Every drop destruction event on an Enterprise account (BURNED, REVOKED, EXPIRED, VIEW_EXHAUSTED) 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 — the matching public key is published as a JWKS at /.well-known/ciph4-receipts/jwks.json.

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. Together, that's “prove-the-deletion-happened” in a form you can hand to an auditor who has never heard of CIPH4.

How verification works

  1. The verifier base64url-decodes the payload field and parses it as JSON.
  2. 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 — catching any tampering that would preserve JSON validity but alter key order.
  3. It looks up the kid in the JWKS to find the matching public key. Historical keys from past rotations stay in the JWKS so older receipts remain verifiable after a key rollover.
  4. It uses Node.js' built-in crypto.verify with the Ed25519 public key to verify the 64-byte signature over the original payload bytes.
  5. A valid receipt returns the parsed payload; any of the above failing returns a specific reason so the caller can diagnose the failure class.

Other ways to verify

This page uses the hosted verifier at POST /api/verify-receipt. For auditors who refuse to trust a CIPH4-hosted endpoint, the same verification can be performed offline using only Node.js built-in modules:

  • Fetch the JWKS from /.well-known/ciph4-receipts/jwks.json and cache it locally.
  • Run scripts/verify-deletion-receipt.mjs (ships with the product docs) against the receipt and cached JWKS — zero dependencies.
  • Or call the Python SDK (client.receipts.verify(envelope)) / PowerShell cmdlet (Test-Ciph4Receipt).

See the documentation for the full cryptographic specification.