Zero-knowledge encryption means the service storing your data cannot read it. Not “won’t.” Cannot. Your data gets encrypted on your device before it ever leaves, and the keys stay with you. The server only ever sees encrypted gibberish.
So what does “zero-knowledge” actually mean?
When a service says it has “zero-knowledge encryption,” it means one specific thing: the company running the service has zero knowledge of what’s in your data. They can’t see it. They can’t decrypt it. They don’t have the keys.
This isn’t a policy decision, it’s not “we promise not to look at your files.” It’s a technical architecture where looking is impossible. The company doesn’t have the mathematical ability to turn your encrypted data back into readable form. Even if they wanted to. Even if a court ordered them to. Even if someone broke into their servers and stole every database they have.
That last part is the one that really counts. Breaches happen. Servers get compromised. Employees go rogue. Governments issue subpoenas. In a zero-knowledge system, none of that exposes your actual data. An attacker who gets everything the server has gets a pile of encrypted blobs, useless without your key.
Quick terminology note: “zero-knowledge proofs” are a related but different concept (a way to prove you know something without revealing what you know). When people talk about “zero-knowledge encryption” or “zero-knowledge architecture” in the context of apps and services, they mean this: the service provider knows nothing about your data.
The simple version
Think of a storage unit facility. You rent a unit, put your valuables inside, and lock it with your own padlock. The storage company holds the building. They can walk right up to your unit. But they don’t have the key to your padlock. If someone breaks into the facility, they find a locked unit they can’t open. If the storage company gets a court order, they can hand over the unit, but what’s inside is still locked.
That’s zero-knowledge in a nutshell. The service holds the container. You hold the only key.
We hold the container; you hold the only key. Trust isn't optional it's irrelevant.
The non-zero-knowledge version? The storage company puts their own lock on your unit and gives you a copy of the key. Sure, you can get in. But so can they. And anyone who compromises the storage company’s master key ring gets into every unit in the building.
Most cloud services work like that second version. The company encrypts your data, but they hold the encryption keys. They encrypt it “at rest” and “in transit,” which protects against certain attacks, but not against the company itself, its employees, or anyone who compromises their key infrastructure.
How it works (without the math)
Here’s the flow. You create an account on a zero-knowledge service. During setup, a cryptographic key is generated on your device. This key might come from a password you choose, a recovery phrase the app generates, or some combination. The part that matters: this key is created and stored locally. It never gets sent to the server.
When you store data, encryption happens on your device before anything leaves. Your phone takes the plaintext, encrypts it using your local key, and sends the encrypted result to the server. The server stores that encrypted blob. It has no idea what’s inside.
# Setup: key is generated and kept on the device. const key = derive(passphrase) // stays local
# Store: encrypt locally, upload only ciphertext. const blob = encrypt(plaintext, key) upload(blob) → “server sees gibberish”
# Read: server returns the same blob; phone decrypts. const plain = decrypt(download(), key)
Retrieval is the reverse. The server sends the encrypted blob back to your device. Your device decrypts it locally using the key that never left.
The server’s role is storage and delivery, it holds encrypted data and moves it around, but it never has what it would need to make sense of any of it. Compare that to traditional encryption where the server handles both encryption and key management, meaning the server (and anyone who compromises it) can read your data at any time.
There’s a real trade-off, though. Because the service doesn’t have your key, it can’t help you if you lose it. There’s no “forgot my password” flow that restores access to your encrypted data. If your key is gone, your data is gone. That’s not a bug, it’s the mathematical consequence of the architecture working correctly.
Who uses zero-knowledge encryption
Zero-knowledge architecture isn’t new or exotic. Some of the most respected security tools are built on it.
Signal encrypts messages end-to-end. Signal’s servers relay encrypted messages but can’t read them. When the FBI has served warrants to Signal, the company has handed over essentially nothing useful, because they don’t have anything useful.
Proton Mail applies the same idea to email. Your inbox is encrypted with keys derived from your password, which Proton never sees. Their transparency reports show exactly how little data they can provide in response to legal requests.
1Password and Bitwarden are both zero-knowledge password managers. Your vault is encrypted locally with a key derived from your master password. The companies store encrypted vaults but can’t decrypt them.
AbsentKey uses zero-knowledge encryption for secret sharing. Your secrets are encrypted on your phone before they’re uploaded. The server stores encrypted blobs. AbsentKey can’t read what you’ve stored, either.
“Encrypted” by itself does not tell you much. The question that matters: who holds the keys? Until 2024, Google Drive encrypted files on its servers while Google held the keys. That encryption protected against external attackers but not against Google itself.
Not every service advertising “encryption” is zero-knowledge, though. For years, Google Drive encrypted files on their servers while Google held the keys. They could (and did) access the contents. That encryption protected against external attackers but not against Google itself.
The word “encrypted” by itself doesn’t tell you much. The question that matters: who holds the keys?
How AbsentKey uses zero-knowledge encryption
AbsentKey was built from the ground up as a zero-knowledge system. (For a deeper look at the full security model, see Is AbsentKey Safe?) Here’s what that looks like in practice.
When you create an account, the app generates a 12-word recovery phrase on your device. This phrase is your master key. It never leaves your phone, never sent to AbsentKey’s servers. It exists on your device and anywhere you choose to back it up.
From that 12-word phrase, AbsentKey derives your encryption keys using HKDF-SHA256, a standard key derivation function. This gives the app the cryptographic material it needs to encrypt and decrypt your data, all derived from that single phrase.
When you create a secret, the app encrypts it on your device using XSalsa20-Poly1305, an authenticated encryption algorithm from the NaCl/libsodium family. “Authenticated” here means the encryption doesn’t just hide the data, it also guarantees nothing’s been tampered with. If someone modifies even a single bit of the encrypted blob, decryption fails rather than returning corrupted data.
Sharing a secret with someone? AbsentKey uses X25519 key exchange (Diffie-Hellman on Curve25519), which lets two people derive a shared secret without either one sending their private key over the network. Your device and the recipient’s device agree on a shared encryption key through math. The server facilitates the exchange but never learns the shared key.
The result: AbsentKey’s servers store encrypted blobs and manage access control metadata (who can request what, what timers are set). But they never see the actual contents of any secret. They can’t. They don’t have the keys.
The mobile client is source-available on GitHub, so you can read the encryption code yourself and confirm plaintext never hits the network.
Why this matters for secret sharing
Think about what people share through services like AbsentKey as part of their digital legacy plan. Passwords to bank accounts. Cryptocurrency seed phrases worth real money. Business credentials. The kind of information where a breach doesn’t just mean inconvenience, it means financial loss, identity theft, or worse.
Now imagine sharing that through a service that can read it. You’re trusting every employee with database access. You’re trusting their security team to never make a mistake. You’re trusting that no government will ever compel them to hand over data. You’re trusting no attacker will ever breach their infrastructure.
That’s a lot of trust for a service holding your most sensitive information.
Zero-knowledge flips that equation. The cryptography makes the service’s trustworthiness irrelevant to the security of your data. If AbsentKey’s servers were completely compromised tomorrow, the attacker would get encrypted blobs, computationally infeasible to decrypt without the keys that only exist on users’ devices.
If you’re putting your master passwords or recovery phrases into a sharing service to prepare your digital legacy, that service better not be able to read them. “Trust us” doesn’t cut it when the data is that sensitive. “We literally can’t” is the only acceptable answer.
FAQ
Can zero-knowledge services recover my data if I lose my password?
No. That’s the trade-off. The service doesn’t have your encryption keys, so there’s no “reset password” mechanism that restores access to encrypted data. If you lose your key, your data is permanently inaccessible. This is why services like AbsentKey generate a 12-word recovery phrase and ask you to write it down somewhere safe. The service can’t help you because it never had the ability to decrypt your data in the first place.
Is zero-knowledge encryption the same as end-to-end encryption?
Closely related but not identical. End-to-end encryption (E2EE) means data is encrypted on the sender’s device and only decrypted on the recipient’s device. Zero-knowledge is a broader architectural principle, the service provider has no knowledge of user data. Most zero-knowledge services use E2EE as part of their implementation, but you can have E2EE without full zero-knowledge (if the service still collects certain metadata), and zero-knowledge storage without the “end-to-end” framing (a personal vault with no sharing). When a service is both, that’s the strongest combination.
What happens if I lose my recovery phrase in AbsentKey?
If you lose your 12-word recovery phrase and also lose access to your device, your secrets are permanently locked. AbsentKey can’t recover them. This isn’t a limitation specific to AbsentKey, it’s a fundamental property of zero-knowledge systems. The recovery phrase is the root from which all your encryption keys are derived. Without it, the math doesn’t work. That’s why AbsentKey prompts you to write it down during setup and store it somewhere separate from your device.
Encryption that doesn’t require trust
The whole point of zero-knowledge encryption is removing trust from the equation. You don’t have to trust the company, their employees, or their server security. The math handles it.
If you’re going to share sensitive information through any service, make sure that service can’t read what you’re sharing. Not “promises not to.” Can’t.
AbsentKey is built on that principle. Your secrets are encrypted on your phone with keys that never leave your phone. The server stores data it can’t decrypt. Nobody can read your secrets except the people you choose to share them with.
Download AbsentKey, free to receive, available on iOS and Android.
