Security model
Imok is a zero-knowledge encryption service: your handover packet is encrypted in your own browser before it's uploaded, and our servers store only ciphertext. There is no point in the system — not at rest, not in transit, not in our database — where we can read what you wrote.
Encryption details
- Algorithm: AES-256-GCM (authenticated encryption, so tampering is detected on decryption).
- Key derivation: PBKDF2 with SHA-256 and 310,000 iterations, from the passphrase you choose.
- Unique salt per packet, so identical passphrases never produce identical keys.
- Stored server-side: the ciphertext, the IV, the salt, and the iteration count — everything needed to decrypt, except the one thing that matters: your passphrase.
- The passphrase never leaves your browser. It is never transmitted to our servers in any form, which is why we cannot recover it for you.
What we store vs. what we never see
| On our servers | Never on our servers |
|---|---|
| Encrypted packet (ciphertext) | Your passphrase |
| IV, salt, PBKDF2 iteration count | Your plaintext handover packet |
| SHA-256 hashes of reveal and check-in tokens | The tokens themselves |
| Your email address (for sign-in and check-ins) | Passwords — sign-in is by magic-link email |
| Switch state and check-in timestamps | The contents of reminder or reveal emails beyond their templates |
Tokens, links, and sessions
- Reveal and check-in tokens are random 32-byte values, stored only as SHA-256 hashes. A database dump cannot be used to forge a link.
- Reveal links are one-time: they expire after the first successful reveal or after 30 days, whichever comes first.
- Rate limits: magic-link requests capped at 5 per hour per email; reveal fetches capped at 10 per hour per IP.
- Sessions use httpOnly, Secure, SameSite=Lax cookies, and state-changing requests are protected by Origin header CSRF checks.
- Authentication is magic-link email — there is no password database to steal and no password reuse to exploit.
Free during early access · We can never read your packet
Threat model — what this protects against
Server breach. Attackers get ciphertext only. Without your passphrase, the packet is indistinguishable from random bytes.
Database dump. Tokens are stored hashed, so dumped data can't be used to open reveal or check-in links. There are no passwords to crack.
Curious insiders. There is no admin tool, support backdoor, or "view packet" button. We engineered ourselves out of access.
What this does NOT protect against
Honesty matters more than marketing here. Imok does not protect against:
- A lost passphrase. Lost passphrase = lost packet, forever. We cannot recover it. Write a new packet instead.
- A weak passphrase. 310,000 PBKDF2 iterations slow attackers down, but a passphrase like "fluffy123" is still guessable. Use a long one.
- A compromised successor device. Once your successor decrypts the packet in their browser, its safety is in their hands, not ours.
- Prolonged silence that isn't an emergency. If you stop checking in and ignore 5 days of reminders and your trusted contact's nudge, the packet will release as designed. The layered stages make this unlikely — but the switch only knows what it can measure. See how it works for the full sequence.
The trusted-contact notice, by design
When your switch reaches CONTACTING_TRUSTED, the trusted contact receives one neutral message asking them to check on you. It deliberately does not mention the packet, the handover, or the reveal link. This protects you twice: your plans stay private if the alert turns out to be a false alarm, and the trusted contact can't intercept or demand the packet — they simply never learn it exists.
Security FAQ
Can Imok employees read my handover packet?
No. Your packet is encrypted in your browser before upload, and the passphrase-derived key never leaves your device. Our servers store only ciphertext, an IV, a salt, and the iteration count — there is nothing for us, or anyone with access to our systems, to read.
What happens if Imok's servers are breached?
An attacker gets encrypted packets (useless without each owner's passphrase) and SHA-256 hashes of tokens (not the tokens themselves). There are no passwords to steal, because sign-in uses magic links. The design goal is that a full database dump yields nothing usable.
What if I lose my passphrase?
The packet becomes unrecoverable — permanently. We cannot recover or reset your passphrase because we never see it. The fix is to write a new packet with a new passphrase and make sure your successor arrangement is updated. We'd rather lose your packet than be able to read it.
Does the trusted contact learn about the packet?
No. The trusted contact receives exactly one neutral message asking them to check whether you're okay. It deliberately does not mention a packet, a handover, or what Imok does. Only your designated successor ever receives the reveal link.
How are the reveal and check-in links protected?
Both use random 32-byte tokens stored only as SHA-256 hashes. Reveal links work once and expire after 30 days or first use. Reveal fetches are rate-limited to 10 per hour per IP, and magic-link requests to 5 per hour per email. Details are on this page and in how it works.
Related reading: zero-knowledge encryption explained simply, what is a dead man's switch, and our pricing (free during early access).