Encryption Guarantees

A public-facing overview of the encryption guarantees that protect your data. This document describes what the platform guarantees — and precisely where each guarantee applies.

Client-Side Encryption

Every document you upload is encrypted on your device before it leaves your machine. The server receives only ciphertext — encrypted data that it cannot read, interpret, or reverse.

This guarantee is structural, not policy-based:

• Your encryption keys are generated on your device and never transmitted to the server in unencrypted form
• Each document receives its own unique encryption key, generated fresh at upload time. Compromising one document's key does not affect any other document
• Document metadata is encrypted separately — titles, filenames, and other attributes are protected with the same rigor as the document content itself
• The server stores encrypted blobs, wrapped keys, blind tokens, and operational metadata — it performs storage and routing but cannot interpret sensitive content

The only exception to client-side-only plaintext is enclave processing: operations that require temporary access to document content (OCR, verification, search index generation) happen inside a hardware-isolated secure enclave. Plaintext exists there transiently, in isolated memory, and is re-encrypted before any result leaves the enclave boundary.

At-Rest Encryption

The platform enforces encryption at rest for sensitive payloads:

• Document content and metadata are stored as encrypted blobs. The server has no mechanism to decrypt them
• Search indexes are built from one-way blind tokens, not plaintext. The server can match tokens for equality but cannot reverse them to learn what they represent
• Audit records are encrypted inside the secure enclave before being written to storage. Only an attested enclave instance can decrypt them
• Sensitive stored relationships use blind tokens in the areas where tokenization has been applied — document ownership, grant-document associations, entity member document keys

The database also stores operational metadata: statuses, timestamps, size categories, processing state, and some resource identifiers. The at-rest guarantee covers sensitive content and key material, not all observable metadata.

Post-Quantum Design

All key transport for entity membership, document delivery, and grant access uses a hybrid classical + post-quantum scheme: ML-KEM-1024 (post-quantum) combined with X25519 (classical). Both layers must be broken to compromise a wrapped key.

This hybrid design provides three concrete guarantees for those key paths:

• If quantum computers arrive sooner than expected, the post-quantum layer protects your data
• If the post-quantum scheme has a flaw, the classical layer still provides full security
• Keys wrapped today remain safe in the future — "harvest now, decrypt later" attacks are neutralized for these paths

The platform DEK wrap (wrapped_dek_pmk) currently uses P-256 ECDH. Migration to hybrid KEM for that field is tracked as engineering work.

Digital Signatures

The platform uses a hybrid ML-DSA-65 + Ed25519 signature scheme for delivery authorization and capability tokens. Both signature components must verify independently — an attacker would need to break both the classical and post-quantum scheme to forge a valid signature.

Platform verification seals on documents use ECDSA_SHA_256 via a hardware-backed platform signing key. The algorithm field in verification responses reflects the algorithm in use. Migration to hybrid signatures for verification seals is tracked as engineering work (gap #24).

What The Server Cannot See

The platform's encryption guarantees mean the server is structurally unable to access:

• The content of any document
• Document titles, filenames, or sensitive metadata
• What you are searching for
• Your encryption keys in any form
• The contents of audit log entries

The server can see a limited set of operational data required to function:

• A login bucket index (a 13-bit integer derived from your email via an OPRF — the server cannot reverse this to learn your email address; no plaintext email is stored)
• Timestamps of actions
• Coarse document size categories
• Document processing status
• Some resource identifiers in certain tables and route paths

Sensitive stored relationships use blind tokens where tokenization has been applied. Some tables retain plaintext identifiers for operational reasons — see Zero-Knowledge Boundary for the precise scope.

Hardware-Isolated Processing

Certain operations — such as generating search indexes or producing verification seals — require temporary access to decrypted data. These operations happen exclusively inside a hardware-isolated secure enclave:

• The enclave has no direct network access — all external communication is proxied through a narrow, encrypted channel to the parent host
• Server operators cannot inspect, modify, or observe what happens inside the enclave
• Before the enclave can access any encryption keys, it must prove its identity through hardware attestation — a cryptographic verification that the enclave is running the exact, unmodified software that was audited and approved, inside a genuine hardware-isolated environment
• A tampered, replaced, or impersonated enclave cannot pass attestation and therefore cannot access any keys

After processing, the enclave re-encrypts all outputs before returning them. Plaintext exists only momentarily, inside isolated memory, and is never written to persistent storage.

Tamper-Evident Processing

Documents that complete enclave processing receive a verification seal — a cryptographic proof that the document was processed by a genuine, attested enclave and has not been altered since. Both the encrypted seal and a public commitment hash are stored alongside the document. The seal fields are populated when the processing pipeline completes verification; they remain null for documents that do not reach that path.

Every authentication and administrative event on the platform is recorded in a tamper-evident audit trail. Audit entries are encrypted inside the secure enclave and chained together cryptographically — tampering with or deleting a single record would break the chain and be immediately detectable.

Consent-Based Sharing

Document sharing is consent-based, time-limited, and zero-knowledge:

• You decide who gets access, for how long, and you can revoke it at any time
• Sharing is implemented through cryptographic grants — encrypted packages that only the intended recipient can open
• The server stores grants but cannot read them or identify recipients — the association between a grant and a specific document is stored as a blind token, not a plaintext identifier
• All grants have a mandatory time limit and are automatically revoked when they expire
• Revocation is immediate and atomic — access is terminated before any cleanup begins

For a deeper look at the sharing lifecycle, see the Grants & Sharing documentation.