Zero-knowledge cloud storage encrypts your files on your device before they upload, with keys only you hold. The provider stores ciphertext it can't read, scan, hand over in readable form, or train AI on. That's stronger than "encryption at rest", where the provider keeps the keys and can decrypt whenever it likes.
That one distinction is the whole game. Most clouds blur it on purpose, because the blurry version sells just as well and costs them nothing. So I'm going to draw the line precisely, and then hand you the tools to check the claim yourself instead of taking my word for it.
I'm Guus. My brother and I build Beebeeb, an end-to-end encrypted, zero-knowledge storage product. So yes, I have a side. I'll be upfront about that, and I'll be just as upfront about where we aren't finished yet.
What "zero-knowledge" actually means
The term is borrowed from cryptography, where it has a formal definition. In storage it gets used more loosely, but the working version is simple, and you should hold every provider to it:
The provider can prove it's storing your data without ever learning what the data is.
Three things have to be true for that to hold.
- Encryption happens on your device. Your file becomes ciphertext before a single byte leaves your laptop or phone. This is client-side encryption. The plaintext never travels.
- You hold the keys. Only you. The key that decrypts your files is derived from your password (or a recovery key) on your device. The provider never receives it. Not "doesn't peek at it" — never receives it.
- The provider holds ciphertext it can't reverse. What sits on the server is a blob of high-entropy noise. Without your key, it's mathematically useless.
If all three hold, the provider genuinely knows nothing about your files' contents. They can still see metadata — file sizes, timestamps, how much you store — and a careful product minimises even that. But the contents? Noise.
The keys-only-you-hold part is the load-bearing wall
Here's the test that cuts through every marketing page. Can the provider reset your password and still give you your files back?
If yes, they hold a key to your data. Full stop. A password reset that recovers your files means the decryption key exists somewhere they can reach. That isn't zero-knowledge, whatever the homepage says.
Real zero-knowledge has a price, and honest providers state it plainly: lose your password and your recovery key, and your data is gone. We can't recover it. Neither can Proton. Neither can Tresorit. That sentence is the proof you're looking at the real thing. A provider that promises both "we can't read your files" and "don't worry, we'll always get you back in" is promising two things that can't both be true.
Zero-knowledge vs "encryption at rest" — the distinction clouds love to blur
Nearly every cloud says "your data is encrypted." Technically true. Nearly meaningless.
Encryption at rest means the data is encrypted while it sits on the provider's disks — and the provider holds the keys. When you log in, they decrypt it for you. Which means they can decrypt it any time they want: to index it for search, to scan it, to generate thumbnails, to answer a subpoena, or to feed it to a model. The lock is real. They just keep a copy of the key on a hook by the door.
End-to-end / zero-knowledge means the key never leaves your device. The provider can't decrypt your files because they don't have the means to.
Think of a hotel safe-deposit box. In one version the hotel keeps a master key; in the other you brought the only key from home. The hotel will swear the room is secure either way, and it might be. But only one arrangement protects you when the hotel gets served a warrant, gets breached by an attacker, or quietly decides that scanning your files makes the product better.
This matters more in 2026 than it did even a year ago. A US provider is compellable under the US CLOUD Act to produce data stored anywhere on a valid US demand — even where that conflicts with foreign law. The "EU region" badge on the label doesn't change the jurisdiction of the parent company. In June 2025, Microsoft's France legal chief told the French Senate, on the record, that he couldn't guarantee EU customer data would never be handed to US authorities. With encryption at rest, "we were legally compelled to hand it over" means your readable files left the building. With zero-knowledge, the most anyone can hand over is ciphertext. That's not a policy promise you have to believe. It's arithmetic.
AES-256-GCM, in plain terms
When we say a file is encrypted, the specific algorithm matters. We use AES-256-GCM. Two parts.
- AES-256 is the cipher — the lock. It scrambles your file with a 256-bit key. The number of possible keys is 2 to the power of 256, a figure with 78 digits in front of it. There's no known practical attack that brute-forces that. It's the same cipher standards bodies and security engineers reach for by default, for boring reasons.
- GCM (Galois/Counter Mode) is the part people skip over, and it's the part that saves you. GCM doesn't only encrypt — it authenticates. Every encrypted chunk carries a tag that proves it hasn't been tampered with. Flip a single bit of ciphertext — a faulty disk, a malicious server — and decryption fails loudly instead of quietly handing you corrupted, attacker-shaped data. Confidentiality and integrity in one pass.
On top of the file cipher, your password has to become a key without being guessable. That job goes to Argon2id — a deliberately slow, memory-hungry function that makes brute-forcing passwords ruinously expensive for an attacker while staying fast enough for you to log in. AES-256-GCM for the data, Argon2id for the auth. Neither is exotic. That's the point. Boring, well-understood primitives are exactly what you want holding your files. It also lines up with where EU regulation is heading. EU member states were due to transpose the NIS2 framework into national law by 17 October 2024, with enforcement and implementation ramping through 2025 and 2026. Its implementing rules push relevant cloud and digital-service providers toward a cryptographic policy built on state-of-the-art cryptography and cryptographic agility — the ability to swap algorithms quickly as the field moves, pointing toward eventual post-quantum readiness. They don't mandate a specific algorithm; they mandate the capability to change it.
Open source is the only thing that turns a claim into a fact
Here's the uncomfortable bit. Everything above — client-side encryption, keys only you hold, AES-256-GCM — is a claim. A closed-source provider asking you to believe it is asking for your trust. And the entire reason you wanted zero-knowledge in the first place was so you wouldn't have to trust anyone.
The way out is to publish the code that does the encryption, so anyone can read it and confirm the plaintext never leaves your device and the key is never transmitted. Verify, don't trust. It's the oldest principle in security, and it's the one the storage industry mostly ignores.
Let me be precise about our own setup, because precision is the brand. Our clients and the encryption core are open source — the parts that actually hold and use your keys, the auditable surface. Our server is private. That split is deliberate: the server only ever sees ciphertext, so the security argument never has to depend on trusting the server. It depends on trusting the open client, which you can read. Proton Drive made a similar call, and it's a good one. While I'm here, credit where it's due — both Proton Drive and Tresorit are genuine zero-knowledge products from serious teams. If you're weighing the field, our Beebeeb vs Proton Drive and Beebeeb vs Tresorit comparisons lay out where we differ without pretending the others are bad. Our edges are jurisdiction, openness, the CLI and WebDAV tooling, scale, and being one focused product instead of a suite. Not "they're insecure." They aren't.
How a curious person can actually verify the claim
You don't need to be a cryptographer. You need a browser's developer tools and twenty minutes. Here's exactly what I'd do to any provider, us included.
1. Watch the network while you upload
Open your browser's developer tools, go to the Network tab, and upload a file you'd recognise — say, a text file with the word BANANA in it a hundred times. Find the upload request and look at the payload. In a zero-knowledge product you'll see high-entropy binary, not your text. If you can spot BANANA in the request body, the encryption isn't happening before upload, and the whole claim falls over. This one test exposes most "encrypted cloud" marketing in about thirty seconds.
2. Read the encryption code
For an open product you can go straight to the source and find where encryption happens. Confirm two things: the cipher operation runs on the client, and the key is derived locally and never serialised into any network request. You're hunting for the absence of a "send key to server" line as much as the presence of the encryption call. With our open clients you can do exactly this. With a closed provider you simply can't — and that gap is itself the answer.
3. Try the password-reset test
Sign up, store a file, then trigger a password reset and read what the flow tells you. If it cheerfully restores access to your existing encrypted files, the provider holds a key. If it warns that resetting without your recovery key means losing access to already-encrypted data, that's the honest, cryptographically-consistent behaviour you want.
4. Check the jurisdiction and the corporate parent
Encryption is the technical wall; jurisdiction is the legal one. Find out which company actually operates the service, and under which country's law — not just where the servers physically sit. We're operated by Initlabs B.V., a Netherlands company, with data stored in Falkenstein, Germany, under EU law and outside the reach of the US CLOUD Act. That's a deliberate, checkable structural choice, not a slogan.
Where I have to be honest about our limits
An independent third-party security audit of Beebeeb is planned, not yet done. I'm not going to call us "audited" — that word means something specific and we haven't earned it. Today the strongest verification we offer is the open code you can read for yourself. The audit is on the roadmap before our September 2026 launch, and when it lands I'll link the report right here. And if you read a competitor claiming to be "fully audited", go find the actual report with a date and a firm's name on it. Sometimes it exists. Sometimes it's just a word on a page.
The AI-training worry, settled by the math
This is the question I get most in 2026, and zero-knowledge answers it cleanly.
The fear is reasonable. A provider that holds your keys and your files can, in principle, scan them, index them, and use them to train or fine-tune models — sometimes via a line buried in a terms-of-service update nobody read. With encryption at rest, that technical capability is sitting right there. The only thing between your files and a training run is the provider's current policy. Policies change. Companies get acquired. Terms get rewritten on a Tuesday.
With true zero-knowledge, that capability doesn't exist. We hold ciphertext we can't read. We can't train a model on your documents for the same reason we can't hand them readable to anyone else: we don't have the key, and the file on our disks is noise. The protection isn't a promise we might quietly revise next quarter. It's an architecture we couldn't walk back if we wanted to.
That's the entire pitch for doing this properly, and it's why we picked the harder path. The only privacy guarantee worth anything is one the provider couldn't break even if it tried.
The bottom line
Zero-knowledge cloud storage isn't a feature you bolt on or a phrase you drop on a pricing page. It's an architecture: encrypt on the device, keep the keys with the user, store noise on the server, and publish the code so anyone can check it. Anything less is "encryption at rest" in a nicer outfit — and in a world of the CLOUD Act, sovereignty washing, and models hungry for training data, the gap between the two is the whole point.
You can start free with 5 GB on the same encryption the paid plans use, and our pricing scales up to 99 TB self-serve, with a custom quote beyond that. But more than any of that: read the code, run the network test, ask the password-reset question. Don't trust me. Verify.