Integrity of rclone ENCRYPT

ncw · January 2, 2021, 11:25am

No, the crypt backend does a version of rclone cryptcheck while it is uploading files so it should notice corruptions at that point.

This was done as part of

github.com/rclone/rclone

crypt: cryptcheck uploads and downloads on the fly

opened 10:33AM - 10 May 18 UTC

ncw

enhancement Remote: Crypt hashing

Currently the crypt backend does not return hashes since the wrapped remote will… only have hashes of the encrypted data which are useless for comparing. This means that when rclone does uploads and downloads via crypt, it isn't checking the hash of the source and destination like it usually does. We have `rclone cryptcheck` to do an after the fact verification, but it is possible to do a verification on the fly, in the crypt backend: In the crypt backend * On upload * before transfer pick a hash supported by the wrapped remote * encrypt then hash the data * at the end of the transfer check the hash of the encrypted data matches the hash returned by the wrapped remote * On download * before transfer pick hash supported by the wrapped remote * hash then decrypt the data * at the end of the transfer check the hash of the encrypted data matches the hash returned by the wrapped remote * if any seeks happen, then disable the hashing. This will have quite low performance overhead as we will just be hashing the data one more time. See: #2290 for background