> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kvelden.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Zero-Knowledge Design
> What zero-knowledge means in Enclave — and what it doesn't.
## What zero-knowledge means here
In Enclave, zero-knowledge means: **Kvelden cannot read your files, and cannot be compelled to hand over their plaintext.**
This is not a policy statement. It is an architectural property — but the specific mechanism depends on the room's [encryption mode](/enclave/rooms#encryption-modes):
* **Envelope rooms** (the default) rely on a hardware-backed master key that only Enclave's authenticated servers can invoke. See [Envelope rooms](#envelope-rooms).
* **Zero-Knowledge and ZK Strict rooms** go further: Enclave never holds — wrapped or otherwise — any key capable of decrypting room content. See [Zero-Knowledge and ZK Strict rooms](#zero-knowledge-and-zk-strict-rooms).
## Envelope rooms
Envelope rooms are built on four guarantees:
1. Files are encrypted on your device before upload
2. The decryption keys are in your KMS or our HSM — accessible only via authenticated KMS API calls from authorised clients
3. Kvelden's servers store only ciphertext and wrapped keys
4. Even Kvelden employees with database access cannot decrypt files
### What we do see
We want to be precise about what metadata Enclave does process:
| Data | Seen by Kvelden? | Notes |
| ---------------------- | ---------------- | ------------------------------ |
| File ciphertext | ✓ (stored) | Meaningless without keys |
| File name | ✓ | Stored in database |
| File size | ✓ | Stored in database |
| Upload timestamp | ✓ | Audit log |
| Uploader identity | ✓ | Audit log |
| Room name | ✓ | Stored in database |
| Wrapped DEKs | ✓ (stored) | Meaningless without master key |
| Plaintext file content | ✗ | Never transmitted or stored |
| Master keys | ✗ | Live in your KMS / our HSM |
### The HSM boundary
When using Kvelden-managed keys, the master key lives in a FIPS 140-2 Level 3 HSM. The HSM enforces:
* Only authenticated Enclave application instances can request key operations
* Key operations are logged
* The key material never leaves the HSM — only wrapped outputs are returned
Even Kvelden engineers cannot extract the master key from the HSM. The HSM's tamper-resistant hardware enforces this at the physical level.
## Zero-Knowledge and ZK Strict rooms
Zero-Knowledge and ZK Strict rooms remove Enclave from the key hierarchy entirely. There is no master key, KMS, or HSM in this model — every key capable of decrypting room content is generated in a member's browser and never leaves it in plaintext form.
### Key hierarchy
| Key | Generated by | Stored by Enclave | Form stored |
| ----------------------------------- | -------------------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Personal key pair (X25519) | Each member's browser, on first access | Private key only | Encrypted with a key derived from the member's passphrase (PBKDF2-HMAC-SHA-256, 600,000 iterations) |
| Room encryption key (REK) | The first member's browser, on room creation | ✓ | One copy per member, each individually wrapped to that member's public key using a hybrid post-quantum KEM (X25519 + ML-KEM-768, HKDF-SHA-256, AES-256-GCM) — never stored unwrapped |
| File / message / secret keys (DEKs) | The uploading member's browser | ✓ | Wrapped by the REK |
Because every stored form of the REK is wrapped to an individual member's public key, and the matching private key is itself encrypted with a key derived from a passphrase Enclave never receives, **no record Enclave holds — alone or in combination — can decrypt room content.**
**Post-quantum ready.** Room keys are wrapped with a *hybrid* key-encapsulation mechanism — classical X25519 combined with ML-KEM-768 (NIST FIPS 203). Wrapped keys captured today remain confidential even against a future quantum computer, and stay secure as long as *either* algorithm holds. See [Cryptographic Primitives](/security/cryptography#zero-knowledge-key-encapsulation-post-quantum-hybrid) for the full specification.
### Getting access
A member or external guest only receives a usable copy of the REK after (1) setting up their personal key pair, and (2) an online admin granting them access, which wraps the current REK to their public key. Until both steps are complete, they can see the room and its file list but cannot decrypt anything inside it. See [Encryption modes](/enclave/rooms#encryption-modes) for the full in-product flow.
### Losing — and recovering — access
Because the private key is encrypted with a passphrase Enclave never receives, a forgotten passphrase would normally mean lost access. Enclave provides two customer-controlled ways to recover without weakening any of the above: a self-service **recovery code**, and quorum-based **organization recovery** for when a key-holder is unavailable. See [Key Recovery](/security/key-recovery).
### Key rotation
Removing a member from a Zero-Knowledge/ZK Strict room triggers a **rotation**: a new REK is generated, re-wrapped for every remaining member (and any external guests with access), and every file, message, and secret in the room is re-encrypted under it — entirely client-side, in the admin's browser. The removed member's copy of the old REK cannot decrypt anything created after rotation.
### What we do see
| Data | Seen by Kvelden? | Notes |
| -------------------------------------------------------------------- | ---------------- | ---------------------------------------------------------- |
| File / message / secret ciphertext | ✓ (stored) | Meaningless without the REK |
| Per-member wrapped REK copies | ✓ (stored) | Each copy is meaningless without that member's private key |
| Encrypted private key packages | ✓ (stored) | Meaningless without the member's passphrase |
| File/room metadata (names, sizes, timestamps, membership, audit log) | ✓ | Same as Envelope rooms |
| Full-text search index, previews, thumbnails | ✗ | Never generated — would require server-side plaintext |
| Plaintext content, REK, private keys, passphrases | ✗ | Never transmitted or stored in any form |
### Server-side workflows
* **Zero-Knowledge** — A workflow (currently: e-signature requests) runs only after the affected member explicitly enables it for that one file. Their browser decrypts the file locally, computes a SHA-256 hash, and sends only that hash to the server — enough to issue a verifiable signing certificate without the server ever seeing plaintext. Every such consent is recorded in the audit log with a timestamp and IP address.
* **ZK Strict** — No server-side workflow is available, with or without consent. The relevant UI actions do not appear, and the server rejects the corresponding API calls outright.
### External guests
Guests invited from outside your organisation set up their own **vault** — a passphrase-protected key pair scoped to your organisation and reusable across every Zero-Knowledge/ZK Strict room you share with them. An admin grants the guest access to a room's REK the same way as for internal members, and decryption plus watermarking happen entirely in the guest's browser. See [Encryption modes](/enclave/rooms#encryption-modes).
## Legal compulsion
If Kvelden receives a valid legal order to produce customer data:
* We can produce: file ciphertext, file metadata, audit logs
* We cannot produce: plaintext file content (we do not have it)
* For BYOK/HYOK customers: we also cannot produce wrapped keys (those are in your KMS)
* For Kvelden-managed keys in Envelope rooms: we can produce wrapped KEKs, but not the HSM master key
* For Zero-Knowledge/ZK Strict rooms: we can produce the per-member wrapped REK copies and encrypted private key packages, but neither is usable without keys that exist only on members' devices and the members' own passphrases
We publish a transparency report annually covering the number and types of legal demands received.
## Threat model
| Threat | Enclave's defence |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Kvelden employee curiosity | No access to plaintext, master keys, or — for Zero-Knowledge/ZK Strict — any usable copy of the room key |
| Kvelden server breach | Attacker gets ciphertext and wrapped keys only; for Zero-Knowledge/ZK Strict, those wrapped keys are also useless without members' device-held private keys |
| Legal compulsion of Kvelden | Plaintext unavailable; master key in HSM (Envelope), or never held in any form (Zero-Knowledge/ZK Strict) |
| Rogue application server | Cannot decrypt without KMS authentication (Envelope), or any key material at all (Zero-Knowledge/ZK Strict) |
| Network interception | TLS 1.3; payload is ciphertext regardless |
| Compromised client | Out of scope — client must be trusted |
The client device is trusted. If your device is compromised (malware, physical access), an attacker can read files as they are decrypted — and, for Zero-Knowledge/ZK Strict rooms, could extract your private key while your vault is unlocked. Enclave cannot protect against a fully compromised endpoint — no encryption system can.