Key Hierarchy

How Literal uses personal, document, organization, and platform keys to protect encrypted documents and authorized access.

Literal’s keys are layered: root keys protect derived keys, and derived keys protect documents, search tokens, signatures, recovery material, and organization access paths. Access to one document key does not grant access to every document.

Key Families

Literal uses four main key families:

Personal keys — protect a document holder’s private keys, personal documents, search tokens, and recovery material.
Document keys — encrypt individual document content, metadata, OCR output, and verification artifacts.
Organization keys — support entity-scoped access, membership, metadata, and search.
Platform keys — protect enclave-only operations such as organization secret unwrapping and verification seals.

The diagram below shows the full key derivation graph — pan and zoom to explore.

Loading diagram…

Key hierarchy summary

Personal keys protect the document holder’s data and private key material. Organization keys support entity-scoped access and search. Platform keys are available only through attested enclave paths. Document keys sit at the center: each document has its own key, wrapped separately for every authorized access path.

Document Keys

Every document gets its own unique document encryption key (DEK), generated randomly at upload time. The DEK encrypts the document’s content, metadata, and verification seal.

Per-document DEKs mean that exposure of a single document key does not affect other documents. The DEK is then wrapped separately for every authorized access path — personal, organization, platform, or grant — so unwrap rights can be added or revoked per path without re-encrypting the document body.

Personal Keys

Personal Master Key

A document holder’s personal master key (User Master Key, UMK) is the root of the personal key hierarchy. It is derived from the user’s password using Argon2id, a memory-hard key derivation function intended to make offline guessing expensive. This derivation happens entirely on the client device — Literal never receives the password or the master key.

The personal master key is used to:

Wrap document keys for personal access.
Derive the personal search key.
Protect private signing and encryption keys.
Encrypt the recovery key backup.

The personal master key is never stored anywhere. It exists only in memory on the client device while the user is logged in. Without the password, recovery requires the recovery key.

Personal Search Key

The personal search key (Blind Index Key, BIK) is derived from the personal master key. It generates blind index tokens — one-way cryptographic values used for searching personal documents. Literal can match these tokens but cannot reverse them to learn what was searched or what the documents contain.

Signing Keys

Each account includes a signing key pair — a private key for creating digital signatures and a public verification key. The signing key proves that the document holder authorized actions such as sharing a document, claiming access to shared content, or joining an organization.

The private signing key is encrypted with the personal master key and stored alongside other credentials. The public verification key is stored in the account record so Literal can verify the signatures.

Literal uses a hybrid signing scheme that pairs an established classical method (Ed25519) with a post-quantum method (ML-DSA-65). Literal requires both signature layers to verify before accepting the proof, reducing dependence on a single signature family.

Recovery Material

The recovery key backup is encrypted with the personal master key. See Recovery below for how it is used when the password is lost.

Organization Keys

Organizations have a separate key hierarchy. Organization secrets are generated and unwrapped inside the secure enclave, while members receive wrapped access to the specific keys they need.

Organization Secret

The Entity Master Key (EMK) is the root of an organization’s key hierarchy. It is generated inside the secure enclave and wrapped by a hardware-protected platform key. Members do not receive the EMK directly. The EMK never leaves the enclave in plaintext and can only be unwrapped inside the enclave.

Entity Encryption Key

The entity encryption key (EEK) is derived from the EMK and used to encrypt the organization’s name and metadata. When a member joins, the enclave derives the EEK and wraps it with that member’s hybrid public key (ML-KEM + X25519). The wrapped EEK is stored in the membership record so only the member can unwrap it. Members use the EEK to decrypt organization metadata client-side, without enclave involvement.

Entity Data Key

For document access within the organization, the enclave uses a two-step internal derivation chain: Entity User Key (EUK) = HKDF(EMK, salt), then Entity Data Key (EDK) = HKDF(EUK). The salt differs by operation: during initial document processing the salt is the entity identifier, producing an entity-scoped EDK; during member access grants the salt is the member’s user identifier, producing a per-member EDK. Revoking membership invalidates the member-specific derivation path — even though the organization master secret still exists, a former member’s per-member EDK cannot be re-derived. The EDK is used to wrap document keys, giving the member access to organization documents. This derivation is ephemeral — EUK and EDK exist only inside the enclave during the operation and are never exported or stored.

Organization Search Key

The organization also has its own search key (entity BIK), derived from the EMK inside the enclave. This enables organization-wide search across shared documents — members can search the organization’s document pool without Literal learning what they’re looking for.

Platform Keys

Each organization has a dedicated platform key (PMK), provisioned inside the hardware-backed key management service at entity creation time. This key bridges the hardware security boundary and the application-level key hierarchy and is unique to the organization.

The platform key is used to:

Wrap and unwrap the organization secret. When an organization is created, the enclave provisions a new key in the key management service for that organization and wraps the EMK with it. The enclave unwraps the EMK later to derive member keys and perform organization-scoped operations.
Authorize enclave-produced artifacts, such as verification seals.

Before the enclave can use the platform key, it must prove its identity through attestation. The hardware verifies that the enclave code has not been modified and that the environment is genuine. Only after passing attestation does the key management service release access.

Platform keys also support enclave-produced verification artifacts, such as document seals. See Document Lifecycle for how seals are produced during processing.

The platform key never leaves the hardware. It cannot be exported, copied, or accessed outside the attested enclave environment.

Key Wrapping And Access Paths

Keys in Literal are protected through wrapping — encrypting one key with another. The same document key can be wrapped along multiple authorized access paths:

Document keys are wrapped separately for each authorized access path: personal access, organization access, platform processing, or grant-based sharing.
Private encryption and signing keys are wrapped with the document holder’s personal master key.
Organization secrets are wrapped with hardware-protected platform keys and unwrapped only after enclave attestation.
Organization metadata keys are wrapped per member so metadata can be decrypted client-side without enclave involvement.

This layered approach means access to one key does not grant access to all data. Each layer provides an independent barrier, and unwrap rights can be added or revoked per path without re-encrypting the underlying document.

Recovery

If a document holder loses access to the password, the recovery key provides a way back. The recovery key is generated during account setup and can decrypt a backup of the personal master key. From there, all other personal keys can be re-derived.

Keep the recovery key safe. It is the only way to regain access to data if the password is lost. Literal cannot reset the password or recover keys on behalf of the document holder.

See Account Recovery for the recovery workflow.

Hybrid Post-Quantum Protection

Literal uses hybrid cryptography for sensitive key transport and signing paths. Hybrid schemes combine established classical algorithms with post-quantum algorithms so the system does not depend on a single cryptographic family.

Key transport paths use X25519 with ML-KEM-1024. Signature paths use Ed25519 with ML-DSA-65. Literal accepts a key exchange or signature only when the required classical and post-quantum checks succeed.

This design reduces migration risk and helps protect data against record-now-decrypt-later attacks where encrypted traffic or wrapped key material is captured today and attacked later.

Zero-Knowledge Model — the trust-boundary foundation this key hierarchy enforces.
Document Lifecycle — how keys protect a document at each stage.
Encrypted Search — how the personal search key enables private search.
Grants & Sharing — how document keys are wrapped and transferred through grants.

Last updated on

On this page