Security model

#Zero-knowledge principle

MimiKey separates having an account from being able to decrypt. Your account answers who you are, where your vaults live and which devices belong to you. The two secrets needed to decrypt anything — your master password and your Secret Key — exist only on your devices and are never sent to the server.

Three invariants follow, and every client (Mac, iOS, web) and the third-party authorization platform upholds them:

1. Items are encrypted on your device before upload. The server only stores and relays ciphertext.
2. Nothing the server stores — login verifiers, key wraps, token hashes — is sufficient to decrypt your items.
3. A third-party app only ever receives a single result that you approved, one request at a time, inside MimiKey's own interface, sealed to that app's current authorization.

Important Zero knowledge protects you against an honest-but-breached server and against database leaks. It cannot protect a device that is already controlled by malware. See the threat model below.

#What the server stores

#What the server never stores

• Your master password, in any form (including hashes)
• Your Secret Key
• Your personal vault key, or any shared vault key in plaintext
• Item plaintext
• Your account identity private key in plaintext
• A third-party app's seal and approval private keys (they live only in that app's system keychain)

Note The server can still observe some metadata: how many items you have, ciphertext sizes, modification times, the timeline of devices and requests, and the hints a third-party app attaches to its requests (reason, hint, prefill, fields). Those fields are plaintext, and integrators must never put credentials in them.

#Two-secret key derivation (2SKD)

All of your account keys are derived from two secrets together:

• Master password — the passphrase you remember, 12–1024 bytes long.
• Secret Key — a 128-bit random key generated on your device at sign-up and displayed as PM- followed by 26 Crockford Base32 characters. It is stored only on your devices and in your Emergency Kit.

Together with your account salt they go through Argon2id (64 MiB of memory, 3 iterations, 1 lane), domain-separated by purpose, producing three independent values:

As a result:

• If the database leaks, an attacker must guess both your master password and a 128-bit Secret Key, paying the Argon2id cost for every guess. Offline brute force is not feasible.
• Your master password alone is not enough. A new device must enter the Secret Key on first sign-in.
• Account recovery requires your Secret Key. Without your Emergency Kit there is no recovery path; the server cannot compute one for you. If both your master password and Secret Key are lost, your data is unrecoverable by design.

The full list of parameters and domain strings is in Encryption.

#SRP sign-in

Sign-in uses SRP-6a (RFC 5054 2048-bit group, SHA-256). The identity is your normalized (trimmed, lowercased) email address:

1. The client sends an ephemeral public value A; the server returns the salt and its ephemeral value B.
2. Both sides compute a shared key. The client sends proof M1; the server verifies it and returns proof M2, which the client verifies in turn.
3. On success the server issues an account session token (valid for 30 minutes).

Your master password, Secret Key and login material never cross the network; passively observing or replaying a handshake yields nothing usable. After sign-in, the client re-derives the vault key and identity material locally from the same two secrets and decrypts your items.

Important A leaked SRP verifier is still a target for offline guessing, at the cost set by 2SKD. The stronger OPAQUE protocol is on the roadmap and not yet implemented.

#Devices and sharing identity

Device registration. Every device that signs in registers its public key with the server. You can revoke a device at any time from your device list: its sessions end immediately and further challenge sign-ins are refused. The last active device on an account cannot be revoked.

Account identity key. Each account has an X25519 identity key pair. The public key is stored openly; the private key is sealed with your identity material and stored on the server, so any client that completes SRP sign-in can unseal it locally. The identity fingerprint is the first 8 bytes of the public key's SHA-256, in hex, for manual comparison.

Shared vaults. Your personal vault key is derived by 2SKD and never distributed. A shared vault uses a random 32-byte key that is wrapped for each member individually with a sealed box addressed to that member's identity public key. The server stores only the wraps and a key fingerprint.

Removing a member. The owner's client first re-encrypts every item with a new random vault key, then distributes new wraps to the remaining members, and only then asks the server to remove the member. The removed member can no longer sync new ciphertext, but anything they already obtained or exported while they were a member can still be opened with the old key. That is an inherent limit of end-to-end encryption.

#Local protections

Biometrics on iOS. Your master password is not stored on the device by default. Only when you explicitly turn on biometric unlock is it written to the keychain with biometryCurrentSet access control, which also requires a device passcode. Adding or removing a fingerprint or face invalidates the item automatically; you then unlock with your master password and turn biometrics on again.

Touch ID on Mac. When enabled, the Mac generates a non-exportable, biometry-gated key in the Secure Enclave and uses it to protect a random wrapping key, which in turn seals the three 2SKD outputs. The record file is readable only by you and contains neither your master password nor your Secret Key. The sealed data is bound to the server address and your account email, so it cannot be moved to another account, and it stops working after a master password change or account recovery.

Important Clipboard history, cloud clipboards, and copies that another process read before clearing cannot be recalled. Clipboard clearing is hygiene, not isolation.

#Third-party authorization guarantees

Third-party apps integrate through the MimiKey SDK (see the developer overview). The platform guarantees the following to you:

• Decisions happen only inside MimiKey. Consent, picking, reading, creating and updating are all approved on cards rendered by MimiKey's own process. The third-party app may only show non-decision notices such as "Opening MimiKey…"; it cannot click buttons for you, overlay a fake card, or read what you enter.
• Only the item you approved. The app never sees your item list. Every result is a single item sealed to a seal key unique to that app installation and that authorization; the server sees only ciphertext.
• Plaintext for new and changed items bypasses the app. You type new passwords on MimiKey's own safety card. New values in an update are sealed by the SDK to your account identity public key, so only your unlocked device can open them.
• A stolen token is not enough. Every data call must carry an Ed25519 signature from that grant's approval private key, within ±300 seconds, with a single-use nonce. The approval key lives only in that app installation's system keychain.
• Callbacks carry no data. The URL that returns you to the app contains only code, request_id, state and status. Even if another app hijacks the custom URL scheme, it gets no ciphertext and no plaintext.
• Revocation is immediate. You can revoke any grant from Third-party access in MimiKey, and the platform operator can disable an abusive integrator; all of its grants and tokens stop working at once.

Important Once you approve handing an item to an app, that app holds the plaintext. MimiKey cannot control what it does afterwards. Only authorize apps you trust.

#Threat model summary

#What MimiKey defends against

#What MimiKey does not defend against

• A compromised device. Malware, other processes running as your user, and administrator-level software can read memory, the Secret Key in local storage, keystrokes or the screen.
• A tampered web front end. If the server is compromised and serves malicious scripts, it can read the Secret Key from browser storage and capture your master password while you use the web app. For high-assurance use, prefer the native Mac and iOS apps.
• A weak master password combined with a leaked Secret Key. With both in an attacker's hands, only the strength of your master password remains.
• Forgetting both secrets. Your data is unrecoverable by design; there is no back door.
• Data already handed over. Results you approved for third-party apps, data a removed member obtained earlier, and clipboard history cannot be taken back.
• Metadata. The server sees item counts, sizes, timestamps and the hint text in third-party requests.
• A malicious server withholding or replaying old ciphertext. There is no anti-rollback ledger yet. The server cannot read or forge item contents, but it can deny service, hide items, or serve an older revision.
• Quantum computers. X25519 and Ed25519 are not post-quantum.

#Audit status

MimiKey is in internal beta and has not yet undergone an independent third-party security audit.

What is in place today:

• The cryptographic core uses established open-source implementations (RustCrypto Argon2, XChaCha20-Poly1305, HKDF and SRP, plus curve25519-dalek and ed25519-dalek), and wipes keys from memory with zeroize.
• The Rust, Swift and JavaScript implementations are cross-checked against shared test vectors (see Encryption).
• Every critical server flow has end-to-end acceptance tests run against an isolated environment.

Until an independent audit is complete, we recommend that you do not keep the only copy of your most critical accounts — banking, primary email, Apple ID — in MimiKey. Outstanding work includes OPAQUE sign-in, an anti-rollback ledger, post-quantum key exchange, and the independent external audit.