Built so we can't see your data.
Zero-knowledge isn't a promise we make. It's how MimiKey is built: what it takes to decrypt your vault never reaches our servers. Here's exactly how.
Where we are MimiKey has not yet had an independent security audit. This page describes the current design and implementation. We'll update it when the audit is complete.
Encrypted before it ever leaves your device.
Each item is sealed into an envelope on your device, then uploaded. Our servers store and sync those envelopes, but never hold a key that opens them.
Your device
Keys are derived here from your master password and Secret Key. Items are encrypted and decrypted here.
Encrypted envelope
The whole item is encrypted: title, URL, username, password and notes.
- 24-byte nonce
- Ciphertext
- Auth tag
MimiKey servers
Store and sync ciphertext. Nothing more.
What our servers store
- Your email and account status
- An SRP salt and verifier (your password can't be derived from it)
- Encrypted items
- Device public keys
What our servers never get
- Your master password
- Your Secret Key
- Your vault keys
- Any item in plaintext
Metadata we can see: how many items you have, the size of each ciphertext and when it changed.
Cryptography in detail
Every algorithm is public and widely scrutinized. The core is written in Rust and shared by every app.
| Purpose | Algorithm | Details |
|---|---|---|
| Item encryption | XChaCha20-Poly1305 | Each item gets its own subkey. Associated data binds the vault, item and revision, so ciphertext can't be moved into another item or vault. |
| Key derivation | Argon2id + HKDF-SHA256 | 64 MiB and 3 iterations slow down brute force. HKDF separates domains so subkeys are independent. |
| Sign-in | SRP-6a | 2048-bit group with SHA-256. The server stores only a verifier, and both sides authenticate. |
| Shared vaults | X25519 sealed box | The vault key is sealed to each member's identity key and bound to that vault and recipient, so it can't be passed on. |
| Signatures | Ed25519 | Signs device identity and third-party requests to prevent forgery and replay. |
| Passkeys | ES256 (P-256) | Private keys are stored as encrypted items and only sign on your device. |
AI and other apps only get the one item you approve.
Apps connected to MimiKey can't read your vault. Every request goes through an approval card shown by MimiKey itself.
Approval cards live inside MimiKey
Authorizing, picking, creating and editing items: every decision is rendered by MimiKey's own process. A connected app can't fake a card or tap it for you.
Sealed to one authorization
The item you approve is encrypted to this authorization on this device. Our servers relay only ciphertext, and an app that intercepts the callback can't open it.
No lists, no other items
Connected apps never see your item list, master password or Secret Key. When they ask you to save a new login, you type the password in MimiKey.
Take it back anytime
Revoke an app in MimiKey and its tokens stop working immediately.
What we haven't done yet, in plain sight.
- An independent security audit has not been completed.
- The web vault runs code served by our servers. If those servers were compromised, that code could be replaced. For everyday use, we recommend the native apps.
- Sign-in uses SRP today. The stronger OPAQUE protocol is on our roadmap.
- Revoking a device can't make it forget what it has already decrypted.
Take your passwords back.
Sign up free and start using MimiKey on every device you own.