What Is Zero-Knowledge Cloud Storage? Definition and Tests

Q: How is zero-knowledge different from just “encrypted” storage?

Almost all cloud storage is “encrypted” — in transit (TLS) and at rest (disk encryption). But in ordinary encrypted storage the provider holds the keys, so it can decrypt and read your files, and can be compelled to hand them over. Zero-knowledge means the keys are derived and used on your device and never reach the provider. The test is simple: if the provider can reset your password and still show you your files, it is not zero-knowledge.

Q: Is Google Drive or Dropbox zero-knowledge?

No. Google Drive, Dropbox, OneDrive, and standard iCloud all encrypt files in transit and at rest, but the provider holds the keys and can read file contents — for indexing, search, previews, abuse scanning, or in response to a legal request. They are encrypted, not zero-knowledge. iCloud becomes end-to-end encrypted for most categories only if you turn on Advanced Data Protection, which is opt-in.

Q: Is zero-knowledge the same as end-to-end encrypted?

They overlap heavily and are often used interchangeably for storage. “End-to-end encrypted” emphasizes that data is encrypted from one endpoint to another with no readable point in between; “zero-knowledge” emphasizes that the service provider, specifically, holds no key and no plaintext. For a storage service where you are both endpoints, they describe the same guarantee: the provider cannot read your files.

Q: What can the provider still see if storage is zero-knowledge?

Encryption hides file contents, not necessarily everything around them. Depending on the design, a zero-knowledge provider may still see metadata such as file sizes, upload timestamps, access patterns, your account email, and billing details. Good implementations also encrypt file names and folder structure, but not all do. Zero-knowledge protects the contents of files; it is not anonymity.

Q: What happens if I forget my password?

Usually your files become unrecoverable, and that is the point. Because the provider never holds your key, it cannot reset your password and restore access to your files the way Google or Dropbox can. This is the direct trade-off for the provider being unable to read your data. Zero-knowledge services typically mitigate it with a one-time recovery key or phrase you store yourself — which you must keep safe, because it is the only backdoor and it belongs only to you.

Q: How do I verify a provider is really zero-knowledge?

Four practical checks. One: read the security or whitepaper page and confirm files are encrypted client-side, before upload. Two: check whether a forgotten password means lost files — if the provider can fully restore access, it holds your key. Three: look for open-source client or crypto code you or a reviewer can inspect, rather than a claim you must take on faith. Four: check whether an independent audit exists. No single check is sufficient alone, but together they separate architecture from marketing.

Q: Does zero-knowledge storage protect against a future quantum computer?

Not by default. Most zero-knowledge providers still use classical encryption (RSA or elliptic-curve key exchange), which a future large quantum computer could break — a concern for data an adversary can copy now and decrypt later. Post-quantum protection is a separate, newer property layered on top of zero-knowledge. As of August 2026 very few providers ship it by default on stored files.

What zero-knowledge cloud storage means

Zero-knowledge cloud storage is cloud storage where your files are encrypted on your own device, before they are uploaded, using a key that is derived from a secret only you hold. The provider receives and stores only the resulting ciphertext. It never receives the key, so it cannot decrypt your files.

The name is literal. The service has zero knowledge of what your files contain. If its servers are breached, if an employee goes looking, or if a court order arrives, what the provider can produce is ciphertext — not readable client records, contracts, or financial statements.

The distinction that matters is where the encryption happens and who holds the key. In ordinary cloud storage, the provider encrypts your files on its own servers and keeps the keys. In zero-knowledge storage, the encryption happens on your device and the key never leaves it. That single architectural difference is the whole idea.

Zero-knowledge vs "encrypted": the distinction that matters

Nearly every mainstream cloud service is already "encrypted," and providers say so prominently. It is true, and it is not the same thing.

Standard encrypted storage protects your files in two places:

In transit — a TLS connection encrypts data as it travels between your device and the server, so someone tapping the network sees nothing useful.
At rest — the provider encrypts files on its disks, so a stolen drive is not readable.

Both are worth having. Neither stops the provider itself from reading your files, because in both cases the provider holds the keys. That access is what powers server-side search, thumbnail previews, document editing, abuse scanning, and — when compelled — disclosure to third parties.

Zero-knowledge storage adds a third, decisive layer: the file is encrypted on your device, before upload, with a key the provider never sees. The provider still applies TLS and at-rest encryption on top, but underneath, the content it holds is already opaque to it.

There is a one-sentence test for any provider: if it can reset your password and still show you your files, it is not zero-knowledge. The ability to restore your access from its side means it holds a key to your data.

How zero-knowledge storage actually works

The mechanics vary between providers, but the shape is consistent:

A key is derived on your device. Typically from your password or passphrase run through a slow key-derivation function, or from a randomly generated key protected by that passphrase. This happens locally — the raw key is never sent anywhere.
Each file is encrypted locally. Before a file leaves your device, it is encrypted with a symmetric cipher. Well-designed systems give each file its own key, so compromising one file does not cascade to the rest.
Only ciphertext is uploaded. The provider stores encrypted blobs. Depending on the implementation, file names and folder structure are encrypted too — the better ones do this; not all do.
Decryption happens only on your devices. When you or an authorized recipient open a file, the key is reconstructed locally and the file is decrypted there. The plaintext never exists on the provider's servers.

The consequence runs in both directions. Because the provider cannot read your files, it also cannot recover them for you if you lose your key. That trade-off is not a flaw; it is the guarantee working as designed.

What zero-knowledge does not protect

Zero-knowledge is a precise claim about file contents, and it is easy to over-read. Being honest about the edges is part of understanding it.

Metadata may still be visible. File sizes, upload and access timestamps, and access patterns can remain observable even when contents are encrypted. Whether file names and folder structure are hidden depends on the specific implementation.
Account and billing data is not file data. Your email address, payment details, and login times are handled like any other service's account data, outside the encrypted envelope.
Your device is the trust boundary. Encryption happens on your device, so malware or a compromised machine sees plaintext exactly as you do. Zero-knowledge protects data at the provider, not a device that is already breached.
It is confidentiality, not anonymity. The provider generally still knows that you have an account and that you are storing something — just not what.
It is not automatically post-quantum. Most zero-knowledge providers use classical key exchange, which a future quantum computer could break. That is a separate property, covered below.

Encrypted, zero-knowledge, end-to-end: the terms untangled

These labels are used loosely, which is how "encrypted" gets mistaken for "private." Here is the plain mapping:

Encrypted — data is scrambled somewhere in the pipeline (in transit and/or at rest). Says nothing about who holds the key. The provider usually does.
End-to-end encrypted (E2EE) — data is encrypted from one endpoint to another with no readable point in between. For storage, you are effectively both endpoints.
Zero-knowledge — the emphasis is on the provider: it holds no key and no plaintext, and therefore has zero knowledge of your file contents.

For a personal storage service, end-to-end encrypted and zero-knowledge describe the same practical guarantee from two angles: the provider cannot read your files. "Encrypted," on its own, does not make that promise.

The post-quantum wrinkle

Even a genuinely zero-knowledge provider is usually relying on classical cryptography — RSA or elliptic-curve key exchange — to establish the keys underneath. Those are secure against today's computers but vulnerable to a sufficiently large future quantum computer running Shor's algorithm.

That matters for one specific threat: "harvest now, decrypt later." An adversary copies your ciphertext today and simply waits, decrypting it once the hardware exists. For files whose sensitivity is short-lived, this is a weak threat. For records that must stay confidential for a decade or more, it is a real one.

Post-quantum protection layers a quantum-resistant key-establishment step — such as ML-KEM (standardized by NIST as FIPS 203) — over the zero-knowledge design. As of August 2026, very few providers ship it by default on stored files. It is a distinct property from zero-knowledge, and worth checking separately. The post-quantum encrypted cloud storage guide covers it in depth.

Who can read your files, by default

The single question that separates these products is who holds the keys. This table reflects each option's typical default configuration, as of August 2026; consult each provider's current documentation before relying on it.

Provider (default config)	Encrypted in transit + at rest	Client-side / zero-knowledge	Provider can read your files	Post-quantum by default
Google Drive, Dropbox, OneDrive	Yes	No	Yes	No
iCloud (Standard Data Protection)	Yes	No	Yes	No
iCloud (Advanced Data Protection)	Yes	Yes (opt-in)	No	No
Proton Drive, Tresorit, Sync.com	Yes	Yes	No	No (classical)
pCloud	Yes	Only via paid Crypto add-on	Yes, unless add-on enabled	No
ShieldFive	Yes	Client-side encryption; client-code trust applies	Cannot claim provider-inaccessible	Hybrid default on web and Android, AES fallback

The line that does not move is the "provider can read your files" column. Business tiers and admin controls narrow operational risk for the top rows, but they do not change who holds the keys. That is an architecture decision, not a settings toggle.

How to verify a zero-knowledge claim

"Zero-knowledge" is a marketing term as often as a technical one. Four checks separate the architecture from the label:

Read the security documentation. Confirm, in the provider's own words, that files are encrypted client-side, before upload. Vague phrasing about "bank-grade encryption" is not the same claim.
Test the forgotten-password path. If the provider can fully restore access to your files after a password reset, it holds your key and is not zero-knowledge. A zero-knowledge service will instead rely on a recovery key you hold yourself.
Look for inspectable code. Open-source client or crypto code lets you — or an independent reviewer — verify the claim rather than trust it. A closed black box asks for faith.
Check for an independent audit. An external review is a separate assurance from open code; the strongest position is both. Its absence does not prove a claim false, but its presence is meaningful.

No single check is conclusive. Taken together, they are hard to fake.

Where ShieldFive fits

Files are encrypted on your device before upload. Your password never reaches our servers: the browser turns it into a separate login value with Argon2id and sends only that, and the key that opens your vault is derived separately and stays on your device. The app code is delivered by ShieldFive, so the client you are served is part of the trust boundary: client-side encryption does not establish that ShieldFive is technically unable to decrypt your files. See the security overview before deciding whether this model meets your requirements.

Three properties are worth stating precisely, including their limits:

Client-specific formats. Web uploads default to the ML-KEM-1024/XChaCha20-Poly1305 hybrid format, with an AES-256-GCM fallback. Android also writes the hybrid format by default, with the same AES-256-GCM fallback, and reads both formats. The format used by a particular client matters; we do not promise post-quantum hybrid encryption for every upload.
Open crypto, closed app. The cryptography core is open source under Apache-2.0 and can be read and reviewed at github.com/shieldfive/crypto. The application built around it is closed-source. The crypto core has not yet completed an external third-party audit; that audit is planned, and it is worth saying plainly rather than implying otherwise.
EU data residency. Encrypted data is stored in the EU, which supports GDPR-ready workflows and EU-jurisdiction preferences. Because files are encrypted before they arrive, the storage location only ever holds ciphertext regardless.

ShieldFive offers a free 10 GB tier with no card. See plans and pricing and the security overview. If you want to compare zero-knowledge providers side by side, the best zero-knowledge cloud storage guide rates ten of them honestly on jurisdiction, audits, open code, and the post-quantum axis.

Frequently asked questions

What is zero-knowledge cloud storage?

Zero-knowledge cloud storage is storage where your files are encrypted on your own device, before they are uploaded, using a key only you hold. The provider stores only ciphertext and never receives the key, so it cannot read your files. The "zero-knowledge" is literal: the service has zero knowledge of your file contents. It is a property of the architecture, not a promise in a privacy policy.

How is zero-knowledge different from just "encrypted" storage?

Almost all cloud storage is "encrypted" — in transit and at rest — but the provider holds the keys and can read your files. Zero-knowledge means the keys are derived and used on your device and never reach the provider. The test: if the provider can reset your password and still show you your files, it is not zero-knowledge.

Is Google Drive or Dropbox zero-knowledge?

No. Google Drive, Dropbox, OneDrive, and standard iCloud encrypt files in transit and at rest, but the provider holds the keys and can read contents — for indexing, previews, scanning, or a legal request. They are encrypted, not zero-knowledge. iCloud becomes end-to-end encrypted for most categories only with the opt-in Advanced Data Protection setting.

Is zero-knowledge the same as end-to-end encrypted?

For a storage service they describe the same practical guarantee: the provider cannot read your files. "End-to-end encrypted" emphasizes that data is encrypted from one endpoint to another with no readable point in between; "zero-knowledge" emphasizes that the provider specifically holds no key and no plaintext.

What can the provider still see if storage is zero-knowledge?

Encryption hides contents, not necessarily everything else. A provider may still see metadata such as file sizes, timestamps, and access patterns, plus your account email and billing details. Good implementations also encrypt file names and folder structure, but not all do. Zero-knowledge protects file contents; it is not anonymity.

What happens if I forget my password?

Usually your files become unrecoverable — and that is the point. Because the provider never holds your key, it cannot reset your password and restore your files the way Google or Dropbox can. Zero-knowledge services typically mitigate this with a one-time recovery key you store yourself, which is the only backdoor and belongs only to you.

How do I verify a provider is really zero-knowledge?

Four checks: confirm the docs say files are encrypted client-side before upload; test whether a forgotten password means lost files; look for open-source client or crypto code you can inspect; and check whether an independent audit exists. No single check is sufficient, but together they separate architecture from marketing.

Does zero-knowledge storage protect against a future quantum computer?

Not by default. Most zero-knowledge providers use classical key exchange (RSA or elliptic-curve), which a future large quantum computer could break — the "harvest now, decrypt later" concern. Post-quantum protection is a separate property layered on top. As of August 2026, very few providers ship it by default on stored files.

Is ShieldFive zero-knowledge?

Not as an absolute provider-cannot-read guarantee. Files are encrypted on your device before upload. Your password never reaches our servers: the browser turns it into a separate login value with Argon2id and sends only that, and the key that opens your vault is derived separately and stays on your device. The app code is delivered by ShieldFive, so the client you are served is part of the trust boundary: client-side encryption does not establish that ShieldFive is technically unable to decrypt your files. See the security overview before deciding whether this model meets your requirements. Web uploads default to the ML-KEM-1024/XChaCha20-Poly1305 hybrid format, with an AES-256-GCM fallback. Android also writes the hybrid format by default, with the same AES-256-GCM fallback, and reads both formats. The format used by a particular client matters; we do not promise post-quantum hybrid encryption for every upload.

Is zero-knowledge storage worth the trade-offs for everyone?

Not necessarily. If you rely on server-side full-text search, in-browser editing, or provider-driven password recovery, ordinary encrypted storage is more convenient. Zero-knowledge earns its trade-offs when confidentiality matters more than those conveniences — client records, legal and financial documents, health data, source material, or anything under a professional confidentiality obligation.