Key Hierarchy

Literal uses a hierarchical key system where compromising one key doesn't compromise all data.

How Keys Are Organized

Your keys form a tree of safe-deposit boxes: your personal master key (UMK), derived from your password, is the master key to the top box. Inside are specialized sub-keys — each for documents, search, signing, and recovery — wrapped by the key above them. You can only access a document key if you can unlock its parent.

Your Password
└── Personal Master Key (User Master Key, UMK)
    ├── Document Keys (per-document, wrapped with UMK)
    ├── Personal Search Key (blind index token generation)
    ├── Signing Keys (private key wrapped with UMK)
    └── Recovery Key Backup (wrapped with UMK)

Per-Entity Platform Key (hardware-protected, one per organization)
└── Organization Secret (Entity Master Key, EMK)
    ├── Entity Encryption Key (EEK, name/metadata; wrapped per-member for client access)
    ├── Entity Search Key (BIK, entity-scoped blind indexes)
    └── [Enclave-internal] Entity User Key (EUK) → Entity Data Key (EDK)
        (ephemeral per-member derivation chain; wraps document keys for entity access)

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

Personal Keys

Personal Master Key

Your personal master key (User Master Key, UMK) is the root of your personal key hierarchy. It is derived from your password using Argon2id — a memory-hard key derivation function; deriving the UMK from a password takes ~1 second and 64 MB of RAM by design, making offline brute-force attacks cost-prohibitive. This derivation happens entirely on your device — the server never sees your password or your master key.

Your master key is used to:

• Wrap (encrypt) the keys for each of your documents.
• Derive your personal search key.
• Protect your private signing and encryption keys.
• Encrypt your recovery key backup.

Document Keys

Every document gets its own unique document encryption key (DEK), generated randomly at upload time. This key encrypts the document's content, metadata, and verification seal. The DEK is then wrapped with your personal master key, so only you can unwrap it.

This per-document design means that even if one document key were somehow exposed, no other documents would be affected.

Search Key

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

Signing Keys

Your account includes a signing key pair — a private key for creating digital signatures and a public verification key. When you share a document, claim access to shared content, or join an organization, your signing key proves that you authorized the action.

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

Literal uses a hybrid signing scheme that pairs an established classical method (Ed25519) with a post-quantum method (ML-DSA-65). Both must agree for a signature to be valid, so your identity proofs are protected against both current and future threats.

Organization Keys

When you join an organization, a separate set of keys comes into play.

Organization Secret

Each organization has its own master secret (Entity Master Key, EMK), generated inside the secure enclave when the organization is created. Think of it as the master key to a corporate safe-deposit box — the organization owns it, but individual members never see it. This secret never leaves the enclave in plaintext — it is wrapped with a dedicated hardware-protected platform key 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 — 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, user_id), then Entity Data Key (EDK) = HKDF(EUK). Think of the EDK as your personal locker inside the corporate safe: revoking your membership immediately locks the locker, even though the master safe still exists. 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 the server learning what they're looking for.

Platform Keys

Each organization has its own dedicated platform key (PMK), provisioned inside the hardware-backed key management service at entity creation time. This key acts as the bridge between the hardware security boundary and the application-level key hierarchy — it is unique to the organization and never shared across organizations.

The platform key is used to:

• Wrap and unwrap the organization secret — when an organization is created, the enclave provisions a new KMS key for that organization and wraps the EMK with it. Later, the enclave unwraps it to derive member keys and perform operations on behalf of the organization.
• Create verification seals — the platform signs a cryptographic seal for each document, certifying that the document was processed inside the enclave and hasn't been tampered with.

Before the enclave can use the platform key, it must prove its identity through attestation. The hardware verifies that the enclave code hasn't been modified and that the environment is genuine. Only after passing attestation can the enclave access the platform key.

Key Wrapping And Protection

Keys in Literal are protected through wrapping — encrypting one key with another:

• Document keys are wrapped with your personal master key (for personal access) and optionally with organization keys (for shared access).
• Your private encryption and signing keys are wrapped with your personal master key.
• The organization secret is wrapped with a dedicated hardware-protected platform key, provisioned per organization, that can only be accessed inside the secure enclave with valid attestation.
• The entity encryption key is wrapped with your hybrid public encryption key and stored in your membership record.

This layered approach means that access to any single key doesn't grant access to all your data. Each layer provides an independent barrier.

Recovery

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

Post-Quantum Protection

Key exchange and key wrapping use hybrid schemes that combine a well-established classical method (X25519) with a post-quantum method (ML-KEM-1024). Both must be broken simultaneously for an attack to succeed. This applies across all key transport paths — entity key wrapping, delivery key wrapping, grant key transport, and platform DEK wrapping.