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