Zero-Knowledge Encryption Explained

The idea

Zero-knowledge encryption is a design pattern. The service that stores your data never has the ability to read it. Not as a policy. As a technical constraint. The server receives ciphertext, stores ciphertext, and serves ciphertext. It never holds the key.

The term gets used loosely. Some services call themselves zero-knowledge but still process your data in plain text on the server before encrypting it for storage. That's server-side encryption with a trust promise, not a zero-knowledge architecture.

A genuine zero-knowledge system encrypts data on the client before it leaves the device. The server is a storage and delivery mechanism. It can be compromised, subpoenaed, or run by someone you don't trust, and the data remains unreadable.

Zero-knowledge architecture vs zero-knowledge proofs

These are related concepts that often get conflated.

Zero-knowledge proofs (ZKPs) are a cryptographic protocol. One party proves to another that a statement is true without revealing any information beyond the truth of the statement itself. ZKPs are used in blockchain privacy (zk-SNARKs, zk-STARKs), authentication systems, and verifiable computation. They are mathematically rigorous and computationally specific.

Zero-knowledge architecture is a system design pattern. The service operator has zero knowledge of the user's data because the system is designed so the server never has access to plaintext or decryption keys. It's an engineering decision about where encryption and decryption happen.

A zero-knowledge architecture doesn't necessarily use zero-knowledge proofs. And a system that uses zero-knowledge proofs isn't necessarily zero-knowledge in its data handling. They solve different problems.

How it works in practice

The pattern has three parts:

• Client-side encryption. The user's device encrypts data before sending it to the server. The encryption key is generated locally.
• Key separation. The decryption key is never transmitted to the server. It stays with the user or is transmitted through a channel the server doesn't control.
• Server as blind storage. The server stores encrypted blobs. It can enforce access rules (expiry, view limits) on the blob, but it cannot read or modify the contents.

The critical property: even if the server is fully compromised, the attacker gets ciphertext without the key to open it.

Why it matters for secret sharing

When you share a password, an API key, or a private document through a service, you're trusting that service with the contents. Most secret-sharing tools use server-side encryption: your secret arrives at the server in readable form, gets encrypted for storage, and is decrypted again for the recipient. The server handles the plain text twice.

With zero-knowledge architecture, the trust model changes. You're trusting the service to store and deliver bytes reliably. You're not trusting it to keep your secrets secret, because it can't read them regardless of intent.

This distinction matters when:

• The service is breached and its database is exfiltrated.
• The service is served with a legal order to produce user data.
• An insider with database access is curious or malicious.
• The service changes ownership or terms of service.

In all four scenarios, a zero-knowledge architecture means the data is still encrypted and the service genuinely cannot comply with a request to reveal it.

How Secret.Broker implements it

Your browser encrypts the secret using XChaCha20-Poly1305 before anything is sent to the server. The encryption key goes into the URL fragment (the part after the #), which browsers never include in HTTP requests. The server receives and stores only ciphertext.

When the recipient opens the link, their browser downloads the ciphertext and reads the key from the fragment. Decryption happens locally. The server serves encrypted bytes and never sees the key that opens them.

The protocol page documents the full encryption stack: key derivation with Argon2id, domain binding, the binary payload format, and memory handling.

What zero-knowledge doesn't protect against

Zero-knowledge encryption protects data at rest and from the server operator. It doesn't address every threat:

• Compromised endpoints. If the sender's or recipient's device is compromised, the attacker can read the secret after decryption. Encryption protects data in transit and storage, not on a compromised machine.
• Link interception. If someone intercepts the full link (including the fragment), they can decrypt the secret. Paranoid mode mitigates this by splitting the link and the key across separate channels.
• Malicious client code. If the service serves tampered JavaScript that exfiltrates the key before encrypting, the zero-knowledge property breaks. This is why open-source clients and reproducible builds matter.

Zero-knowledge is one layer in a defence-in-depth strategy. It's a strong layer, but it's not the only one.