Security — AES-256-GCM, zero-knowledge, threat model
How Filarr protects your data: files encrypted on your disk, KEK/FEK architecture, optional end-to-end encrypted cloud sync.
KEK / FEK Architecture
Filarr uses a two-level key system. Each file is encrypted with its own File Encryption Key (FEK) using AES-256-GCM. The FEK is itself protected by a Key Encryption Key (KEK) derived with PBKDF2-SHA-512, 600,000 iterations — the exact same derivation for your password and for your recovery phrase. If one FEK is compromised, only that file is exposed — not the rest of your data.
Which derivation, for which key
A product sold on encryption should be able to say which one, where, and with what parameters. Here is the full table, read back from the code of all three surfaces — desktop, web and mobile.
| Path | Derivation | Parameters | Surfaces |
|---|---|---|---|
| Account password → KEK | PBKDF2-SHA-512 | 600,000 iterations, 16-byte salt, AES-GCM-256 | Desktop, web, mobile |
| Recovery phrase → KEK | PBKDF2-SHA-512 | 600,000 iterations — the exact same function as above | Desktop, web, mobile |
| Local vault key, at rest | None — random 256-bit key | Sealed by the system keychain (DPAPI, Keychain, Keystore) | Desktop, mobile |
| File content | None — encrypted under its FEK | AES-256-GCM, 96-bit IV, 128-bit tag | All |
| Block-synced file (delta) | HKDF-SHA-256 | Derived from the FEK, 16-byte salt, “filarr-delta-v4” context, 32-byte output | Desktop, web |
| Custody key (escrow) | Argon2id | m = 19 MiB, t = 2, p = 1, 32-byte output | Desktop, web, mobile |
| Password-protected Filarr Send | Argon2id | m ≤ 64 MiB, t ≤ 10, p = 1 — clamped by the server | Desktop, web, mobile |
| Passkey unlock (WebAuthn PRF) | HKDF-SHA-256 | Separate, versioned domain | Desktop, web |
| Device pairing | HKDF-SHA-256 over ECDH P-256 | Uncompressed 65-byte public keys, 32-byte shared secret | Desktop, web, mobile |
Two points that often get lost. The FEK that encrypts your files is randomly generated, never derived from a password: the password only protects its wrapper. And passkey unlock exists on desktop and web only — on mobile, the second factor is a TOTP code. The key for block-synced files is derived from the FEK, never from a password either. Its context stays “filarr-delta-v4” even in the latest manifest layout: the derivation context is deliberately not versioned alongside the data layout, since changing one would make the other unreadable.
Your password stays with you
All encryption and decryption happens on your machine, and your password never leaves your device. Two distinct protections coexist, and it helps to know which does what. What leaves the machine — the copy of your key that makes multi-device access possible — is protected by a key derived from your password with PBKDF2-SHA-512, 600,000 iterations: without that password, the copy is useless, to us included. What stays on disk is encrypted with AES-256-GCM under a randomly generated key sealed by the operating system’s own vault — DPAPI on Windows, the Keychain on macOS, Keystore on Android. That model protects a stolen disk or a backup image; it does not protect against someone who already has your unlocked session. An honest caveat: on a Linux machine with no working keyring, Filarr falls back to a permission-restricted file, and the protection against disk theft no longer applies. When cloud sync is on, our servers (Cloudflare R2) only ever receive encrypted blobs.
Two-factor authentication (TOTP)
Optional from Settings > Security inside the app. Compatible with any standard TOTP app (Authy, Google Authenticator, 1Password, Bitwarden). At login: password, then a 6-digit code. 8 single-use backup codes are generated at activation so you aren't locked out if you lose your TOTP device.
The TOTP secret is stored server-side (required to verify codes) but grants no access to your files — it only protects the login to your account. Your password remains the only key that unlocks your data encryption.
- TOTP RFC 6238 (SHA-1, 6 digits, 30s period)
- Every standard TOTP app: Authy, Google Authenticator, 1Password, Bitwarden
- 8 single-use backup codes, hashed server-side
- Rate-limited to 10 attempts / 15 min / IP
Threat Model
Since your plaintext data never leaves your machine — and the copy of your key we store is useless without your password — Filarr’s threat model is fundamentally different from a typical cloud service. The main threats are physical access to your device, losing your password, or a password weak enough to be brute-forced if our servers were ever compromised (which is why we strongly recommend a password manager).
- Physical access to deviceProtected by AES-256-GCM encryption
- Password lossRecoverable via recovery phrase only
- Malware on deviceKeys in memory only during use
- Disk theftEncrypted with AES-256-GCM, key sealed by the system keychain
- Brute force attackPBKDF2-SHA-512, 600,000 iterations
- Online account takeoverProtected by optional TOTP 2FA
What this means in real life
Encryption is only useful if it protects you in the situations that actually happen.
Your laptop gets stolen
Your files are encrypted with AES-256-GCM. Without your vault password, they’re unreadable — even with full disk access. The thief gets an encrypted hard drive, not your documents.
A cloud provider gets breached
Filarr only stores encrypted blobs on our servers. Your files are encrypted on your device before upload. Even if our storage is compromised, attackers get unreadable ciphertext — not your files.
A legal request for your data
If Filarr receives a legal request, we can only hand over encrypted blobs — files plus the encrypted copy of your key. Without your password nothing is decryptable, and we never see your password. This isn’t a policy — it’s a technical fact.
You forget your vault password
This is the cost of end-to-end encryption. Your key is protected by a derivative of your password (PBKDF2-SHA-512, 600,000 iterations), and your password is never transmitted to us — if you lose it, we cannot recover your data. We recommend using a password manager and exporting a recovery key from Settings > Security.
What if Filarr gets curious?
We can’t. Your files are encrypted with a random key, itself protected by a key derived from your password using PBKDF2-SHA-512 with 600,000 iterations. We store that key in encrypted form to enable multi-device access, but we never see your password — so we can never unwrap it. Our servers only see random-looking bytes.
Your internet goes down mid-session
Filarr is local-first. Everything works offline — notes, files, graph, canvas. Changes sync automatically when you reconnect. No internet required to access your own files.
Multi-profile isolation
Each profile in Filarr has its own set of encryption keys. Data in a “Personal” profile is completely isolated from a “Client A” profile. Even if one profile is compromised, the others remain protected.
What our servers still know
End-to-end encryption protects the CONTENT, not the fact that you use it. Our servers therefore see some traces of use — never what is written, never a file name, never a title. Here they are in full, rather than in a footnote.
Mentions
That you mentioned someone, in which item of which vault, and when.
Never the note’s text or its title: your device resolves them with your keys.
Live co-editing
Which devices are connected to which note, and when.
Never what is typed there: the relay forwards encrypted bytes it cannot open. This feature is off by default.
Phone notifications
They travel through Google’s servers, and carry the name of the person who mentioned you.
Never a title or an excerpt — what we do not have cannot become readable elsewhere.
Sync
The number of files, their size, the date they last changed.
Never their names, never their content, never the shape of your folders.
What we’re still working on
Cloud sync is live with end-to-end encryption — your files are encrypted on your device before upload. The desktop client is now published on GitHub under Business Source License 1.1: you can read the code and verify the cryptographic claims directly, rather than trusting us on our word. An independent security audit is on the roadmap. There’s no SOC2 or HIPAA certification yet.
Same guarantee for file sharing
Filarr Send applies the same AES-256-GCM encryption. The key stays in the URL, never on our servers.