Security Model

Every file is encrypted on your machine before it touches the network. The server has no way to decrypt your content, derive your keys, or read your data. Even if the server were compromised or legally compelled to hand over data, an attacker would get only encrypted blobs with no practical path to decryption.

There is no "forgot password" flow. If you lose your passphrase, your data is unrecoverable. This is a deliberate tradeoff: we chose strong guarantees over convenience.

All encryption keys are derived from a single passphrase through a three-stage hierarchy. No keys are stored in plaintext anywhere.

Passphrase
    │
    ▼  Argon2id (memory-hard KDF)
    │
Master Key (256-bit)
    │
    ├─ HKDF-SHA256 ──▶  Vault Key   ──▶  per-folder  ──▶  per-file keys
    │                                       (AES-256-GCM)
    ├─ HKDF-SHA256 ──▶  Auth Key    ──▶  BLAKE3 hash sent to server
    │
    └─ HKDF-SHA256 ──▶  Sharing Key  (reserved for future use)

Stage 1: Passphrase to Master Key. Your passphrase is processed through Argon2id, a memory-hard key derivation function designed to resist GPU and ASIC-based brute-force attacks. A random 256-bit salt is generated per user and stored server-side (the salt alone is useless without the passphrase).

Stage 2: Master Key to domain keys. HKDF-SHA256 derives three independent keys from the Master Key. Each branch uses a unique context string, ensuring compromise of one key reveals nothing about the others.

Stage 3: Vault Key to file keys. The Vault Key is further derived into per-folder and per-file keys using HKDF. This hierarchical approach means individual file keys can be computed on-the-fly from the passphrase without storing any key material on disk.

Each file is encrypted with AES-256-GCM (Galois/Counter Mode), an authenticated encryption algorithm that provides both confidentiality and integrity in a single operation. A fresh random 12-byte nonce is generated for every file encryption, ensuring no two encryptions produce the same ciphertext even for identical content.

The encrypted format includes a version prefix, enabling future algorithm upgrades without breaking existing vaults.

File content is hashed with BLAKE3 before encryption. These hashes are used for conflict detection and sync protocol operations. BLAKE3 is a modern cryptographic hash function that is both fast and resistant to length-extension attacks.

The server never receives your Auth Key directly. Instead, the client computes a BLAKE3 hash of the Auth Key and sends that hash during registration and login. The server stores only the hash and verifies it using constant-time comparison to prevent timing attacks.

API keys for programmatic access (e.g., MCP server integrations) are stored as SHA-256 hashes and support path-based scoping and permission levels (read, write, or both). Keys can be revoked at any time.

ContextMate uses the @noble family of cryptographic libraries, which are peer-reviewed, independently audited, and focused on constant-time implementations to prevent side-channel attacks.

An attacker with full server access would obtain encrypted blobs, auth key hashes, and Argon2id salts. They would not have any plaintext content, encryption keys, or passphrases.

Decrypting the data would require brute-forcing each user's passphrase through Argon2id, which is designed to be computationally and memory-intensive. A strong passphrase makes this practically infeasible.

The entire ContextMate codebase is open source under the MIT license. Every cryptographic operation can be inspected, verified, and audited by anyone. We believe security through transparency is stronger than security through obscurity.

View the source on GitHub →