What does client-side encryption protect against, and when do I need it?

“Encrypted” can describe several different boundaries. HTTPS encrypts a connection between a client and an endpoint. Server-side encryption encrypts stored data under keys controlled by the service or its operator. Client-side encryption encrypts before upload, which can keep the content unreadable to the service that stores and returns it.

That last boundary is useful when the storage provider should be able to hold bytes but should not be able to inspect them. It is not automatically better for every file. Encryption adds key management, recovery decisions, compatibility work, and sometimes limits server-side search, preview, virus scanning, or transformation. The correct question is which parties should be able to read the plaintext.

Three boundaries, three claims

HTTPS protects against many network observers between your client and the HTTPS endpoint. It does not protect against a malicious or compromised endpoint, an administrator who can access plaintext after termination, or a client that uploads plaintext by mistake.

Server-side encryption protects stored media if a raw disk or backup is exposed, depending on the key architecture. The service can generally decrypt while serving a legitimate request. Client-side encryption changes the sequence: the client turns plaintext into ciphertext, sends ciphertext, and the authorised recipient decrypts locally.

Use authenticated encryption

Confidentiality alone is not enough. An attacker who cannot read a file may still alter it. Use an authenticated encryption mode from a maintained, reviewed library, so the recipient can detect changes and reject a ciphertext produced with the wrong key. Do not invent a format from a hash, a password concatenation, or a home-made XOR scheme.

Key derivation matters when a human passphrase is involved. A password is not a random encryption key. Use a password-based key derivation function with a unique salt and a work factor suited to the environment, or generate a random key and store it in a proper secret manager. NIST's key-management guidance covers lifecycle concerns such as generation, storage, recovery, and destruction.

What client-side encryption does not conceal

Encryption usually does not hide that a request happened, when it happened, how large the object is, which box or name was addressed, or how often it is downloaded. The service may also see response status and network identity. Object names can reveal sensitive information, so choose neutral names when metadata matters.

Traffic analysis is a separate problem. Padding can make sizes less revealing, batching can alter timing, and private networks can reduce observer access, but each adds complexity. Do not promise anonymity when the design only provides content confidentiality.

Keys are the hard part

A system with perfect encryption and a lost key has failed its owner. Decide how recipients receive the key, who can recover it, how a new device is enrolled, and what happens when someone leaves. Keep a protected backup for keys that protect irreplaceable data. For a temporary secret, a short-lived key may be appropriate. For a long-lived archive, recovery deserves deliberate governance.

Do not put a key into an ordinary URL query parameter. A browser fragment can avoid sending the fragment to the HTTP server, but fragments can still be copied, recorded, or exposed by the client. A separate authenticated channel or a key-wrapping scheme may be better. The capability that permits a GET and the cryptographic key that decrypts the result are separate kinds of authority.

Client-side encryption with svc.nz

svc.nz can hold arbitrary bytes, so an encryption-aware client can encrypt locally and PUT the ciphertext to in.svc.nz/<box>/<name>. The recipient GETs from out.svc.nz/<box>/<name>/latest with an Authorization: Capability ... header, then decrypts locally. The service's public job is to address, authenticate, version, and return bytes.

# The body below should already be ciphertext created by your client
curl -X PUT --data-binary @payload.ciphertext \
  https://in.svc.nz/private-box/payload.bin \
  -H 'Authorization: Capability YOUR_WRITE_CAPABILITY'

curl --fail --output payload.ciphertext \
  https://out.svc.nz/private-box/payload.bin/latest \
  -H 'Authorization: Capability YOUR_READ_CAPABILITY'

Do not infer from this shape that the example implements encryption for you. Choose a client and format that you can audit and recover. Optional client-side encryption is a concept and workflow choice, not a substitute for cryptographic engineering.

Anonymous boxes expire, which can reduce the lifetime of casual transfers. svc.nz is currently a private trial, so do not use it as the sole copy of important encrypted data, and read the policy centre for current service limitations.

When you need it

Use client-side encryption when the storage operator should not have plaintext access, when policy requires provider-independent confidentiality, or when a file will pass through a service you do not fully trust. It is especially useful for private exports, sensitive research material, credentials that must be transported temporarily, and data whose server-side indexing is unnecessary.

It may be unnecessary when the endpoint is fully trusted, the data is public, or a managed platform's server-side encryption and identity controls meet your threat model. It may be the wrong tool when multiple services need to search, transform, or moderate plaintext. You can still encrypt selected fields or selected objects rather than forcing every workflow into an opaque blob.

Verify the workflow

Test with known plaintext and a wrong key. Confirm the server receives ciphertext rather than a client-side flag alone. Confirm tampering fails authentication, keys are absent from logs, and the recipient can recover after a restart. Record the format version and nonce handling so future clients can read old objects. Security claims should be demonstrated at the boundary you care about.

FAQ

Sources

NIST SP 800-57, key management; NIST SP 800-38D, GCM authenticated encryption; MDN Web Crypto API; OWASP Cryptographic Storage; RFC 8446, TLS 1.3.