Oversight Protocol

What it is

Oversight takes a document and a recipient's public key and produces a .sealed file. The seal binds three things together: the content is encrypted to that recipient and to no one else; the recipient's copy is watermarked so a leaked copy can be traced back to them; and the whole event is written to a tamper-evident log that an outside auditor can check. It is a protocol with two reference implementations (Python and Rust) that produce bit-identical output, not a hosted product you have to trust.

It exists because the usual answer to "who leaked this?" is a shrug. Encryption controls who can open a file; it says nothing once a legitimate recipient has opened it and passed it on. Oversight is built for that second problem: attribution and evidence after access, without running any code on the reader's machine.

How a seal works

Each recipient's copy is watermarked with a mark derived from their public key, then encrypted with X25519 (or hybrid ML-KEM-768 + X25519) and XChaCha20-Poly1305 and signed with the issuer's Ed25519 key. The content hash goes to an RFC 3161 timestamp authority and is appended to an RFC 6962 Merkle log. The final container bundles the ciphertext, signature, timestamp token, inclusion proof, and policy. Opening it verifies the proof, checks the timestamp and policy, decrypts, and keeps the watermark metadata for recovery if the content surfaces later.

Cryptographic suite

No custom cryptography. Every primitive is NIST-standardized and comes from RustCrypto or liboqs. In hybrid mode the key-encryption key binds both shared secrets, so an attacker has to break X25519 and ML-KEM-768 to recover content.

Watermarking

Three independent layers, so removing one does not remove attribution:

• L1 - zero-width characters. Invisible Unicode marks that survive copy-paste.
• L2 - whitespace patterns. Per-line trailing-whitespace encoding.
• L3 - semantic substitution. Synonym swaps from a fixed 151-class vocabulary that survive manual retyping. L3 changes wording, so it is off by default for legal, regulatory, source-code, and other wording-sensitive documents, and the manifest records a canonical content hash so a dispute can reach ground truth.

Adapters cover plaintext, images (Y-channel LSB), PDF, and DOCX.

Threat model - what it does and doesn't do

Being precise about the boundary matters more than a feature list.

• It does: bind a copy to a named recipient; make tampering with a seal or silent deletion from the log detectable; keep content confidential against a future quantum adversary in hybrid mode; and give passive, network-level signal when a sealed file is opened.
• It does not: stop a recipient from photographing their screen or re-typing the text from scratch - watermarking is deterrence and attribution, not DRM. Beacons are passive DNS, HTTP, or OCSP calls that a careful reader can block; nothing executes on their machine. L3 is the only layer that survives full retyping, and it is opt-in for the reasons above.

The full write-up, including the assumptions and the known gaps, is the published threat model.

Get started

git clone https://github.com/oversight-protocol/oversight
cd oversight && pip install .

oversight keygen # generate your keypair
oversight seal report.pdf --to alice.pub # seal to a recipient
oversight open report.sealed # verify + decrypt

Prefer not to install anything? The browser-based Sealed File Inspector parses a .sealed file, verifies the issuer's signature with WebCrypto, and shows the manifest, watermarks, and policy entirely on your device. Full commands are in the CLI reference.

Spec & conformance

The registry interface is pinned as registry v1: the canonicalization algorithm, the error envelope, the endpoint list, and the evidence-bundle fields are all fixed. A conformance harness runs against either the reference registry in-process or a live operator URL, so an independent deployment can claim v1 compatibility with evidence rather than a promise. The attribution registry and beacon infrastructure run at registry.oversightprotocol.dev.

Reference Python + Rust, bit-identical by a shared conformance suite · License Apache 2.0 · Current release and full changelog: GitHub releases.

Status

Where the project is, newest first. Full release history is on GitHub releases.

• In progress
  v1.0. Registry ported to Rust (Axum + SQLx); every registry-v1 endpoint under #![forbid(unsafe_code)] with burn-in validation. Pending a wire-format stability declaration.
• Shipped
  Mobile verifier. A Flutter UI over the same Rust crates via flutter_rust_bridge, verification bit-identical to desktop; the iOS build runs on GitHub-hosted macOS runners. On TestFlight.
• Shipped
  Browser inspector. Drop a .sealed file to verify the Ed25519 signature with WebCrypto and read the manifest, watermarks, and policy on-device. Classic, hybrid, and hardware-P256 all decrypt. Open it.
• Shipped
  v0.4.10–v0.4.11. Hardware-key track: a KeyProvider trait (YubiKey / Nitrokey / OnlyKey via PIV) and the OSGT-HW-P256-v1 suite across Python, Rust, and the inspector.
• Shipped
  Outlook add-in. A task pane that reuses the inspector's parse / verify / decrypt; classic and hybrid both decrypt in-pane.
• Shipped
  v0.4.7. Registry federation pinned as registry-v1 with a conformance harness.
• Shipped
  v0.4.6. SIEM export for Splunk HEC, Elastic ECS, and Microsoft Sentinel.
• Shipped
  v0.4.5. L3 semantic-watermark safety (off by default for sensitive documents), a GUI starter, and the published threat model.
• Shipped
  v0.4.4. Nine security findings resolved by failing closed.
• Shipped
  v0.5–v0.6. Sigstore Rekor v2 transparency via DSSE; format adapters (text, PDF, DOCX, image) ported to Rust.
• Live
  registry.oversightprotocol.dev. Attribution registry with HTTP, OCSP, DNS, and license beacons.