Client-Side vs Server-Side Encryption, and Zero-Knowledge

“Encrypted” on a product page can mean three different things, and they stack rather than compete:

• Encryption in transit protects the connection between your device and the service, almost always with TLS. It ends at the server, which decrypts the stream to process it. The end-to-end encryption vs TLS article covers where that boundary sits.
• Encryption at rest (server-side) encrypts data before it is written to the provider's disks and decrypts it when it is read back. It is now a baseline: Amazon S3, for example, has encrypted every new object upload by default since 5 January 2023, according to its documentation.
• Client-side encryption happens on your device, before upload, under keys you control. When the recipient's device is the only other holder of the key, this is end-to-end encryption.

The algorithm is usually the same in all three (AES-GCM is the common choice; see how AES-256-GCM works). What differs is where the key lives and which software can use it. A file encrypted at rest with AES-256 and decrypted on demand by the provider's application is, from the provider's point of view, a readable file.

Cloud storage services expose these as explicit options, which makes them a useful map. Using S3's names as the example (other providers have equivalents):

Provider-managed keys

The provider generates, stores and rotates the keys, and its storage service decrypts transparently for any authorised request (SSE-S3 in AWS terms). You get protection for decommissioned drives and stolen media with no effort, and nothing else: anyone the service treats as authorised reads plaintext.

Customer-managed keys in the provider's KMS

Data keys are wrapped by a key-encryption key held in the provider's key management service, under a policy you write (SSE-KMS). You gain access control, an audit log of every decryption and the ability to disable or delete the key, which makes the data unreadable. The provider's software still performs the decryption, and the KMS still belongs to the provider.

Customer-provided keys per request

With SSE-C you send the key over HTTPS with every request; S3 uses it to encrypt or decrypt and, per AWS, never stores it. The plaintext and the key are still present on the provider's servers during each request, so this is still server-side encryption. AWS has disabled it by default for new general purpose buckets since April 2026, steering customers to SSE-KMS.

Client-side keys

You encrypt before upload and the provider stores bytes it cannot interpret. In AWS's words, you then “manage the encryption process, encryption keys, and related tools”. Every convenience that needs to read the file moves to your devices or disappears.

Most real deployments use envelope encryption in all four models: a random data key per object, itself encrypted by a longer-lived key-encryption key. The question is only where that outer key lives. The OWASP cryptographic storage cheat sheet describes the pattern and the key-management processes around it.

Two patterns stand out. Server-side encryption, however the keys are managed, never protects against someone who can act as the service, because the service's job is to decrypt for authorised callers. And client-side encryption moves the risk to the endpoints and to key loss: it turns “the provider might read this” into “you might lose this”.

In cryptography, a zero-knowledge proof is a protocol that convinces a verifier a statement is true while revealing nothing else, such as proving you know a password without sending it. Storage marketing uses “zero-knowledge” for something unrelated: the provider claims it cannot read your files. Some products that use the term do employ zero-knowledge protocols for login; most simply mean client-side encryption.

As a claim about files, it should be held to these tests:

1. Keys are generated on your devices, and neither the keys nor your password (only a proof of it) reach the server.
2. The provider cannot reset your password and hand back your files.
3. File and folder names are encrypted, not only file contents.
4. Sharing with another person does not route a usable key through the server, or if public keys are fetched from the server, they can be verified.
5. The design holds against an actively malicious server, not just a curious one: a server that swaps keys, replays old ciphertext or serves modified client code should be detected or prevented.

The last test is where products fail. Jonas Hofmann and Kien Tuong Truong analysed five end-to-end encrypted cloud storage services under a malicious-server model and reported severe cryptographic vulnerabilities in four of them, including cases where the server could inject files into users' encrypted storage, tamper with file data or gain access to file contents. Encrypting on the client is necessary; it is not sufficient without authenticated keys and integrity across the whole file tree.

Apple's optional Advanced Data Protection for iCloud is a well-documented example of switching a large consumer service to client-side keys, and its security overview spells out the costs:

• Recovery. Before enabling it you must set up a recovery contact or a recovery key, because Apple no longer holds the keys and cannot help you recover the data.
• Web access. Access to the data through iCloud.com is disabled by default, since a web page would need the keys.
• Scope. Mail, Contacts and Calendars stay under standard protection, as does some metadata (dates, file sizes, checksums, device names), because interoperability and service operation need them.

The same costs appear in any client-side design:

• Search, previews, thumbnails, virus scanning and deduplication need plaintext. They either run on the device or not at all.
• Sharing becomes key distribution: the recipient needs the file key, delivered either inside a link or wrapped for their public key. The second option inherits the problem of verifying that public key.
• Browser clients download their encryption code from the provider on every visit, so a provider that wanted to could serve a targeted user modified code. Native clients narrow, but do not remove, that dependency.

SRIFT avoids most of the at-rest question by not storing files at all. Server state lives only in memory, and a transfer streams from the sender's device to the receiver's while both are online, so there is no stored copy to encrypt, breach or subpoena. That makes it a different tool from cloud storage rather than a replacement: there is no mailbox for a recipient who is offline, as the P2P vs cloud comparison explains.

For data in motion, the encryption is client-side in these cases:

• Relayed browser and CLI transfers: each chunk is sealed with AES-256-GCM under a key the two devices agree with ECDH P-256 for that transfer; the relay forwards ciphertext.
• Direct WebRTC transfers: protected by WebRTC's mandatory DTLS between the two browsers, with no extra application-level layer.
• Quick-share links with --encrypt: the CLI encrypts the file in 1 MiB chunks under a random key placed in the URL fragment, which browsers do not send to servers. The relay sees a placeholder name and the ciphertext size.

# Client-side encrypted link; the key is the part after #k=
srift quick-share ./contract.pdf --encrypt --once

# Link plus a password, so a leaked link alone is not enough
# (or set SRIFT_LINK_PASSWORD to keep it out of shell history)
srift quick-share ./contract.pdf --password "<shared passphrase>" --ttl 2h