Zero-knowledge architecture
The server stores only ciphertext. We hold no key, no password, and no readable content — by design, not just by policy.
Trust model
The security boundary is not a promise — it is a consequence of the architecture. The server never receives the inputs needed to decrypt your data.
auth_token (HKDF-derived credential)Core guarantees
Your password runs through Argon2id locally to produce a master key. The server receives only an HKDF-derived auth_token — a credential mathematically separated from the password and from the encryption keys. Even if this token were stolen, it cannot decrypt any vault content.
Your X25519 and ML-KEM-768 private keys are generated in the browser and immediately wrapped with AES-256-GCM(master_key, …) before being uploaded. The server stores the ciphertext. Without your master key — which never leaves your device — the blobs are meaningless.
Every save generates a fresh Data Encryption Key (DEK) at random. The DEK encrypts your mind map with AES-256-GCM, then is itself wrapped using a hybrid classical + post-quantum KEM. The server stores the wrapped DEK and the blob — but has no input to unwrap the DEK. No key reuse across saves.
How it works
The server hashes auth_token again with Argon2id before storing — so even the credential in the database is a derived hash, not the original token.
The DEK is never stored anywhere. It is re-derived on demand by the client using their private keys. Each save is independently encrypted — no key reuse between saves or between users.
Cryptography stack
Encrypts all content: mind map blobs, map titles, and private key blobs. Uses the browser's native Web Crypto API — no third-party symmetric crypto library.
Derives the master key from your password. Parameters: 64 MiB memory, 3 iterations, 4 threads. Implemented via hash-wasm (WebAssembly) — runs entirely in your browser.
Elliptic-curve Diffie-Hellman used for the classical half of the hybrid KEM. Generates an ephemeral keypair on every save — no long-term encryption key reuse. Implemented via @noble/curves.
The post-quantum half of the hybrid KEM. Standardised by NIST in 2024 (FIPS 203). Protects against future quantum computers that could break X25519 using Shor's algorithm. Via @noble/post-quantum.
Derives domain-separated keys from the master key ("crypt-mind-auth-v1", "crypt-mind-title-v1", "crypt-mind-dek-v1") and combines the classical + post-quantum shared secrets. Via @noble/hashes.
Combines X25519 and ML-KEM-768 shared secrets via HKDF: HKDF(classical_shared ‖ pq_shared). Security holds if either layer remains unbroken — a conservative, defence-in-depth design.
Data inventory
Argon2id(auth_token) — credential hashAES-256-GCM(master_key, x25519_private)AES-256-GCM(master_key, mlkem_private)AES-256-GCM(DEK, map_content) — MinIOAES-256-GCM(title_key, map_title)If the entire database and object storage were stolen, an attacker would see only opaque ciphertext blobs and public keys. Without your password, the content is computationally infeasible to recover.
Threat model
auth_token alone cannot decrypt any vault content.The security whitepaper covers every flow in detail: full key derivation trees, complete threat model, session security, and technology stack.