What Does Zero Knowledge Encryption Mean for Your Notes

2026-09-11 · Yesterself

Somewhere there is a notebook nobody has read. If you lose it, it is gone. There is no support line, no reset link, no employee who can look inside on your behalf. That is the standard paper sets without trying, and most software quietly fails to match it.

Zero knowledge encryption is the phrase the software industry reaches for when it wants to claim the notebook standard. It is worth knowing what the phrase actually covers, because it gets used loosely, and because the version that is real comes with a cost the marketing page tends to mention last.

The short answer

Zero knowledge encryption means the company running the service stores your content in a locked form and holds nothing that can unlock it. The key was made on your device, out of something only you have, and it did not travel to their servers.

The practical consequence is what matters. The company can hand your data to someone else — an attacker who breaches them, a government with a valid order, whoever buys the company in three years — and what gets handed over is a locked box.

One note on the term itself. A "zero-knowledge proof" is a specific idea in cryptography: proving you know something without revealing what it is. The marketing phrase borrowed those words and loosened them. In product copy, "zero knowledge encryption" usually means "we cannot read customer content." That may well be true. It is a claim about architecture, and you check it the way you check any architecture claim: by asking what the system would have to be capable of, and whether it is.

Four phrases that sound alike and are not

• Encrypted in transit. The connection is protected while data travels. This says nothing about what happens when it arrives.
• Encrypted at rest. Data sits encrypted on the provider's disks, with the provider holding the key. It defends against a drive stolen from a data center. It does not defend against the provider, its staff, or anyone in a position to compel it.
• End-to-end encrypted. Encryption happens on your device and decryption happens on the other end's device. The provider carries ciphertext. In a journal, both ends are you.
• Zero knowledge. End-to-end, plus the claim that the provider holds no key material capable of recovering your content — no copy of your password, and no way around it.

Nearly every service can honestly say the first two. Far fewer can say the fourth.

How a key gets made without the company seeing it

Two shapes are common, and both are simpler than they sound.

1. A passphrase you choose. It is run through a key derivation function on your device — Argon2, scrypt and PBKDF2 are names you will see — which is deliberately slow, so that guessing is expensive. The passphrase itself stays on the device.
2. A random key generated on your device, then shown to you as a list of ordinary words. Twelve or twenty-four words drawn from a standard vocabulary, often the BIP39 word list, is the usual form. The words are the key, written so a human can copy it onto paper.

Either way the secret is born on your hardware and stays there. That is the whole mechanism. Everything else — the audits, the diagrams, the badge on the pricing page — is commentary on that one fact.

Why this is architecture and not a promise

A privacy policy is prose, and prose changes. New ownership, new terms, a new jurisdiction, a new business model that suddenly finds your writing interesting. A promise not to look is only as durable as the people making it and the pressure they are under.

A design constraint behaves differently. If the server holds ciphertext and no key, then "please look" is not an instruction anyone there can carry out. The question stops being whether they would and becomes whether they could.

That is a real difference, and it still deserves three caveats:

• It narrows what can go wrong; it does not remove risk. Implementation bugs, weak passphrases, and a compromised laptop are all still live.
• Metadata usually survives. Timestamps, how often you write, how large the uploads are, IP addresses, payment records. Encrypting content does not hide the shape of your usage.
• How the code reaches you matters. If the client is a web page fetched fresh on every visit, you are trusting whatever code was shipped today. A signed app you installed, plus outside review, narrows that gap without closing it entirely.

Questions that separate a real claim from a slogan

1. If I forget my password, can you restore my data? If the answer is yes, they hold a key. Everything after that is a detail.
2. Where is the key generated, and what leaves my device?
3. What can you produce in response to a legal request? A transparency page that answers plainly is a good sign.
4. Can I export everything, in an open format, at no cost, including on the free plan?
5. Has anyone outside the company looked at the code or the cryptography?

The tradeoff you cannot design away

Here it is, without softening. There is no password reset. There is no support agent who can rescue you. If the key is gone, the archive is unreadable — by you, and by them.

This is not an oversight anyone is working to fix. A door built for the forgetful reader is a door, and it can be opened by whoever else finds it or demands it. The recovery feature you want on a bad Tuesday is the same feature you did not want when you chose the product.

Middle grounds exist, and each one trades something away: escrowing a recovery key with the provider restores rescue and restores their access; splitting a phrase among trusted people adds coordination; a printed copy in a safe deposit box is strong against hackers and weak against a house fire you did not plan for.

Practical handling, roughly in the order people wish they had done it:

• Write the phrase on paper. Not a screenshot in a photo library that syncs somewhere else.
• Keep two copies in two places, one of them away from home.
• Test recovery once, early, while the archive is small enough that losing it would not hurt.
• Keep exports. Encryption protects your writing from being read; exports protect it from being lost. They are different problems.
• Decide on purpose what happens to it when you die. A phrase nobody else can reach is also a phrase nobody else can inherit, and that is its own tangle. This is not legal advice; if an estate is involved, talk to someone who does that work.

Where this leaves a journal

Yesterself is a journaling app built this way, which is why the tradeoff above is not abstract to us. There is no account, no email address, no password. The identity is twelve words you hold. The server stores ciphertext it cannot read, and nothing is used to train anything. Export is free forever, on the free tier too, in open formats.

And the cost is exactly the cost described here: if the twelve words are gone, the writing does not come back, and we cannot bring it back. We are not planning to solve that, because solving it would mean holding a key. The app is not released yet, so there is nothing to install; a waiting list on the site is the only thing there is to join.

Whatever you end up using, ask the reset question first. It takes one sentence, and the answer tells you most of what the rest of the page is trying to say.

Common questions

What does zero knowledge encryption mean in plain terms?

It means the service stores your content in a locked form and does not hold the key, because the key was created on your device and stayed there. The provider can hand the data to anyone and it remains unreadable without your key.

Is zero knowledge the same as end-to-end encryption?

They overlap. End-to-end describes where encryption and decryption happen, while zero knowledge is the further claim that the provider holds no key material capable of recovering your content, including no copy of or backdoor around your password.

What happens if I forget my password or lose my recovery phrase?

In a genuine zero knowledge system the data stays locked and support cannot recover it. Keep an offline copy of the phrase in two separate places, and keep exports of anything you would hate to lose.

Can a zero knowledge provider still see anything about me?

Usually yes, in the form of metadata: when you connect, how often, how large your uploads are, your IP address, and payment details if you pay. Encrypting content does not hide the shape of your usage.

How can I tell whether a company's zero knowledge claim is real?

Ask whether they can reset your password and restore your data; a yes means they hold a key. Then check where the key is generated, whether outside reviewers have examined the code, and whether you can export everything in an open format.