rclone Crypt on iPhone and Apple TV: How Cloud Media Streamer Decrypts Without a Server

ByPriya Nair

What rclone crypt actually does

rclone’s crypt remote isn’t a separate storage backend — it’s a wrapper. You point it at an existing remote (Google Drive, Dropbox, SFTP, whatever), and from that point on rclone encrypts everything before upload and decrypts after download. The cloud provider sees only encrypted blobs. They have no key.

Content encryption uses NaCl SecretBox: XSalsa20 as the stream cipher, Poly1305 for authentication. Files are split into 64 KiB chunks, each independently encrypted with its own nonce. The key derives from your passphrase via scrypt (N=16384, r=8, p=1), which makes key derivation memory-hard and expensive to brute-force. That’s a meaningfully different foundation from older tools that hash passwords with MD5 or SHA-1.

One thing people miss when setting up a crypt remote for the first time: file names and directory names can be encrypted too, independently of file contents. File names reveal a lot. Whether you encrypt them is a separate decision from encrypting the data itself.

The three filename encryption modes

When creating a crypt remote, rclone asks how to handle file names. The choice affects both security and real-world compatibility.

  • Standard — encrypts names with AES-256 in EME mode, then base32-encodes the result. Real encryption, but the output names are longer than the inputs. Cloud providers impose path length limits; names over roughly 143 characters can fail on OneDrive and Dropbox because of how they count UTF-16 code units internally. rclone added base32768 encoding as an alternative to pack more data per character for Unicode-aware backends.
  • Obfuscate — applies a rotation cipher to each character. Not encryption. The original name is recoverable without any key. It hides names from casual browsing, not from anyone who looks at the data deliberately.
  • Off — names stay as-is with a .bin extension appended. Directory structure is fully visible to the cloud provider.

Standard is the right choice for most privacy use cases. But if your library has long file names — detailed episode titles with year and resolution metadata baked in — test against your specific backend before committing a large collection.

How the app decrypts on-device

Cloud Media Streamer connects directly to the cloud backend with no intermediary server. The rclone crypt decryption happens locally, on the iPhone or Apple TV. The app reads encrypted chunks, decrypts each 64 KiB block as it arrives, and passes the plaintext stream to the appropriate player.

This is what makes seeking work. Each 64 KiB chunk is self-contained and independently authenticated. To jump to a point in the middle of an encrypted video, the app requests the chunk offsets covering that timestamp, decrypts just those blocks, and starts playback. No full-file download required.

Supported backends include Google Drive, Dropbox, OneDrive, pCloud, Mega, SFTP/SSH, WebDAV, Samba, KDrive, and Koofr. Beyond rclone crypt, the app handles Cryptomator and Encfs containers too — three encryption schemes with different key derivation and file structures, so the implementation covers meaningfully different ground.

Why skipping the Files app integration makes security sense

The developer explicitly chose not to integrate with the iOS Files app. That trades some convenience for a real security gain.

When an app registers as a Files provider extension, its decrypted data becomes accessible to any other app with Files access. iOS sandboxing isolates apps by default, but the Files app exists precisely to bridge that isolation for usability. That same bridge works against you when keeping decrypted content private is the entire point of the setup.

Staying inside the app sandbox means plaintext only exists in memory during active playback or viewing. It never lands on a filesystem location another app could reach. For someone whose threat model is a cloud provider they don’t fully trust, that design choice is consistent all the way through.

Practical setup notes before pointing it at your remote

A few things worth knowing before configuring the app against an existing rclone crypt remote.

You’ll need the password and salt that were used when the remote was originally created. In rclone’s config file these appear as password and password2. They’re stored in lightly obscured form using AES-CTR with a static key baked into rclone — not real encryption. The config file itself should have restrictive filesystem permissions; anyone who can read it can recover both values.

If you used obfuscate mode for file names, the app will browse and play everything correctly. But anyone with access to your cloud storage can read your original file names without your password. That may be an acceptable tradeoff depending on what you’re protecting.

Directory name encryption is a separate toggle from file name encryption in rclone. You can have encrypted file names sitting in readable directory paths, or have both encrypted. Worth confirming which combination your remote uses before browsing a large library through a new client.

The premium tier (priced at $19.99 at time of writing) unlocks rclone vault access along with file manipulation operations like rename, copy, and delete. Browsing, streaming, and reading encrypted remotes are available in the free version.

Sources


Similar Posts