Client-Side vs Server-Side Encryption for Secret Sharing

Where the encryption happens changes who you have to trust.

Two places encryption can happen

When you paste a secret into a sharing tool and hit create, the secret gets encrypted somewhere. Either your browser encrypts it before sending (client-side), or the server encrypts it after receiving it (server-side). Both produce encrypted data at rest. The difference is who sees the plaintext along the way.

Server-side encryption

Your secret travels to the server as plain text over HTTPS. The server receives it, encrypts it for storage, and saves the ciphertext. When the recipient opens the link, the server decrypts the data and sends it back.

HTTPS protects the secret in transit. Encryption at rest protects it from someone who steals the hard drive. But the server handles the plaintext at both ends. If the server is compromised while your secret is in memory, the attacker gets the plaintext. If the operator is compelled by a legal request, they can decrypt it.

The server is the trust boundary. You're trusting the operator.

Client-side encryption

Your browser encrypts the secret before it leaves your machine. The encrypted data goes to the server. The server stores ciphertext it can't decrypt. When the recipient opens the link, their browser downloads the ciphertext and decrypts it locally.

The server never sees the plaintext. A compromised server yields only ciphertext without the key. A legal request gets the same thing. The trust boundary moves from the server to the endpoints: your browser and the recipient's browser.

The trust model difference

With server-side encryption, you're trusting the operator's infrastructure, their employees, their security practices, and their willingness to resist legal pressure.

With client-side encryption, you're trusting the code running in your browser. You can inspect that code. You can verify what it does. The server's role is reduced to storage and deletion. It handles ciphertext and metadata, never the secret itself.

Zero-knowledge architecture

Zero knowledge means the server stores your secret in encrypted form and doesn't have the key to decrypt it. It's a specific property of client-side encryption: the server knows that a secret exists, when it expires, and how many views remain. It doesn't know what the secret says.

The term is sometimes used loosely. If a tool claims zero knowledge but encrypts on the server, the claim doesn't hold, because the server saw the plaintext before encrypting it.

How Secret.Broker implements client-side encryption

Your browser generates a random 256-bit key, runs it through Argon2id key derivation, and encrypts the secret with XChaCha20-Poly1305. The ciphertext goes to the server. The key goes into the URL fragment, the part after the #. Browsers never send the fragment to the server. That's not a policy. It's how HTTP works.

The protocol page documents the full stack. The fragment security page explains why the URL fragment is safe.

Which tools use which approach

When server-side encryption is enough

Not every secret needs client-side encryption. If you trust the operator and the secret is low-value (a Wi-Fi password for a coffee shop, a temporary invite code), server-side encryption is fine. The question is whether you're comfortable with the server seeing your secret in readable form.

For passwords, API keys, SSH keys, and credentials with real consequences if leaked, client-side encryption removes the server from the threat model.

Share a Secret