Threat model
We defend against: server compromise (someone steals the database), network adversaries (someone reads traffic between you and the server), lost or stolen device (with vault locked).
We don't defend against: an attacker who already has access to your unlocked machine. No notes app does. If your laptop is unlocked and an attacker is sitting at it, they can read your notes the same way you can.
What the server sees and doesn't see
Sees
- Your account email
- Opaque encrypted blobs
- HMAC'd path identifiers (so it can route updates without learning the filename)
- KDF salt and parameters
- A verifier blob proving you can derive the key
Doesn't see
- Plaintext content
- Plaintext paths or filenames
- Your password or any password-derived key
- Your master key or any per-file key
The crypto stack
- KDF
- Argon2id, m=64 MiB, t=3, p=4. Output is a key-encryption-key (KEK).
- Master key (MK)
- 32 random bytes generated at vault setup. Wrapped under KEK, stored locally. Never derived from your password directly — that means changing your password is cheap (re-wrap the MK, no re-encryption of files needed).
- Per-file
- Every note has its own data encryption key (DEK). DEKs are wrapped under MK. Content is encrypted with XChaCha20-Poly1305 AEAD.
- Filename privacy
- The server-visible identifier for each entry is HMAC-SHA256(path_key, normalized_path). Deterministic for routing, opaque to the server. The plaintext filename is encrypted alongside the wrapped DEK.
Recovery phrase
12 BIP39 words generated at setup, shown once, never stored on the server. The phrase encrypts a copy of the master key.
Forget your password, the phrase still works. Lose both — your data is unrecoverable. We can't recover it for you. That's the deal.
Cryptography summary
The crypto stack is documented above. We use widely-reviewed primitives (Argon2id, XChaCha20-Poly1305, BIP39) from well-maintained libraries — not hand-rolled crypto. If you'd like a third-party security review of Jotura's design, get in touch.