How NomadVault keeps keys away from the server
This page describes the cryptography we use, what each component can and cannot see, and the threats this design does not address. Reviewed September 2026.
Trust model
We assume our own infrastructure can be compromised. The design therefore places every key and every plaintext operation in the client, and treats the tenant API, database and object storage as untrusted stores of ciphertext. An operator with full database access obtains file sizes, timestamps and wrapped keys, not content.
02 / 03 The server receives ciphertext, not your document contents. Metadata and access events remain visible.
What the server can and cannot see
File sizes, MIME types, timestamps and version counts Folder structure and the sharing graph: who has access to which file or folder, with which role User identities, sessions and every audit event Access patterns: who opened, uploaded or downloaded what, and when Blinded search tokens: which tokens occur in which file, how often, and which files a query matched, never the words behind them
File contents File and folder names Notes and previews Any private key, file key or search key Your password
Key hierarchy
The chain starts at the individual user, not the tenant. Each user derives their own Account Master Key from their password with Argon2id in the browser; it unlocks only that user's RSA-4096 and ML-KEM-768 key pairs. Every file has its own symmetric key, wrapped to those key pairs twice, classically and post-quantum, so that a future break of RSA alone does not expose content. There is no tenant-wide master key and no administrator key: an admin who has not been granted a file cannot decrypt it.
Encryption flow on upload
- 01SanitiseContent Disarm & Reconstruction strips macros, scripts and embedded objects in the browser.
- 02Generate file keyA 256-bit key and 96-bit nonce from the platform CSPRNG, per file version.
- 03Encrypt in chunksAES-256-GCM over 10 MB chunks, each with its own nonce and the chunk index as authenticated data, the last one size-padded; streamed as it is produced.
- 04Wrap the key twiceRSA-4096-OAEP and ML-KEM-768 encapsulation, combined with HKDF.
- 05Upload and recordCiphertext goes to your bucket; the tenant records the wrapped key, the encrypted metadata envelope and an audit entry.
Threat model
What this design stops, and what it does not.