Zero-Knowledge Encryption, Explained Simply

Zero-knowledge encryption means the service provider stores your data but mathematically cannot read it. Your content is encrypted on your own device, with a key that only exists on your own device, before anything is uploaded. The provider holds an encrypted blob — ciphertext — and has no more ability to open it than a stranger who finds a locked safe on the street.

That definition sounds abstract, so let us make it concrete.

The hotel safe vs the bank vault

A normal encrypted service is like a bank vault where the bank keeps a copy of every key. Your valuables are locked up, and the locks are good — but the bank can open your box if it wants to, if a court orders it, or if a rogue employee abuses access. You are trusting the institution, not the math.

Zero-knowledge is a hotel safe where you set the combination and the hotel genuinely does not have a master code. Staff can watch the safe, guard the safe, even move the safe — they cannot open it. If someone breaks into the hotel and steals every safe in the building, they have a pile of sealed metal boxes and nothing else.

The practical consequence: your trust shifts from policy (“we promise not to look”) to mathematics (“looking is impossible with what we hold”). Promises can be broken, subpoenaed, or quietly changed in a terms-of-service update. AES-256 cannot.

Why it matters for sensitive documents

A handover packet is among the most sensitive documents a person can create. It maps your accounts, your clients, your money, and your instructions for what happens when you are gone. In the wrong hands it is a complete blueprint of your business life.

With conventional server-side encryption, a breach of the provider potentially exposes that blueprint. With zero-knowledge, a breach leaks ciphertext, not your life. An attacker who steals the entire database gets: encrypted blobs, salts, and iteration counts. To read a single packet they would still need that user’s passphrase — which the database does not contain and never did.

This is not a theoretical comfort. Breaches of large, well-run services happen regularly. Zero-knowledge architecture means that when evaluating a service holding your most sensitive document, the question “what if they get breached?” has a boring answer: attackers get data that is computationally useless to them.

How Imok implements it, step by step

Here is the exact chain, with nothing held back:

1. You write your handover packet in the browser — the operational map for your successor.
2. You choose a passphrase. It never leaves your device. It is never transmitted, logged, or stored anywhere on our side.
3. Your browser derives an encryption key from that passphrase using PBKDF2 with SHA-256 and 310,000 iterations. The iteration count makes guessing passphrases expensive: each guess costs real computation, so brute force crawls.
4. Your browser encrypts the packet with AES-256-GCM, the same authenticated encryption standard used to protect classified and financial traffic worldwide.
5. The server receives and stores only four things: the ciphertext, the IV (initialization vector), the salt, and the iteration count. No key. No passphrase. No plaintext.
6. If the dead man’s switch triggers, your successor receives a one-time reveal link. They open the packet in their own browser, enter the passphrase you arranged for them to have, and decryption happens locally on their machine too.

At no point in the chain — not during storage, not during release, not during decryption — can Imok read the packet. We designed it so that we cannot, not merely so that we promise not to. You can read the full details on our security page and the delivery mechanics on how it works.

The honest trade-offs

Zero-knowledge has real costs, and you should hear them plainly:

• We cannot recover your passphrase. Lose it and the packet is gone forever. There is no “forgot my passphrase” flow, because any such flow would be a backdoor — and a backdoor for you is a backdoor for an attacker.
• Choose a strong passphrase. Length beats cleverness. Four or five random words is far stronger than a short password with symbols.
• Write the passphrase down for your successor, separately and securely. A sealed envelope with a solicitor, a note in a home safe, or split knowledge between two trusted people. The packet is useless if the passphrase dies with you — plan for its delivery just as carefully as the packet’s.
• Test the setup. Make sure your successor knows the passphrase exists and roughly where to find it, without necessarily being able to read it today.

What zero-knowledge does NOT protect

Being honest about limits is part of being trustworthy. Zero-knowledge encryption does not defend against:

• Weak passphrases. “password123” can be brute-forced regardless of how good the cipher is. The math protects strong keys, not lazy ones.
• Compromised devices. Malware or a keylogger on your computer can capture your passphrase as you type it, before encryption ever happens. Keep your devices patched and clean.
• The content of your planning. Zero-knowledge protects storage and delivery; it cannot make a badly written handover document useful. What you put in the packet still matters.

For a broader view of how Imok handles security questions, see our FAQ, and for the trigger mechanism itself, read what is a dead man’s switch.

Frequently asked questions