Imagine the following use case: backup to a secure trusted server then push the repos to an untrusted cloud using rclone.
Since restic (which has been designed to store your data on untrusted location) is using scrypt which can be very extensive to crack, especially with a long repo password (see https://www.tarsnap.com/scrypt/scrypt.pdf). Would it make sense to also encrypt the repos with rclone while pushing them to the cloud or would it be overkill or would it introduce a flaw in some way?
In all scenarios of course the keys passwords have to be saved in a very secure location to prevent from turning your backups into a useless pile of bytes.
Sorry if this is a naive question but since I am not crypto expert it’s very difficult to evaluate the threat when pushing data to the cloud. On the other hand the could is a simple way to secure your data in case of fire or steal of computer. As usual if you don’t want people to peep to your data don’t send them out of your network. It’s always a trade off matter.
That depends on what you mean by “encrypt the repos with rclone.” Most popular backends (S3, B2, sftp) are already encrypted in transit. Removing in-transit encryption is a bad idea because it can expose the backend credentials.
If you are thinking of using rclone crypt to encrypt the data at rest, yeah, this is a bit pointless because restic already encrypts the data. You’d need to make sure that you are able to decrypt the data before restic would be able to use it.
Encryption in transit: probably already happening, and you want this to protect your credentials.
Encryption at rest: restic already encrypts the repository files. Extra encryption is redundant.
You can do that, but using a suitably long password has the same effect. Brute-forcing it will be entirely infeasible as I believe key stretching is employed to target 0.5 seconds or so of compute time per key decryption attempt. (@fd0 can clarify the specifics.)