Walilock is built so that we — and anyone who breaches our servers — mathematically cannot read your vault contents. Here is exactly how that works.
Encryption and decryption happen locally. Your vault contents reach the relay already encrypted — it cannot decrypt them, because it never has your keys.
Master password → key derivation → XChaCha20-Poly1305 encryption, all local.
Stores and forwards encrypted blobs. No keys. Ever.
Pull the blob, decrypt locally with the same key. End to end.
You sign in without ever sending your password — not even a hash. OPAQUE is an aPAKE protocol: the relay proves you know your password without learning it. A stolen server database reveals nothing usable for signing in as you.
Every item's contents are encrypted locally with authenticated XChaCha20-Poly1305 before they touch storage or the network — the relay holds no key to decrypt them.
Your vault key is derived with a memory-hard KDF (Argon2id) and bound to a per-device secret. Keys live in the OS keychain / Secure Enclave where the platform supports it — never written to disk in the clear.
Every change your devices make is signed on-device with a key the relay never receives, and the relay refuses any write that isn't correctly signed or that tries to roll a version backwards. Someone who steals your account password still cannot alter or delete what's in your vault. Device-side verification of incoming changes is in active development.
| Vault encryption | XChaCha20-Poly1305 (authenticated) |
| Encrypted export files | AES-256-GCM (authenticated) |
| Authentication | OPAQUE aPAKE — password never transmitted |
| Key derivation | Argon2id |
| Key storage | OS keychain · Secure Enclave / TPM where available |
| Passkeys | WebAuthn / FIDO2 · CXP / CXF for transfer |
| Transport | TLS 1.3 + application-layer E2E encryption |
| Breach data | HIBP k-anonymity range queries (first 5 characters of the SHA-1 hash only) |
| Post-quantum | Hybrid X25519 + ML-KEM-768 key exchange for shared family and company vault keys; sync layer on the roadmap |
The same model in plain text, with what the relay stores and each recovery case: the security model.
We design for the worst case. Here is how Walilock holds up.
Attackers get encrypted blobs and no keys. There is no master password or vault key on the relay to steal, so your vault contents stay unreadable.
Traffic is TLS 1.3 encrypted in transit and already end-to-end encrypted at the application layer. A man-in-the-middle sees ciphertext twice over.
Keys for shared family and company vaults are already exchanged with hybrid post-quantum cryptography (X25519 + ML-KEM-768), so a key exchange captured today can't be decrypted by tomorrow's "harvest-now, decrypt-later" attacks. Extending it to the sync layer is on our roadmap.
The vault key is device-bound and protected by your master password plus the OS secure element. A lost device's data can't be unlocked without your secret, and you can revoke the device from sync.
By design, we cannot recover it — that's the trade-off for true zero-knowledge. Save an emergency kit when you enable sync — it restores access after a lost or wiped device, though it cannot replace a forgotten master password.
Paste it into the free lookalike link checker to see whether its address imitates a site people sign in to. It runs in your browser, and nothing you paste leaves the page.