Zero Knowledge Encryption: What It Actually Means, What It Doesn't, and Where It Breaks

Zero knowledge encryption is one of those terms that sounds precise but isn't. It describes a real architectural pattern (the service provider holds ciphertext and never possesses the decryption keys), yet it has no formal cryptographic definition. It is, simultaneously, a legitimate engineering goal and a marketing label. This piece breaks down how it works in practice, where it recently failed in spectacular fashion, and why the term keeps getting conflated with something else entirely.

Key Takeaways

• Zero-knowledge encryption means the provider stores only ciphertext and never holds your keys. Encryption and decryption happen on your device, before data leaves it.
• A February 2026 study from ETH Zurich documented 27 successful attacks against major password managers that market zero-knowledge encryption, exposing a gap between the claim and the implementation.
• The attacks exploited a "malicious server" threat model, not a break in the underlying cryptography. If the server is honest, your data is fine. If it isn't, current implementations often fail to protect you.
• "Zero-knowledge encryption" and "zero-knowledge proofs" are unrelated concepts that share a name. One is about key custody. The other is a mathematical proof system now being explored for verifiable AI inference.
• The label matters less than the implementation. Unauthenticated public keys, missing ciphertext integrity checks, and poor key separation are the specific anti-patterns that turn a strong claim into a weak guarantee.

What Is Zero-Knowledge Encryption?

It is a design pattern where the service provider never has access to your plaintext data or the keys that would decrypt it. Files are encrypted on your device before upload. Keys are derived from your password locally, never transmitted to the server. The provider stores only meaningless ciphertext. Even under a subpoena or after a breach, there is nothing readable to hand over.

The term itself is intuitive: the provider has "zero knowledge" of your data. But as a cryptographic standard, it doesn't exist. There is no RFC, no NIST publication, no formal specification that defines what a product must do to earn the label. Researchers at ETH Zurich and USI pointed this out explicitly in February 2026: "zero-knowledge encryption" is a marketing term, not a cryptographic standard. This distinction matters more than most vendors would like.

How Does Zero-Knowledge Encryption Actually Work?

The core mechanism is client-side encryption with local key derivation. Here's the typical flow:

1. You enter a password on your device.
2. A key derivation function (usually Argon2, PBKDF2, or scrypt) stretches that password into a symmetric encryption key. This happens locally.
3. Your data is encrypted with that key (AES-256 is common) before it leaves your device.
4. The encrypted blob is sent to the server for storage.
5. The server never sees the password, never sees the derived key, and never sees the plaintext.

When you retrieve data, the process reverses. The server sends ciphertext back, your device derives the same key from your password, and decryption happens locally. The provider is a dumb pipe with a storage backend. That's the theory.

In practice, the implementation details determine whether the zero-knowledge claim holds. And as recent research demonstrated, those details are where things go wrong.

What Did the ETH Zurich Research Find?

In February 2026, researchers from ETH Zurich and USI published a paper titled "Zero Knowledge (About) Encryption" that systematically analyzed the cryptographic architectures of three major cloud-based password managers: Bitwarden, LastPass, and Dashlane. The title is a pun, and it's deserved.

They developed 27 successful attack scenarios across these products, with additional results on 1Password. The attacks ranged from integrity violations of targeted vaults to complete compromise of all vaults associated with an organization. The majority of the attacks allowed recovery of users' plaintext passwords.

These are not niche products. The three services collectively serve over 60 million users and hold roughly 23% of the password manager market.

The paper is set for live presentation at USENIX Security 2026 in Baltimore this August.

What Specific Flaws Did They Exploit?

The researchers operated under a "malicious server" threat model. This is critical: they did not break AES-256 or find a flaw in the key derivation. They assumed the server itself could be compromised or act maliciously, which is exactly the scenario zero-knowledge encryption is supposed to protect against.

The specific anti-patterns they exploited included:

• Unauthenticated public keys. If the server can substitute its own public key for yours without detection, it can intercept data you encrypt "for yourself."
• Missing ciphertext integrity. Without authenticated encryption or integrity checks, an attacker who controls the server can modify ciphertext in ways that leak information when the client decrypts it.
• Insufficient key separation. When the same key material is reused across different operations (authentication vs. encryption vs. sharing), a compromise in one context can cascade.
• Missing cryptographic binding between data and metadata. If the server can rearrange which metadata maps to which encrypted blob, it can trick the client into revealing plaintext through oracle-style attacks.

Each of these is a known anti-pattern. None of them are novel in isolation. What's notable is that all three major vendors shipped products with multiple instances of these flaws while marketing zero-knowledge encryption as a headline security feature.

Are Password Managers Still Safe to Use?

Yes, with a caveat. The researchers confirmed that passwords remain safe as long as providers are not actively compromised or acting maliciously. Against passive threats (someone steals the database), the encryption holds. The risk is specifically an actively malicious or compromised server.

All three vendors confirmed that remediation is underway following a coordinated 90-day disclosure process. LastPass publicly responded, stating that their "own assessment of these risks may not fully align with the severity ratings assigned by the ETH Zürich team" and that they had "already implemented multiple near-term hardening measures."

The lead researcher's recommendation was straightforward: providers should "not make false promises to their customers about security but instead communicate more clearly and precisely what security guarantees their solutions actually offer."

Hard to argue with that.

Why the Term "Zero-Knowledge Encryption" Is Misleading

Two reasons, one philosophical and one practical.

The philosophical problem: the term borrows credibility from "zero-knowledge proofs," which is a rigorous, well-defined concept in cryptography with decades of peer-reviewed literature. A zero-knowledge proof lets one party prove to another that a statement is true without revealing any information beyond the truth of the statement itself. It has a formal mathematical definition. "Zero-knowledge encryption" does not. The name implies a level of rigor that the implementations don't earn.

The practical problem: the label encourages a false binary. Either the provider knows your data or it doesn't. In practice, the question is more nuanced. Does the provider hold authenticated keys? Can it modify ciphertext? Can it observe access patterns? Can it inject code into the client? Each of these represents a different boundary, and "zero-knowledge" flattens them all into a single marketing claim.

A more honest framing would specify the threat model. "We cannot read your data assuming our servers are not compromised and we do not push a malicious client update" is accurate for most implementations. It is also a much less compelling tagline.

How Is Zero-Knowledge Encryption Different from End-to-End Encryption?

They overlap but aren't identical. End-to-end encryption (E2EE) means data is encrypted on one endpoint and decrypted only on another endpoint, with no intermediary able to access the plaintext. It is most commonly discussed in the context of communication (messaging, file transfer).

Zero-knowledge encryption is a broader claim about the provider's relationship to your data. It encompasses E2EE but adds the assertion that the provider has no knowledge of the keys, and therefore no ability to decrypt, under any circumstances. Bitwarden describes them as complementary concepts: E2EE protects data in transit, while zero-knowledge describes the provider's inability to access data at rest.

In practice, if your files are encrypted client-side before upload and the provider never holds the keys, you have both E2EE (the transit path carries only ciphertext) and a zero-knowledge architecture (the provider stores only ciphertext). The distinction matters mainly when one holds but the other doesn't. A service could use E2EE for transit but hold a copy of your key server-side, for example. That would be E2EE but not zero-knowledge.

Where Does Zero-Knowledge Encryption Apply Beyond Password Managers?

Cloud storage is the most common application. Services that offer zero-knowledge cloud storage encrypt your files on your device before upload, and the storage provider holds only ciphertext. If the provider's servers are seized or breached, the attacker gets encrypted blobs with no keys.

Encrypted messaging, file transfer, and backup services use similar architectures. The common thread is that the user's device is the trust boundary. Everything outside the device boundary (the network, the server, the provider's employees) is untrusted by design.

At Selina, we apply this architecture to files and transfers. SelinaSEND uses zero-knowledge encryption for file transfers: files are encrypted client-side, and we never hold the keys. Memory is a different story. Because each request reaches a frontier provider at inference, memory is encrypted at rest but is not end-to-end encrypted. We state this clearly because the distinction matters.

What Are Zero-Knowledge Proofs, and Why Do People Confuse Them with Zero-Knowledge Encryption?

Zero-knowledge proofs (ZKPs) are a mathematical protocol that lets one party (the prover) convince another party (the verifier) that a statement is true without revealing anything beyond the truth of that statement. The concept was formalized by Goldwasser, Micali, and Rackoff in 1985. It is one of the foundational results in cryptographic theory.

People confuse the two because they share the phrase "zero knowledge." That's it. The similarity ends at the name.

Zero-knowledge encryption is about key custody: who holds the decryption keys. Zero-knowledge proofs are about information revelation: proving you know something without showing what you know. They solve different problems, use different mathematics, and operate in different contexts.

The confusion is getting worse, not better. Crypto and Web3 marketing frequently refers to "ZK" projects that use zero-knowledge proofs for on-chain privacy or transaction validation, and the same term is applied to cloud storage and password managers that use client-side encryption. A reader searching for "zero knowledge" can land on either meaning and come away more confused.

How Are Zero-Knowledge Proofs Being Applied to AI?

This is where it gets interesting and where the two concepts are most often conflated.

Zero-knowledge proofs are being explored as a mechanism for verifiable AI inference. The idea: an AI model can prove it ran a specific computation correctly (and on specific inputs) without revealing its weights, training data, or the user's query. Frameworks like zk-SNARKs and trusted execution environments (TEEs) are the building blocks.

A 2026 Springer survey confirms that zero-knowledge proof based verifiable machine learning (sometimes called ZKML) is a growing academic research area. The promise is compelling: you could verify that an AI model produced a specific output from a specific input, without the model operator revealing proprietary parameters and without the user revealing private data.

The problem is performance. Current implementations require minutes of proving time per query. One system is reported to be thousands of times slower than plain inference. For an AI agent that needs sub-second responses, this is prohibitive. The research is active, the math is sound, and the engineering is years away from production use in real-time systems.

A practical middle ground is emerging: hybrid approaches that combine TEEs for hardware-level isolation with selective ZKP-based verification for high-stakes outputs. This avoids the latency penalty for routine queries while providing cryptographic guarantees where they matter most.

What Should You Look for in a Zero-Knowledge Encryption Implementation?

Given that the term itself is not a standard, you have to evaluate implementations on their own merits. The ETH Zurich research provides a useful checklist of what to look for (and what to worry about).

Authenticated key exchange. Public keys used for sharing or encrypting data must be authenticated. If the server can substitute keys without detection, the zero-knowledge claim collapses. Look for key pinning, out-of-band verification, or transparency logs.

Authenticated encryption. Ciphertext should include integrity checks (AES-GCM, ChaCha20-Poly1305, or similar AEAD schemes). If ciphertext can be modified without detection, an attacker can mount chosen-ciphertext attacks. This is basic, and the fact that major vendors shipped without it is notable.

Key separation. Different keys for different purposes. Authentication keys should not double as encryption keys. Sharing keys should not be derivable from vault keys. Key reuse across contexts is a consistent source of vulnerabilities.

Cryptographic binding. Metadata (item names, folder structures, sharing permissions) should be cryptographically bound to the encrypted data it describes. Without this binding, the server can rearrange associations and exploit the client as a decryption oracle.

Open-source client code. If the client is closed-source, you are trusting the vendor's implementation without the ability to verify it. Open-source clients can be audited by third parties and the broader security community. This is not a guarantee (Bitwarden is open-source and was still vulnerable), but it is a necessary condition for trust.

Threat model transparency. The vendor should explicitly state what threats the architecture protects against and what it does not. "We protect against a passive server compromise but not against a malicious server pushing a modified client" is honest. "Zero-knowledge encryption protects your data" is not.

Does Zero-Knowledge Encryption Protect Against All Threats?

No. It protects against a specific class of threats: unauthorized access to stored data by the provider, its employees, or anyone who compromises the server and obtains the stored ciphertext.

It does not protect against:

• A compromised client application (if the provider pushes a malicious update to the app on your device, it can capture your password or keys before encryption occurs).
• A malicious server that actively manipulates protocol flows, as the ETH Zurich research demonstrated.
• Weak or reused passwords. If your master password is "password123," the key derived from it is trivially brute-forceable regardless of the architecture.
• Side-channel attacks on the client device itself (keyloggers, screen capture, memory dumps).
• Metadata leakage. Even if file contents are encrypted, the server typically knows file sizes, access times, sharing relationships, and folder structures. This metadata can reveal a lot.

The ETH Zurich researchers framed their findings carefully: the encryption primitives themselves are sound. AES-256 is not broken. The key derivation functions are not broken. The failures are in how the primitives are composed into a system, and in what happens when you stop assuming the server is honest.

How Should Vendors Communicate Zero-Knowledge Claims?

Precisely and with stated threat models. "Your data is encrypted with keys we never hold" is accurate for most implementations. "Your data is protected even if we are compromised" is a stronger claim that, as the ETH Zurich research showed, many implementations cannot actually support.

The gap between the marketing claim and the engineering reality is the problem. Not because the engineering is bad (though in some cases it was), but because the marketing creates expectations the architecture was never designed to meet. A service that protects against passive breaches but not against an actively malicious server is still valuable. But it should say that.

Zero-knowledge encryption as an architectural pattern remains the right approach for services that handle sensitive user data. The alternative, where the provider holds decryption keys and pinky-swears not to use them, is worse by every measure. But "zero-knowledge" should be a description of an implementation's properties, verified by audit and tested against realistic threat models. Not a badge you slap on because your marketing team liked how it sounded.

Where Does This Leave Us?

Zero-knowledge encryption is a useful concept with a real engineering definition: the provider stores ciphertext and never holds the keys. It is also a term with no formal standard, applied loosely by vendors, and recently shown to be poorly implemented in products used by tens of millions of people.

The cryptographic primitives are fine. AES-256 is not the problem. The composition of those primitives into real systems, under realistic threat models, is where implementations fail. Unauthenticated keys, missing integrity checks, poor key separation. These are well-understood anti-patterns, and the fact that they appeared in mainstream products in 2026 says something about the gap between marketing claims and security engineering.

If you build or use systems that claim zero-knowledge encryption, the ETH Zurich paper is required reading. Not because it breaks the concept, but because it shows what the concept actually requires to hold up.

If you want to see how we approach privacy in an AI assistant (where some data necessarily reaches a model provider at inference and the zero-knowledge label does not apply to everything), start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io