Skip to main content

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:
  • Envelope rooms (the default) rely on a hardware-backed master key that only Enclave’s authenticated servers can invoke. See 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.

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:

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

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 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 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.

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

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. 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

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.