How zero-knowledge delivery actually works

Inktally is built on a simple, uncompromising promise: we cannot read your vault. Your documents are encrypted on your device, with a key derived from a password we never receive. The opaque bytes that reach our servers are useless to us, to an attacker who breaches us, and to anyone who serves us a subpoena.

That promise raises an obvious question — one we get in nearly every security review: if you can't read it, how does my sister ever receive it? The honest answer is more interesting than "we just send it," and understanding it is the key to trusting the whole system.

The problem with “automatic” delivery

Most digital-legacy products quietly hold a copy of your key, or can re-derive it. That is what makes their “we'll email it to your loved ones automatically” flow possible. It is also the thing that breaks zero-knowledge: if a server can produce your plaintext at release time, it could produce it any time.

We refuse that trade. So delivery, for us, is never the server waving a wand. It is a re-wrap: someone who holds a key re-seals your data to your recipient's key. The whole design question is who that someone is, and how little they have to be trusted.

If a server can hand over your plaintext at release time, it can hand it over at any time. Zero-knowledge means designing delivery so that never becomes possible.

Key wrapping, briefly

Every document in your vault is encrypted with its own random data key. That data key is then “wrapped” (encrypted) to each party who should be able to open it — including you. Wrapping is cheap; the document itself is encrypted once.

When you add your sister as a recipient, Inktally wraps the relevant data keys to her public key. Her private key never leaves her device, and ours never touches it.

What the server actually stores

For each shared item, the server holds the ciphertext and a small set of wrapped keys. None of them open without a private key the server does not have. You can read every byte of that record and learn nothing about the document. That is the point.

The re-wrap at release time

When your release condition fires — a date, an inactivity window, a manual trigger — the wrapped key still needs to be handed to your recipient in a form her device can open. Two honest models exist, and Inktally lets you choose:

Mode A — Inktally-assisted

You authorize Inktally to hold a temporary, release-scoped wrapping key. When the condition fires, our service uses it to re-wrap the data keys to your recipient. It is faster and needs no third party — but for the release window, we hold a key. We are explicit about that trade in the UI.

Mode B — Executor-held

You name an executor — your lawyer, a trusted friend. We store only sealed bytes; their device performs the re-wrap when they sign in after the condition fires. We never hold a key that opens anything. This is the mode we recommend for high-sensitivity vaults.

The cooling-off window

Both modes wrap the re-wrap in a cooling-off period. When a condition fires, you and any recovery contacts are notified, and nothing is delivered until the window elapses. A missed check-in during a holiday never becomes an irreversible release.

• You can cancel the release during the window with a single sign-in.
• Recovery contacts can flag a false alarm.
• Every step is written to the tamper-evident audit log.

What your recipient finally receives

After the window, the re-wrap completes and your recipient gets a plain email. They open what you left them — the documents, your note — with the keypair tied to their access. No app to evaluate under stress, no new account to create in a hard moment. They simply get access to what was always meant for them.

That is zero-knowledge delivery: not magic, not a backdoor, but a careful chain of wrapped keys that puts the decision — and the trust — exactly where you chose to place it.