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.