Rclone Encrypt Google Drive

[Abigail Tyrie]

Aremote of type crypt does not access a storage systemdirectly, but instead wraps another remote, which in turn accessesthe storage system. This is similar to how alias,union, chunkerand a few others work. It makes the usage very flexible, as you canadd a layer, in this case an encryption layer, on top of any otherbackend, even in multiple layers. Rclone's functionalitycan be used as with any other remote, for example you canmount a crypt remote.

Accessing a storage system through a crypt remote realizes client-sideencryption, which makes it safe to keep your data in a location you donot trust will not get compromised.When working against the crypt remote, rclone will automaticallyencrypt (before uploading) and decrypt (after downloading) on your localsystem as needed on the fly, leaving the data encrypted at rest in thewrapped remote. If you access the storage system using an applicationother than rclone, or access the wrapped remote directly using rclone,there will not be any encryption/decryption: Downloading existing contentwill just give you the encrypted (scrambled) format, and anything youupload will not become encrypted.

The encryption is a secret-key encryption (also called symmetric key encryption)algorithm, where a password (or pass phrase) is used to generate real encryption key.The password can be supplied by user, or you may chose to let rclonegenerate one. It will be stored in the configuration file, in a lightly obscured form.If you are in an environment where you are not able to keep your configurationsecured, you should addconfiguration encryptionas protection. As long as you have this configuration file, you will be able todecrypt your data. Without the configuration file, as long as you rememberthe password (or keep it in a safe place), you can re-create the configurationand gain access to the existing data. You may also configure a correspondingremote in a different installation to access the same data.See below for guidance to changing password.

Encryption uses cryptographic salt,to permute the encryption key so that the same string may be encrypted indifferent ways. When configuring the crypt remote it is optional to enter a salt,or to let rclone generate a unique salt. If omitted, rclone uses a built-in unique string.Normally in cryptography, the salt is stored together with the encrypted content,and do not have to be memorized by the user. This is not the case in rclone,because rclone does not store any additional information on the remotes. Use ofcustom salt is effectively a second password that must be memorized.

File content encryption is performed usingNaCl SecretBox,based on XSalsa20 cipher and Poly1305 for integrity.Names (file- and directory names) are also encryptedby default, but this has some implications and is thereforepossible to be turned off.

Before configuring the crypt remote, check the underlying remote isworking. In this example the underlying remote is called remote.We will configure a path path within this remote to contain theencrypted content. Anything inside remote:path will be encryptedand anything outside will not.

When you are done you can use the crypt remote named secret justas you would with any other remote, e.g. rclone copy D:\docs secret:\docs,and rclone will encrypt and decrypt as needed on the fly.If you access the wrapped remote remote:path directly you will bypassthe encryption, and anything you read will be in encrypted form, andanything you write will be unencrypted. To avoid issues it is best toconfigure a dedicated path for encrypted content, and access itexclusively through a crypt remote.

Important The crypt password stored in rclone.conf is lightlyobscured. That only protects it from cursory inspection. It is notsecure unless configuration encryption of rclone.conf is specified.

You may also specify a local filesystem path, such as/path/to/dir on Linux, C:\path\to\dir on Windows. By creatinga crypt remote pointing to such a local filesystem path, you canuse rclone as a utility for pure local file encryption, for exampleto keep encrypted files on a removable USB drive.

Note: A string which do not contain a : will by rclone be treatedas a relative path in the local filesystem. For example, if you enterthe name remote without the trailing :, it will be treated asa subdirectory of the current directory with name "remote".

If a path remote:path/to/dir is specified, rclone stores encryptedfiles in path/to/dir on the remote. With file name encryption, filessaved to secret:subdir/subfile are stored in the unencrypted pathpath/to/dir but the subdir/subpath element is encrypted.

If you intend to use the wrapped remote both directly for keepingunencrypted content, as well as through a crypt remote for encryptedcontent, it is recommended to point the crypt remote to a separatedirectory within the wrapped remote. If you use a bucket-based storagesystem (e.g. Swift, S3, Google Compute Storage, B2) it is generallyadvisable to wrap the crypt remote around a specific bucket (s3:bucket).If wrapping around the entire root of the storage (s3:), and use theoptional file name encryption, rclone will encrypt the bucket name.

Should the password, or the configuration file containing a lightly obscuredform of the password, be compromised, you need to re-encrypt your data witha new password. Since rclone uses secret-key encryption, where the encryptionkey is generated directly from the password kept on the client, it is notpossible to change the password/key of already encrypted content. Just changingthe password configured for an existing crypt remote means you will no longerable to decrypt any of the previously encrypted content. The only possibilityis to re-upload everything via a crypt remote configured with your new password.

This is a simple "rotate" of the filename, with each file having a rotdistance based on the filename. Rclone stores the distance at thebeginning of the filename. A file called "hello" may become "53.jgnnq".

Obfuscation is not a strong encryption of filenames, but hindersautomated scanning tools picking up on filename patterns. It is anintermediate between "off" and "standard" which allows for longer pathsegment names.

Cloud storage systems have limits on file name length andtotal path length which rclone is more likely to breach using"Standard" file name encryption. Where file names are 143 or fewercharacters in length issues should not be encountered, irrespective ofcloud storage provider.

An experimental advanced option filename_encoding is now provided toaddress this problem to a certain degree.For cloud storage systems with case sensitive file names (e.g. Google Drive),base64 can be used to reduce file name length.For cloud storage systems using UTF-16 to store file names internally(e.g. OneDrive, Dropbox, Box), base32768 can be used to drastically reducefile name length.

This can be used, for example, to change file name encryption typewithout re-uploading all the data. Just make two crypt backendspointing to two different directories with the single changedparameter and use rclone move to move the files between the cryptremotes.

(By default, rclone will just log a NOTICE and continue as normal.)This can happen if encrypted and unencrypted files are stored in the samedirectory (which is not recommended.) It may also indicate a more seriousproblem that should be investigated.

For example, let's say you have your original remote at remote: withthe encrypted version at eremote: with path remote:crypt. Youwould then set up the new remote remote2: and then the encryptedversion eremote2: with path remote2:crypt using the same passwordsas eremote:.

Each chunk will contain 64 KiB of data, except for the last one whichmay have less data. The data chunk is in standard NaCl SecretBoxformat. SecretBox uses XSalsa20 and Poly1305 to encrypt andauthenticate messages.

64k chunk size was chosen as the best performing chunk size (theauthenticator takes too much time below this and the performance dropsoff due to cache effects above this). Note that these chunks arebuffered in memory so they can't be too big.

I plan to use rclone to sync my cloud folder and this is probably a silly question, sorry if it is so.

I see this post: ..t/is-rclone-encrypted-or-not/11855 on security and encryption, but could anyone clarify whether the traffic from my computer to cloud and vice versa is safe?

yeah, it is confusing to understand and confusing to explain.

again, two separate issues. secure during transit and secure at rest.

rclone is always secure during transit.

for copying files in transit, rclone uses encryption, same as any web browser does.

for example, when you login to this forum, your username and password are crypted, all data transferred is encrypted. for when you login to your bank,

I hope this has not already been answered but I have looked around for about a week without any luck. I would like to know if it is possible to Encrypt existing contents on GDrive. If it is not possible, can I created another directory in my gdrive and encrypt that "gdrive:/encrypted" and do something like

Thanks @asdffdsa for the assistance. That seems to do the trick except now I am hitting the 403 User Rate Limit. I have a gigabit upload so i got a little too excited and hammered through 750 in a matter of hours lol. I need to find the sweet spot to stay under that 750GB per day limit.

Still going through the forum looking it to see how to prevent copying existing files. I see some people saying don't use --ignore-existing since rclone copy is smart enough to do so while others are saying neither works.

I already copied about 750GB worth of contents. I ended the process due to the 403 user rate limit. I didn't want to end up getting banned. Next time I restart the copy after the limit has been cleared, I don't want the copy process to go back and recopy files that were already copied.

The problem is: he has had all uploads encrypted with rclone and uses rclone mount. So far I have always copied files from one Drive user to another with the help of a self-made Google Apps Script. This does not copy physically, but only virtually. However, the owner of this virtual copy actually becomes the user who executed the app. This copy is not affected if the original is deleted or similar. This solution had the advantage that no traffic was generated and approx. 100 GB / minute (the larger the individual files, the more; the smaller, the more less) were copied (still, each copied file counted towards the 24-hour limit of 750 GB).

3a8082e126