Restic + rclone encryptions

Hi,

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.

Thanks in advance.

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.

tl;dr:

  • 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.
2 Likes

I just had an idea (maybe a wrong one).

If all files are pushed to the cloud but the keys this would make data almost impossible to crack. (this point has to be confirmed).

In that case the keys have to be store in a secure location in some ways. (could fit in QR code, hard copy, etc…)

The cloud scenario is mostly used as a last resort restauration. Copying all data from the cloud to a trusted storage and putting back the repo keys is an option (at leat for me).

IOW: save the keys, and push only data to untrusted area. I repeat this is for cold storage only.

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.)

2 Likes

One consideration is future restore operations: If you add further encryption at the rclone level then restic can’t directly restore from your cloud storage.

While this type of restore may not be a daily operation, it is exceedingly useful in a disaster recovery scenario.

That’s not totally true. You could rclone serve restic against the crypt backend and point restic at the local rclone.