I want to use rclone backend to move around restic repositories. The rclone crypt backend is interesting because it adds another layer of encryption in addition to moving operations. This shall protect against restic zero days, bugs or flaws not caught by the developers.
The replacement of GCM with Poly135 authentication in restic is certainly nonstandard. Is there a reason for not using the standard encrypted authentication AES-GCM or ChaCha20-Poly135?
Restic apparently is not audited yet (though people have said good things about its encryption).
In any case, rclone adds very little overhead and why not! I get the benefit of the well-reviewed NACL secret box encryption library.
Is it an acceptable practice to use rclone crypt remote? I am thinking of potential drawbacks of this approach, eg, potential fragility, edge cases, aborted operations, added complexity, errors, etc., leading to repository corruption.
I don’t know how restic interacts with rclone’s crypt. Are restic and rclone layers completely independent?
I’ve been doing exactly this for months now in three repos and one cloud backend without problems.
Performance: I don’t seem to be bottlenecked by CPU with the dual encryption layers and no aes-ni (not sure if either layer uses that). I’ll post my CPU load, available and achieved bandwidth later.
I’d be interested in hearing about potential pitfalls as well.
At the time the code was written (in 2014), it was the fastest way to do authenticated encryption in Go. It benefits from native instructions built into many CPUs to encrypt/decrypt with AES, and the fast speed achievable with Poly1305. It was before Go’s GCM implementation got fast.
If I were to reimplement the crypto I’d use something else.
AES-GCM is error prone, but still better than the current somewhat questionable AES 256 CTR-Poly1305, which is a rare combination and hasn’t received much cryptanalysis.
The ChaCha20-Poly135 primitive from the standard secret box from the NACL library might be the way to go, as far as the security is concerned.
Rclone uses XSalsa20-Poly135 (closely related to ChaCha), though apparently filename encryption needs improvement. However, very few people combine restic and rclone encryption.
I am not sure about AES speed ups over ChaCha, but today the CPU is hardly a bottleneck. So instead of updating to AES-GCM, you may want to consider ChaCha20-Poly135.
x----------------
Update: Apparently Flippo says ChaCha is faster in Go implementation!
While we may opt to use a more standard crypto primitive, we will for sure not make it configurable.
It turned out time and time again that so-called “cryptographic agility” leads to complex and error prone code, here’s an excellent article about it which describes the issues it caused within TLS: ImperialViolet - Cryptographic Agility
Agreed, there is no point in supporting many choices just for the sake of it. On the other hand, in case of restic it’s not about reimplementing those algorithms, they are both maintained by Go. Plus, if you’re contemplating switching to another algorithm and want to stay compatible with existing repos you’d need to support both algorithms anyways. In cases where both of the algorithms have clear advantages over one another (e.g., one being significantly fast on CPUs which AES-NI support and the other being faster on CPUs without) it could well make sense to expose that switch. JM2C.
I still do this regularly. I don’t see a difference between encrypting at one layer vs two layers (the layers are rclone and restic). I get about 300MB/s uploading on both.
Restores work fine. I recently had to restore onto a blank box, and didn’t run into configuration or any other problem related to encryption at either level.
FYI, my repo is medium sized: under 100GB, and a mix of files from a couple kBs to several GBs.
