Zero-Knowledge Model

Literal’s zero-knowledge model is about what the application layer can and cannot see. The general application and database layer handles only ciphertext, wrapped keys, and opaque tokens. Plaintext appears only on the document holder’s device or transiently inside the attested secure enclave during authorized processing.

This is a structural guarantee, not a policy decision. Encryption keys are created on the holder’s device. Cryptographic operations happen on that device or inside the enclave. The general server stores and routes data, but cannot interpret it.

Trust Zones

Literal’s architecture divides into four trust zones:

• Client device — the only zone where the user’s plaintext data and derived keys coexist.
• Application server — handles requests, but sees only ciphertext, wrapped keys, and opaque tokens.
• Database and storage — holds encrypted blobs, blind index tokens, and wrapped keys.
• Secure enclave — the only server-side zone where plaintext exists, transiently in memory, during authorized processing.

No path exists for plaintext to flow from the enclave to the database or general server. Only encrypted results exit the enclave boundary.

What The Application Server Can See

The application server is not completely blind. It needs certain pieces of information to function:

• Login bucket — authentication uses an OPRF, so the user’s email is never sent in plaintext. The server sees only a blind bucket index (login_bidx) shared by many accounts.
• Encrypted blobs — the server stores encrypted documents and metadata, but cannot decrypt them.
• Wrapped keys and opaque tokens — wrapped DEKs, blind index tokens, owner tokens, and capability signatures, none of which reveal the underlying identifiers.

What The Application Server Cannot See

• The content of any document.
• Document titles, filenames, or any metadata.
• What anyone is searching for.
• Which document a grant is for, or who the grant is intended for.
• The relationship between a grant and a specific person.
• Which organization a user belongs to — membership records use cryptographic tokens, not plaintext foreign keys.
• User encryption keys in any form.

These guarantees are enforced at the database schema level. Plaintext identifier columns have been physically removed from the relevant tables, not just obscured or deprecated. A database dump cannot reveal these associations because the columns no longer exist.

How The Boundary Is Enforced

Client-Side Encryption

Documents are encrypted on the holder’s device before upload. The server receives and stores only the encrypted result. Even full access to server storage would yield only ciphertext.

Secure Enclave Processing

Operations that require temporary access to decrypted content — text extraction, verification, and entity-scoped index generation — run inside a hardware-isolated secure enclave. The enclave has no general network access and communicates with the rest of the system through a narrow, controlled channel. The enclave boundary is designed so server operators cannot inspect decrypted document content during processing.

The enclave’s identity is cryptographically verified through attestation. Before the enclave can access any encryption keys, it must prove to the key management service that:

• It is running the exact, unmodified software that was audited and approved.
• It has not been tampered with since it was built.
• It is executing inside a genuine hardware-isolated environment.

Only after this proof is verified does the key management service release keys to the enclave. A tampered, replaced, or impersonated enclave cannot pass attestation and therefore cannot access keys.

During authorized processing, the enclave can produce encrypted verification artifacts such as seals; the application server stores those artifacts but does not receive document plaintext. See Document Lifecycle for how seals are produced and stored.

Cryptographic Tokens Instead Of Plaintext Relationships

Sensitive relationship identifiers — document ownership, grant associations, entity memberships — are replaced with one-way cryptographic tokens. The server can compare tokens for equality but cannot reverse-engineer the original identifier. This prevents the server from building a map of who owns what or who is sharing with whom. See Blind Routing for how this is applied to ownership and membership.

Schema-Level Minimization

Plaintext identifier columns that would otherwise carry sensitive associations have been removed from the relevant database tables. The columns no longer exist; nothing remains to dump, scrape, or join against.

Zero-Knowledge Boundary

Trade-Offs

Some operational data must be visible to the application server for the system to function. These are accepted trade-offs:

• Path parameters — server-assigned resource UUIDs appear in request paths. They carry no sensitive meaning; the server is trusted to route requests correctly.
• Timestamps — when uploads, shares, and searches occurred is recorded for operational purposes.
• Processing status — whether a document is uploading, processing, or ready. This reveals nothing about content.
• Size buckets — a coarse size bucket (not the exact byte count) is stored for storage management.
• Token equality — the server can observe that two requests produced the same blind index token within a scope.
• Result counts — how many results matched a search is observable, even though the server cannot read the results themselves.

Related Concepts

• Document Lifecycle — how a document moves through encryption, processing, and verification seals.
• Key Hierarchy — which keys exist, where they are generated, and the hybrid post-quantum protections applied.
• Encrypted Search — how blind indexes support search without exposing search terms.
• Entities & Memberships — how organization membership is encoded without exposing relationships.
• Grants & Sharing — consent-based, time-limited, revocable access.
• Blind Routing — how sensitive relationships are tokenized to reduce relationship mapping.

Last updated on