Client-side, end-to-end and at-rest encryption

Client-side encryption means your own device encrypts the data before sending it, with a key the server doesn't have. The server stores and forwards ciphertext and can't read it. "Encrypted" gets used for four quite different things, and the differences decide what the promise is worth. Below we define the four, say plainly which one cipher.ink is, and describe the one problem no web-based tool, ours included, can fix on its own.

Four meanings of "encrypted"

Encryption in transit

The connection between two machines is encrypted, usually with TLS (the padlock and https). It stops people on the network, such as the café Wi-Fi or your internet provider, from reading or changing what passes by. But the connection ends at the server, which receives the data in the clear. Practically every website uses it, and by itself it says nothing about what the website can see.

Encryption at rest

The server encrypts what it stores on disk, with a key the server itself holds. If the disk is stolen or thrown away, the data is unreadable. Anyone or anything with access to the running server, an administrator or an attacker who gets in, can read everything, because the key is right there. Most cloud services do this and call their data "encrypted".

Client-side encryption

The data is encrypted on the sender's device, before it's uploaded, with a key the server never receives. The server holds ciphertext only. That protects against a server breach, a rogue administrator, a subpoena for stored data (which can only produce ciphertext) and a lost backup. By itself it doesn't say how the recipient gets the key, or who the recipient is.

End-to-end encryption

Client-side encryption between specific people, where the keys belong to the two ends and are exchanged and verified between them. Each side can be confident who they're talking to and that nobody in the middle swapped a key. Signal and WhatsApp work like this: you compare "safety numbers" or a QR code to confirm you have the right keys.

The last two are often confused, and the difference is sharp. Client-side encryption answers "can the server read it?" End-to-end encryption also answers "am I sure who has the key?". What end-to-end encryption actually means takes that further.

Where cipher.ink sits

cipher.ink is client-side encryption with a shared secret. Your browser seals the message with AES-256-GCM and the server stores the sealed result. The key is either a passphrase you and the reader both know, or 256 random bits in the link's # fragment (see why the fragment never reaches the server). The server never sees the key, the message or a file name. So it can't read a message, it can't tell you what one said under any pressure, and a copy of its database, backups included, holds nothing but ciphertext.

It isn't end-to-end in the strict sense, and we don't call it that, for two reasons. First, there's no identity. Nobody has an account, so nothing says who sent a message or confirms who opened it. Anyone with the link and key is "the recipient", and the reader can't tell whether the sender is who they claim to be, which is the part safety numbers solve for Signal. Second, the shared secret has to travel by some other channel, which is exactly Alice's problem in the three-pass protocol puzzle. If the passphrase goes over the same channel as the link, the channel is the weak point and the encryption isn't. Passphrase mode asks you to say it somewhere else. A secret link carries the key inside it, so protecting the link matters.

The catch with every web-based tool

If a page's JavaScript does the encrypting, then you're trusting the server to send honest JavaScript. A hostile server, or one compelled to, could serve a page that looks the same and copies your plaintext or key before it's sealed. The encryption is real and the code is good, but the code arrives fresh from the server every time. That's true of every web-based encrypted service: webmail that encrypts in the browser, password managers' web vaults, file-sharing sites with "zero-knowledge" in their marketing. It's the main reason security researchers rank native apps with signed, reproducible builds above websites.

The CSP, the self-hosting of every script and the absence of third-party code in cipher.ink all narrow the ways this could happen, and the readable source means a change is visible to anyone who looks. None of that removes the trust. We list it as a known edge on the security page, and we say it here because an explanation of client-side encryption that left it out would be marketing.

What would reduce it

• A browser extension that pins the code. Meta and Cloudflare's Code Verify extension, built for WhatsApp Web, compares the JavaScript a page serves with a published manifest of hashes and warns if it differs. It moves the trust from "the server serves honest code today" to "the code matches what was publicly audited".
• Subresource Integrity (integrity="sha384-…" on a script tag) makes the browser refuse a script whose hash has changed. It protects against a compromised CDN, but the page carrying the tag still comes from the same server, so it can't defend against the server itself.
• Reproducible builds and transparency logs let anyone check that the published code is the code that was audited, and that everyone gets served the same version.
• A native app with a signed update, installed once, which is the model Signal uses.

We don't offer any of these today, and we're not promising to. For a tool anyone can use with no install, the browser is the delivery mechanism, and its trust model is what it is.

When client-side encryption is the right tool

It suits sending something sensitive, such as a password, a recovery code or a document, to one person through a service you don't need to trust to keep it, and which can't become a honeypot because it holds nothing readable. It also suits cases where you don't want either side to need an account. It doesn't suit long conversations (use an end-to-end messenger), proving who wrote something (use a signature) or hiding that you communicated at all. The server sees that a message of some size was stored and opened, and when.

Questions people ask

How cipher.ink uses this

Every message is encrypted in your browser with AES-256-GCM. The server stores the payload and sees only what the security page lists: the ciphertext, the mode, the expiry, sizes and timestamps, and a hash of the receipt token. The how it works page follows one message from sealing to burning. The safest way to use the service combines passphrase mode, a short expiry and burn after reading, with the passphrase told another way.