How to correctly setup the salt for the crypt remote?

Help and Support
1

Hi there,
I just started using rclone a few days ago and am not quite familiar with the encryption/cryptography thing.
I am a little bit confused about how to set the salt for the crypt remote.

From the result I got from a small experiment and the results of searching on this forum, it seems that one must provide the same pair of password and salt to successfully encrypt and then decrypt a file via the crypt remote.
Does that mean a salt is effectively another password that the user must memorize/write it down in case the rclone config may be corrupted or lost?

Furthermore, I am wondering what is the difference in the safety aspect between a) providing a really long password (say, 256 bit or 32 ASCII characters) and b) providing a not-so-long password + a not-so-long salt (say, 128 bits for each).
Will the latter one be safer than the former one, or the opposite?

2

Yes that is correct.

You don’t have to use a salt, but it is recommended.

The salt is all about stopping dictionary attacks on your password. So a 256 bit password would be more secure than 128 password + 128 bit salt.

3

Thanks for the explanation!

The salt is all about stopping dictionary attacks on your password. So a 256 bit password would be more secure than 128 password + 128 bit salt.

Is the former one more secure because the rclone adds a default salt to it and the default salt (hopefully) never gets exposed?

If that is the case, I am curious about would it be beneficial and technically feasible and practical to expand the default salt into a set of default salts? (just curious, not suggesting for a new feature)
That is, when setting up a crypt remote, a user can choose to provide only a custom password and let the system to pick a salt randomly from a pool (the pool never changes across all versions of rclone, or only expands in later versions).
rclone then works as usual, encrypt and decrypt files with the stored password and salt.

The (possible?) benefits come when a) the user loses the crypt remote configuration or b) an attacker tries to breach the encrypted remote.

a) When the user loses the remote configuration, the system can easily restore it by asking the correct password from the user and try it along with each salt in the pool, as long the pool size is reasonably small (like several thousands or a million).
The good thing about this is that a user do not need to backup the rclone configuration and take an extra risk of letting bad guys get it.

b) When an attacker tries to breach the encrypted remote, the size of the possible password set is multiplied the number of salts in the pool.
So given the same efforts made for memorizing things, say, 256 bits password + system decided salt V.S. 128 bits password + 128 bits salt (still 256 bits to be memorized in total), the former seems to be safer, even when the system salt pool somehow goes public.

4

Just a small note - I meant to comment about this since the encrypted remotes were introduced but I didn’t know at the time there is a forum :slight_smile:

The way the salt is used in rclone is somehow non-standard and potentially dangerous. Normally you don’t need to remember your salt, just the password - the salt is either stored directly (like in /etc/shadow) or I guess can be brute-forced as mentioned above. If you need the salt to get to your data it’s not salt but a second key which you really otherwise no-data-for-you!

1 Like
5

That could be done. It isn’t crypto best practice though! Your reasoning is sound in a) and b) though.

1 Like
6

The salt is used when turning your password into a key for decryption.

rclone could store it on the cloud provider rather than the config file, however rclone doesn’t store any config in the cloud provider in general.

That does make it effectively like another password. If you are using a good enough password (not likely to be in any dictionaries - eg a random 128 bit one) then you don’t need to use the salt.

1 Like
7

Actually after some googling I found that the salt pool idea (not surprisingly) has already been used, though it is called pepper (wiki page here).

It is good to know that the salt pool idea is practical for a backup system like rclone.

I was thinking if using a long password + a default salt (or a salt pool) is always safer than a custom password + a salt with equal length, then why not forcing all users to only using the former one.
But on a second thought, I realized that letting users to freely combine the password and salt is ultimately safer for all users because it makes attackers hard to narrow down the search space for the password; they must try out all possibilities.
So using custom password + salt itself is not making the encrypted files safer than using only a long password do, but the possibility of a user may choose to do so surely causes some lovely troubles to the attackers.:grinning:

8

I don’t know if this will help or obfuscate the situation but…

In general, with cryptography, “salts” are used to permute the encryption key so that the same string may be encrypted in different ways. So if the string “hello” was to be encrypted then a random salt should be picked and the result used to encrypt the string. Next time you encrypt the word “hello” you will pick a different random salt and so get a different encrypted string. If you had a 64bit salt then you would have 2^64 different ways of encrypting the string. The idea is to make “rainbow tables” hard to generate

For example, to encrypt the word “hello” using AES-256 with the key “mykey” and a random salt, we can see the result is different each time:

$ echo hello | openssl enc -aes-256-ctr -salt -a -k mykey     
U2FsdGVkX19Q6lRUSYI2zfDCn7E/+Q==

$ echo hello | openssl enc -aes-256-ctr -salt -a -k mykey
U2FsdGVkX19OrFlqLZvjOwpSqfkbxQ==

Now, of course, the decryption routine needs to know the salt in order to decrypt it so the salt is stored with the encrypted password (it’s hiding in the base64 output). This isn’t a problem because the strength of the encryption is in the AES algorithm; the salt is there to prevent pre-generated (“rainbow”) tables from being used.

Now with rclone, we need to somehow protect the “mykey”. This is stored in the config file, in an “obfusacated” form. If someone got hold of your config file then they have access to your encryption key. If you’re worried about this then you can encrypt the config file with a password you type in (or put in an environment variable for scripting).

So now we come to how rclone uses salts… effectively every file in a crypt’d remote uses the same salt. From a pure crypto perspective this is weak, but it is mitigated by using a strong encryption key. So always set up a minimum of 128bit (pref 256bit) random encryption key.

Why does rclone use a weak “fixed salt” process? So that it becomes possible to compare files without needing to download the whole thing; if the same file contents were encrypted differently every time then it’d be impossible to determine if a file had changed by checksums alone.

So do we need to change salts? If you don’t pick a salt then your files, Bob’s files, Alice’s files… they’ll all have the same salt. Is this a risk? Not really, as long as you pick a strong encryption key… which you should be doing, anyway!

Because the salt is fixed per crypt remote it doesn’t need to be saved with the data, which means it’s also slightly beneficial as a secondary password, but that’s not really what salts are meant to be used for.

Note that the salt is also stored in the same configuration file as the encryption key (and not with the data), so the weak point is still your config file in all of this. If you lose your config file then anyone can get at and decrypt your data.

Conclusion: Always use a strong encryption key. Use a salt if you wish as an addition to, but not instead of, a strong encryption key.

1 Like
9

Thanks for the detailed explanation. That helps a lot!