Table of Contents
- What "encrypted cloud storage" actually means
- Zero-knowledge vs server-side: who holds the keys
- The threat models each design defends against
- Jurisdiction and metadata: the part marketing skips
- The real tradeoffs of going zero-knowledge
- Where end-to-end providers fit: Internxt and Proton Drive
- A decision framework for developers
What "encrypted cloud storage" actually means
"Encrypted" is one of the most overloaded words in the storage market. Almost every provider can truthfully claim their service is encrypted, because some layer is — and the layer that matters is rarely the one on the marketing page.
There are three distinct encryption layers in any cloud storage product, and they protect against entirely different things:
- Encryption in transit — TLS protects bytes moving between your device and the server. This stops a network eavesdropper. Every serious provider does this; it is table stakes, not a feature.
- Encryption at rest — the data on the provider's disks is encrypted, usually with AES-256. This protects against someone physically stealing a drive from the data center. But the provider holds the key, so it does nothing against the provider, a court order, or a breach that reaches the key store.
- End-to-end / zero-knowledge encryption — the data is encrypted on your device with a key only you control, before it ever reaches the server. The provider stores ciphertext it cannot read.
When a privacy-conscious developer asks for "encrypted cloud storage," they almost always mean the third layer. When a mainstream provider advertises "your data is encrypted," they almost always mean the first two. That gap is the entire subject of this article.
Zero-knowledge vs server-side: who holds the keys
The single question that separates the two worlds is: who can decrypt your files without your cooperation?
Server-side (conventional) encryption. The provider generates and stores the encryption keys. Your files are encrypted at rest, but the same system that stores the ciphertext also stores the means to decrypt it. This is the model behind the default experience of Dropbox, Google Drive, OneDrive, and most consumer cloud storage. The benefit is convenience: the server can index your files for search, render previews, run virus scanning, power collaborative editing, and reset your password without data loss. The cost is that the provider — and anyone who can legally or illegally reach the provider's key store — can read everything.
Zero-knowledge (end-to-end) encryption. The key is derived from your password on your device via a key-derivation function such as Argon2 or PBKDF2. The plaintext is encrypted locally; only ciphertext is uploaded. The provider stores an encrypted copy of your key material, wrapped by a key that itself comes from your password, so the stored bundle is useless without you. The provider therefore cannot read your files, cannot produce plaintext in response to a subpoena, and cannot reset your password without you losing access. The term "zero-knowledge" describes exactly this: the service has zero knowledge of your plaintext.
The cryptography here is not exotic — it is the same envelope-encryption pattern used inside password managers like the ones covered in our CLI password managers guide for engineers. What differs between providers is the implementation discipline: which KDF, which cipher, whether file names and folder structure are also encrypted, and whether the client is open source so the claim can be verified rather than trusted.
The threat models each design defends against
Choosing an encryption model is really choosing a threat model. Map your adversary to the design, not the other way round.
| Threat | At rest (server-side) | Zero-knowledge (E2E) |
|---|---|---|
| Network eavesdropper | Defended (TLS) | Defended (TLS) |
| Stolen data-center drive | Defended | Defended |
| Provider reads your files | Not defended | Defended |
| Rogue employee | Not defended | Defended |
| Court order / subpoena for content | Not defended | Defended (no plaintext to give) |
| Server breach reaching key store | Not defended | Defended (keys never on server in usable form) |
| You forget your password | Provider can recover | Not recoverable by design |
| Malware on your own device | Not defended | Not defended (plaintext exists locally) |
Two rows deserve emphasis. Zero-knowledge does not protect you from malware on your own machine — once you decrypt locally, plaintext is in your hands and in your RAM, so endpoint hygiene still matters. And zero-knowledge moves the password-recovery risk onto you: the provider's inability to read your data is the same property that makes a forgotten password unrecoverable. That is a feature, but it is a feature with a sharp edge.
Jurisdiction and metadata: the part marketing skips
Encryption protects content. It does not, on its own, protect metadata — and metadata is often enough.
Even a perfectly implemented zero-knowledge service still has to operate. It knows your account email (you signed up with it), your IP addresses at login, your storage volume, file sizes, upload timestamps, and — depending on implementation — file and folder names. Some end-to-end designs encrypt file names too; many do not. Metadata is generally not covered by the zero-knowledge guarantee, and it is precisely what is subpoenaed first.
This is where jurisdiction re-enters. The legal regime governing a provider determines what metadata can be compelled and under what process. The US CLOUD Act (2018) lets US authorities compel American companies to produce data held anywhere in the world. The EU's GDPR and Switzerland's revised Federal Act on Data Protection (FADP, in force September 2023) impose stricter conditions on disclosure. This is the same jurisdictional logic we covered for email in self-hosted email vs ProtonMail vs Fastmail and more broadly in data sovereignty: where a service is incorporated is a primary technical variable, not a footnote.
The practical takeaway: pair strong content encryption with a provider in a privacy-respecting jurisdiction, and assume your metadata is visible to a sufficiently motivated legal process regardless.
The real tradeoffs of going zero-knowledge
Zero-knowledge storage is not free of friction. Being honest about the costs is the only way to choose well.
Search and previews degrade. Because the server stores only ciphertext, it cannot build a full-text index of your documents or render server-side previews and thumbnails the way Google Drive does. End-to-end providers either search client-side (after your device decrypts an index) or limit search to file names. For a folder of thousands of documents, this is a noticeable difference.
Collaboration is harder. Real-time collaborative editing, the kind that made Google Docs ubiquitous, fundamentally needs a server that can read and merge document state. Zero-knowledge designs can do collaboration, but it is more constrained and the implementations are younger.
Sharing with non-users requires key exchange. Sending an encrypted file to someone outside the service means sharing a decryption key through a separate channel, or using a provider feature that generates a password-protected link. It works, but it is a step that conventional services hide.
Password recovery is on you. This bears repeating because it is the most common way people lose data on these services. Save the recovery key the provider gives you at signup, store it somewhere durable and offline, and use a strong unique password. The whole security model rests on that password.
None of these are reasons to avoid zero-knowledge storage — they are reasons to use it deliberately, for the data that warrants it, rather than as a drop-in replacement for every workflow.
Where end-to-end providers fit: Internxt and Proton Drive
Two providers come up repeatedly in privacy-focused comparisons because they ship open-source clients and end-to-end encryption by default, rather than as a paid add-on or an enterprise-only mode.
Internxt is an EU-based (Spain) provider offering zero-knowledge, end-to-end encrypted cloud storage with open-source clients and a free tier. Its positioning is a full privacy suite (drive, plus adjacent privacy tools), and the European base places it under GDPR. Because the client is open source, the zero-knowledge claim is verifiable rather than asserted.
Proton Drive is the storage component of the Proton ecosystem — Swiss-based, end-to-end encrypted, open-source, with a free tier. If you already use Proton Mail or Proton VPN, Drive slots into the same account and the same Swiss jurisdiction, making it a natural way to keep encrypted files alongside encrypted email. The same zero-access model that protects a Proton inbox protects Drive files.
Neither is a universal answer. They are the right tool when you specifically need the provider to be unable to read your data, and you accept the search/collaboration tradeoffs in exchange.
A decision framework for developers
Stop asking "which is the most secure cloud storage" and start asking "what is this data, and who must not read it?"
Use conventional storage (Drive/Dropbox/OneDrive) when: you need fast full-text search across documents, real-time collaboration, rich previews, and the data is not sensitive enough to justify the friction. Convenience is a legitimate requirement.
Use zero-knowledge storage (Internxt, Proton Drive) when: the content must remain unreadable to the provider — personal documents, credentials archives, client data under NDA, backups of sensitive projects, anything you would not want produced under a subpoena. Accept that search is local and sharing needs a key.
For source code: keep using Git on a forge for the workflow; use encrypted storage for backups of repositories, large binary assets, and build artifacts you do not want a third party indexing. Do not put live secrets in raw files on any storage — use a dedicated secrets manager or encrypted vault.
Whatever you choose, verify the claim. Prefer open-source clients so the encryption is auditable, prefer a privacy-respecting jurisdiction so metadata is harder to compel, and save your recovery key the moment you sign up to a zero-knowledge service. The strongest cryptography in the world is undone by a forgotten password with no recovery path.
For the broader context of keeping your data out of US-jurisdiction services, see our pillar on data sovereignty and the practical migration guide in alternatives to Google.
