What about RClone?

Rclone is a popular command line tool to sync and manage files on a cloud storage. It supports a wide variety of backends (referred to as remotes) and has support for a crypt remote that encrypts the files before storing them in the target backend.

For this evaluation, I only looked at the local file system as the backend, however, it still applies to any other configured backend. The configuration steps are detailed in the crypt page. The defaults are good and turn on both filename and directory name encryption, it also includes an option to generate the passwords (encryption and salt) from /dev/urandom for the user. The filename and directory name length can’t be larger than 143 characters which is smaller than the other solutions we looked at.

For file encryption, it uses NaCl’s SecretBox, which uses XSalsa20 to encrypt the messages, and Poly1305 to authenticate them. The key derived is 256 bit key derived from the encryption password using scrypt and the salt password as the salt.

For filename / directory encryption, the name is segmented to different chunks based on the / separator, each chunk is padded using PKCS#7 before being encrypted using EME. There’s no mention of how the chunks are combined, but the result is base32 encoded (RFC4648 version).

I found their documentation of this feature surprising, they go into details in some areas and why the made certain choices but without writing the scheme in a complete way where you don’t have to dig into the code to figure out the missing details. I also couldn’t find any security audits. Overall, the previous solutions did a much better job with explaining their architecture and security and I’d recommend them over rclone since they’re focused only on file encryption/decryption and not general cloud storage syncing.

I might flesh out the details of their crypto implementation and scheme in a new post.