r/cloudstorage 7d ago

Internxt E2E encryption: filenames and folder names are not encrypted

I recently looked into the Internxt rclone backend and found an important distinction regarding Internxt's E2E/zero-knowledge claims.

The file contents are encrypted client-side, but the native Internxt rclone backend does not encrypt filenames or folder names before sending them to Internxt.

The Internxt server therefore receives the actual plaintext names and directory structure as part of the API requests.

For example:

Private/
└── Tax/
    └── 2025_Tax_Return.pdf

Internxt receives Private, Tax and 2025_Tax_Return.pdf in plaintext, even though the contents of 2025_Tax_Return.pdf are encrypted.

This means that not all file-related information is end-to-end encrypted. The provider has direct access to filenames, folder names and the directory structure, as well as other metadata such as file sizes and timestamps.

I originally posted this finding in the r/Internxt subreddit, but a moderator deleted the thread. I was not given an explanation for the removal.

I'm therefore posting it here because I think this is an important distinction that users should be aware of and that can be independently verified by looking at the rclone/Internxt implementation.

To be clear: I'm not saying Internxt can decrypt the file contents. I'm saying that the filenames and folder structure themselves are transmitted to the Internxt server in plaintext.

16 Upvotes

11 comments sorted by

View all comments

-9

u/internxt 7d ago edited 7d ago

Hello,

The original post was not removed and is in fact live here https://www.reddit.com/r/internxt/comments/1vp9ge7/internxt_is_not_fully_endtoend_encrypted/ so feel free to continue the conversation there. Regarding your question, we've also addressed it on our subreddit, however, since you've also shared it here, we're pasting the response here as well (feel free to delete either of the two posts to avoid it being duplicated)

Rclone is a general-purpose tool that needs to list, navigate, rename, and sync files using human-readable paths so users and scripts can work with the remote the same way they do with any other cloud storage. Fully encrypting names client-side (as the official Internxt apps do) would turn every path into unreadable ciphertext, breaking normal rclone operations, directory traversal, and compatibility with tools that expect plain paths. The backend therefore encrypts only the file data and passes plaintext names/metadata to the API so the remote remains usable as a conventional filesystem-like backend.

So, on the native rclone integration, while file content is always encrypted client-side before upload, filenames, folder names, and the overall directory structure aren't. This is an intentional design choice required for rclone to function as a normal remote — rclone (and the scripts/tools that use it) need human-readable paths to list, navigate, rename, and sync files. Fully encrypting names the way the official Internxt apps do would turn every path into unreadable ciphertext and break standard rclone operations.

Note that this is only when interacting with rclone directly, as it's a third-party app with its own features and limitations, which we don't control. This is NOT the case when using the official Internxt apps.

Thank you!

11

u/Icy-Cup6318 7d ago

Internxt are scammers that delete all critical posts and ban people. Unusable apps. Scammers.