Zero-Knowledge Cloud Storage and Why File Names Matter

By Naresh Singh · 28 October 2026 · 6 min read

Plenty of cloud services say your files are "encrypted", yet the phrase can describe very different designs, and the difference decides who can read your data. This guide explains how encryption at rest differs from client-side encryption, what "zero-knowledge" should mean in practice, why file names and other metadata matter, what you give up in exchange, and what to check before you trust a service.

Encryption at rest vs client-side encryption

Encryption at rest means the provider encrypts data on its own storage systems. It protects against a stolen disk or a discarded backup. But the provider's servers hold the keys, or can ask a key service for them, so the provider's software can decrypt your files whenever it needs to. That is how server-side previews, content scanning and search work. Encryption in transit (TLS) protects the connection between your device and the server, but the server still sees the plaintext at the other end.

Client-side encryption, often called end-to-end encryption in the storage context, moves the encryption step to your device. Files are encrypted before upload, using a key the provider never receives in usable form. The server stores ciphertext it cannot decrypt, even if it is breached or compelled to hand data over. The two approaches are not exclusive: a client-side design normally still uses TLS and at-rest encryption as extra layers. The question is who holds the key that matters.

What "zero-knowledge" should mean

In cloud storage, "zero-knowledge" is a design claim, not the zero-knowledge proofs of academic cryptography. It means the provider has no knowledge of your content or of the keys that unlock it. A service that really works this way usually has these properties:

Encryption keys are generated on your device, not on the server.
The key that decrypts your files is stored on the server only in wrapped (encrypted) form, and the wrapping key comes from something only you hold, typically your password run through a deliberately slow function such as Argon2id, and often also a recovery code.
What you send to prove who you are is derived separately from the key that decrypts your files. If the server could use your login credential to decrypt, the design would not be zero-knowledge.
Encryption is authenticated, for example AES-GCM, so tampering with stored data is detected when you decrypt it.

None of this can be verified from a marketing page, which is a reason to prefer services that publish their design.

Why file names and metadata matter

Encrypting file contents is only half the job. Consider a file called Divorce settlement draft 3.pdf inside a folder called Oncology appointments. The contents may be perfectly protected, yet the name and the folder already tell a story. Metadata leaks in several ways:

File and folder names describe what you keep, and they often end up in logs, search indexes and breach dumps if they are stored in plaintext.
Folder structure shows how you organise your life or work.
Sizes hint at what a file is. A 3 MB file in a photo folder is probably a photo, and a 4 GB file is probably a video.
Timestamps and counts show when you work and how much you store.

A service that encrypts names and folder names as well as contents closes the largest of these gaps. Some metadata cannot be hidden: the server stores your encrypted blobs, so it can see their approximate size, and it also sees your account email, timestamps and network addresses. A trustworthy provider lists what it still sees.

Hiding names creates a puzzle: the server must still stop two files in one folder from having the same name. A common answer is a blind index. The client sends a keyed hash (an HMAC) of the lowercased name. The server can spot a duplicate, but it cannot read the name or work out what it was.

The trade-offs

Keeping the provider out of the loop has real costs, and an honest service tells you about them up front.

Lose your key, lose your data

If the provider cannot decrypt your files, it cannot reset your password and hand them back either. A normal "forgot password" email link cannot restore access to encrypted data, because that would imply the provider holds a master key. Services usually give you a recovery code at sign-up. Store it in a password manager or on paper, because without your password and your recovery code the data is gone.

Sharing needs a key handoff

To share a file, the recipient needs the decryption key without the server learning it. A common technique is to put the key in the fragment of the link, the part after the #, which browsers do not send to the server. Anyone holding the link can open the file, so treat it like a key; a password or expiry helps. Revoking a link stops further downloads, but it cannot un-send what someone already saved.

Search and previews move to your device

The server cannot search inside files or generate thumbnails from them. Your devices do that after decrypting, so server-side features such as full-text search or content scanning are unavailable by design.

Web access has a catch

A browser client runs code delivered by the same server. If that server were compromised, it could in theory deliver altered code. Native apps shipped through an app store narrow that gap.

Your password carries more weight

The wrapped key sits on the server, so someone who stole it could try guesses offline. A slow key-derivation function raises the cost of each guess, but a long, unique passphrase still matters.

What to look for when choosing

Where encryption happens. Is data encrypted on your device before upload, with keys the provider does not hold? The documentation should say so plainly.
Whether names are covered. Ask whether file names, folder names and thumbnails are encrypted, or only contents.
A list of what the server sees. Look for an explicit statement about sizes, timestamps, email, device names and logs.
Published, standard cryptography. Named algorithms such as AES-GCM, HKDF and Argon2id are a better sign than a vague "bank-grade". A published protocol description is better still.
Recovery that is honest. You should be told clearly what happens if you lose your password and your recovery code.
A sensible sharing model. Check where the link key lives, and whether passwords, expiry and revocation exist.
An exit and a matching privacy policy. You should be able to export your files, decrypted, and the policy should agree with the technical claims and say how long logs are kept.

Finally, remember that sync is not backup. A deletion or a corrupted file can propagate to every device, so look for trash and version history, and keep a second copy of anything irreplaceable.

How StorageSync approaches it

StorageSync, our own app, is built to this model. File contents are encrypted on your device with AES-256-GCM, and so are file names, folder names and thumbnails. Your password goes through Argon2id, and the result is split into two separate parts: one unlocks your encryption key on your device, and a different one is what the server checks at sign-in. A recovery code is shown once at sign-up. File names stay unique through a keyed-hash blind index, as described above. Share-link keys live in the link fragment.

The service still sees some things: your email address, device names and platforms, the sizes of encrypted files, counts and timestamps, and network addresses in request logs. It does not see names, contents or your keys. StorageSync is not released yet.

StorageSync encrypts file contents and file names on your device before they are uploaded. It's coming soon.

Get notified