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?