Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Trust Model

The reveal service is a key escrow. Understanding its trust properties is important.

Current: Encrypted-at-Rest Escrow (v1)

The service encrypts view keys at rest using AES-256-GCM with a service secret. During a purchase, the key is decrypted in memory (~1ms) and returned to the buyer.

Mitigations:
  • View keys are encrypted at rest (KV breach alone doesn't leak keys)
  • Key exists in plaintext memory only during the response (~1ms)
  • sha256(viewKey) commitment hash lets buyers verify they got the correct key
  • The service is separate from the storage gateway (different trust boundary)

Future: Hardware TEE (v2)

The service architecture is portable. The same code runs on Cloudflare Workers (v1) or inside a Phala Cloud TEE (v2).

When deployed on Phala:

  • Intel TDX hardware isolation — the operator cannot read view keys
  • Remote attestation — buyers cryptographically verify the TEE is genuine and running the expected code
  • Sealed storage — view keys are encrypted by the TEE, only decryptable inside the enclave

The GET /attestation endpoint returns the TDX attestation proof when running on Phala, or { tee: false } on CF Workers.

Future: Merkle-Gated Access (idea)

Merkle trees could gate who can purchase from the reveal service. The owner deposits a Merkle root of allowed addresses alongside the view key. Buyers submit a membership proof with their payment — the service verifies the proof before releasing the key.

This separates access control (who can buy) from confidentiality (whether the processor can read the secret). In v1, the operator still sees the key. In v2 (TEE), Merkle verification happens inside the enclave — giving both allowlist gating and operator blindness.

Rejected Approaches

We extensively researched alternatives before settling on this architecture:

Single-Proxy Umbral PRE

Umbral proxy re-encryption was tested and works in CF Workers (443KB WASM, ~5ms). However, with a single proxy, buyer + proxy collusion recovers the owner's master private key:

proxy reconstructs f(0) = a/d from kfrags
buyer computes d from their private key
therefore a = f(0) * d = owner's secret key

This is worse than simple escrow — it compromises all of the owner's encrypted content, not just the escrowed item. The Rust WASM implementation has never been audited.

Ferveo DKG (BLS12-381)

Same NuCypher team. Single-node is pointless (degenerates to regular encryption). Multi-node on our own infrastructure is security theater — we hold all key shares. Also GPL-3.0 (hard blocker) and unaudited.

TACo (Threshold Network)

Production-ready threshold decryption, but no Base chain conditions on mainnet (Ethereum + Polygon only). Incompatible with CF Workers (ethers v5 dependency). ~$4.4K/year. 3-12 second decrypt latency.

Lit Protocol

V1 (Naga) sunsetting April 1, 2026. V3 (Chipotle) in transition, not production-stable. Trust model shifting from threshold to single-TEE.

Cloudflare Workers TEE

Does not exist. CF Workers use V8 isolate memory isolation only. No SGX, no SEV, no remote attestation.