Client vs Server Encryption

What server-side encryption really means

Most cloud services advertise “encrypted at rest.” In nearly all of those cases, that means server-side encryption:

Data arrives at the server over HTTPS.
The server sees plaintext and may process, index, or transform it.
Before writing to disk, the server encrypts it (for example, with AES-256) using keys it controls.

Benefits:

Protects against lost disks and some infrastructure-level attacks.
Often implemented transparently via storage providers or database features.

Limits:

Admins, services, and anyone with database or key access can still read your data.
If an attacker compromises the application or key-management layer, “encrypted at rest” does not help.

Server-side encryption is table stakes, not a guarantee that the provider has no access.

What client-side encryption changes

Client-side encryption flips the model:

Data is encrypted before it leaves your device.
The provider stores only ciphertext and non-sensitive parameters (salt, IV, metadata).
Decryption keys never reach the server.

In a browser-based product like Inkrypt:

The browser uses the Web Crypto API to derive keys and encrypt.
Keys are derived from your password via PBKDF2 with 310k iterations.
Notes are encrypted with AES-256-GCM using fresh random IVs.
The server receives ciphertext, salt, IV, and metadata—but no password or key.

This is the core of a zero-knowledge architecture: the provider literally cannot decrypt what it stores for you.

For more on this model:

Threat models: when client-side encryption matters

Client-side encryption meaningfully changes outcomes when:

Databases are breached:
Server-side encryption: attacker steals ciphertext and keys (if they compromise the app or KMS).
Client-side encryption: attacker gets only ciphertext; keys never lived on the server.
Admins or insiders go rogue:
Server-side: admins with key or DB access can read data.
Client-side: admins see ciphertext and metadata only.
Legal or extralegal access:
Server-side: provider can be compelled to produce plaintext or keys.
Client-side: provider can supply ciphertext and parameters but cannot decrypt.

Client-side encryption does not mitigate:

Compromised endpoints (malware on user devices).
Abuse by legitimate recipients (screenshots, copy-paste).

But it does:

Shrink the trust surface.
Reduce blast radius from server-side incidents.
Change breach and compliance discussions materially.

Operational trade-offs of client-side encryption

You give up some conveniences:

Search:
Server cannot full-text search encrypted content.
Workarounds involve client-side indexing or tagged metadata.
Recovery:
No “forgot password” that magically restores plaintext.
If the key depends solely on your password, losing it means losing the data.
Analytics and automation:
No server-side content scanning or enrichment.

In exchange, you get:

A simpler story about who can read what.
Better alignment with zero-knowledge claims.
Stronger posture for high-sensitivity data and regulated contexts.

Inkrypt chooses this trade-off explicitly. We accept:

No server-side search across notes.
No password reset.
Limited analytics on encrypted bodies.

In return, we can confidently say we can’t read your notes.

How to decide between client-side and server-side encryption

You rarely get to ignore server-side encryption entirely; it’s a basic hygiene layer. The real choice is whether you also add client-side encryption for specific data paths.

Use server-side encryption alone for:

Public or low-sensitivity data.
Caches, logs, and non-critical telemetry that still shouldn’t be left in plaintext on disk.

Layer client-side encryption on top for:

Confidential notes and documents.
Secrets that would be damaging if exposed in a database dump.
Data you want to keep out of the provider’s reach by design.

Inkrypt addresses the last category: shared notes and self-destructing messages where client-side encryption with AES-256-GCM and PBKDF2-derived keys is appropriate.

You can try it at https://www.inkrypt.online and decide where that model belongs in your own stack.

FAQ: Client vs server encryption

Q1. Is “encrypted at rest” enough?

It’s necessary but not sufficient. “Encrypted at rest” usually means server-side encryption, where the provider can still decrypt your data. It does not provide zero-knowledge guarantees.

Q2. Can my provider read data if they use server-side encryption?

Yes. If they control the encryption keys or can access them through their infrastructure, they can decrypt. Server-side encryption protects against certain infrastructure failures, not against the provider itself.

Q3. How does client-side encryption work in the browser?

In tools like Inkrypt, the browser uses the Web Crypto API to derive keys (for example, PBKDF2 with 310k iterations) and encrypt content with AES-256-GCM. Only ciphertext and public parameters reach the server.

Q4. Does client-side encryption mean I can never lose data?

No. It means the provider cannot recover it for you if you lose the password or key. Strong client-side encryption removes recovery backdoors as well as attacker routes.

Q5. When should I insist on client-side encryption from a vendor?

When the data involved is highly sensitive, when regulatory or contractual obligations require strongest-available protection, or when you explicitly want to minimise how much a provider can see or do with your data.

Where to go next

For more detail on how Inkrypt implements client-side, zero-knowledge encryption:

Then evaluate where a tool like Inkrypt at https://www.inkrypt.online makes sense in your environment alongside systems that rely solely on server-side encryption.