rclone crypt vs a Native Zero-Knowledge Cloud: What You Actually Get

rclone crypt is genuinely zero-knowledge. It just stops at the encryption.

Point rclone crypt at an S3 bucket and the provider stores ciphertext, nothing else. File contents are sealed with NaCl SecretBox (XSalsa20 + Poly1305) in 64 KiB chunks, the key comes from scrypt (N=16384, r=8, p=1), and filenames are encrypted segment-by-segment with AES-256 in EME mode. That is real client-side encryption over storage you already pay for. What rclone deliberately hands back to you is everything around the encryption: key backup, sharing, previews, recovery. This post is about where that line sits, and what a native client picks up on the other side of it.

What does rclone crypt get right?

The trust model — the part most "encrypted" services quietly fudge — is the part rclone nails. The remote backend never sees a plaintext byte or a plaintext filename. And you don't have to take that on faith: rclone is open source, the crypt format is documented down to the nonce-increment scheme, and you can read the Go that does the sealing. Nobody is asking you to trust a marketing line.

It also rides on commodity storage. rclone crypt wraps any of the ~70 backends rclone supports, so you get zero-knowledge layered on AWS S3 Standard at roughly $0.023/GB-month, a Backblaze bucket, or your own MinIO box. Filenames default to standard encryption; there's also an obfuscation mode that the docs themselves say "cannot be relied upon for strong protection," so use standard unless a path-length limit forces your hand.

Best of all, it composes. rclone mount, rclone serve webdav, cron, restic piped over crypt — it's a Unix tool that does one job and feeds the rest of your stack. For a sysadmin backing up a server unattended, that's usually the right answer, and a native app would just be in the way.

Where rclone makes you the integrator

The encryption is solved. The product around it is homework. Four pieces in particular:

• Key backup is a config file you have to not lose. Your key lives in rclone.conf, derived from a password and (ideally) a password2 salt. Lose it and the data is gone. That's correct behavior for zero-knowledge, but the recovery path is whatever you built — no mnemonic, no escrow, no reset link. You are the key-management department.
• Sharing is a manual export. rclone has no concept of a recipient. To send someone one encrypted file you decrypt it and re-share through another channel, or you hand over the whole crypt password. The second option gives them everything, forever, with nothing to revoke.
• No previews, no thumbnails, no search. Filenames are AES-256 ciphertext on the remote. You can't grep the bucket, can't glance at a photo without pulling and decrypting it, and can't browse from a phone unless rclone is installed on it.
• Per-chunk integrity, not whole-file integrity. SecretBox authenticates every chunk, but base crypt has no defense against a malicious remote truncating or reordering whole files — a long-standing, still-open enhancement request. Fine for most threat models. Worth knowing where the edge is.

What does a native zero-knowledge client add over rclone crypt?

It does the integration work rclone leaves to you, without giving up the "server sees only ciphertext" guarantee — assuming it's built honestly. The primitives are comparable, sometimes the same family. The difference is product, not cryptography. A native client like beebeeb ships its crypto in a shared Rust core, so the web app and the CLI encrypt files the same way rather than re-implementing the scheme per platform. What that actually buys you:

• Recovery that survives a lost password. A BIP39 mnemonic generated at signup re-derives your keys. Zero-knowledge still holds — beebeeb can't produce the phrase for you — but a deterministic backup beats a config file you have to babysit.
• Encrypted sharing that's actually a feature. Send a single file with an expiry, a passphrase, and a revoke button, without handing your whole vault's key to one recipient.
• Server-side conveniences that don't break the model. Encrypted-but-browsable file lists, thumbnails, file versioning (recent versions, retention configurable), file requests, and WebDAV through the CLI. You stop being the integrator.

How the encryption actually compares

Notice the honest asymmetry on that last-but-one row. rclone is open source end to end and you run the whole thing — a real advantage if your trust model demands inspecting every link in the chain. beebeeb's product clients are open source (the code that ever touches your plaintext), but the server is not. If "I run all of it myself" is non-negotiable, rclone wins that point outright, and pretending otherwise would be dishonest.

So which should you use?

Reach for rclone crypt when you already own a bucket, you're comfortable owning key management, and the job is unattended backup or a server-to-server pipe. It's the better tool there, and it's free.

Reach for a native zero-knowledge client when the friction — recovery, sharing with people who've never heard of a config file, previews on a phone — costs you more than it's worth to hand-roll. That's a team, a family, or anyone who wants the encryption without also being its operator.

The two aren't really rivals. They're the same guarantee at different altitudes — one a sharp tool, the other a finished product. If you want to feel where the native side saves you the integration tax, beebeeb's free 5 GB tier is zero-knowledge on the same model as the paid plans. Enough to walk the recovery flow and cut a share link without paying for the privilege.