I planned on using rclone for encrypted backup to Google Drive but I’m worried about how I would verify that my data wasn’t tampered with. If my local backup were destroyed or severely damaged I wouldn’t have anything to compare with. Does rclone have any setup for ensuring that my data isn’t tampered with?
If you want to compare the files you have with the ones uploaded to make sure they’re identical rclone has check/cryptcheck. If you want to keep an external reference I would use hashdeep (for linux) or fsum (for windows) to generate a list with checksums (of the originals) whenever you feel like it. That would be a smallish file, you can store it anywhere, email it to yourself, etc. Then whatever you recover can be checked against that list.
Each encrypted block (about 64k) contains a very strong authenticator. This makes it impossible to alter data without rclone noticing.
rclone can do this too! rclone md5sum or rclone sha1sum and that is quite a good solution for backups. I often do this to the root of a backup tree and save it to the remote.
Shouldn’t this be changed to sha256sum by now? I thought sha1 was broken and numerous people proved you could create collisions, two files that have the same hash but are actually different files.
rclone supports the hashes the remote providers support and none of them have supported sha256 yet, except dropbox with their content hash which is a block based sha256. You can do that with rclone with rclone dbhashsum or use rclone hashsum for the generic hasher.
sha1 (and md5) are certainly good enough to detect corruptions though which is what the providers use them for. As you note both are now no longer considered crypto secure. I think all the attacks on MD5 and SHA1 are collision attacks which means that your attacker needed to have given you document A which he then exchanges for document B with the same hash. It isn’t computationally feasible to make a document with the same hash given any random document (a pre-image attack)
rclone uses Poly1305 as an authenticator for its encrypted data which is considered to be a state of the art authenticator.
Last couple of questions
So you run this on the local backup before pushing to the cloud and since you saved this list to the root of the backup rclone just automatically picks this file up and sends it to the cloud?
So basically if I think my encryption password AND the cloud account password was compromised. I’m screwed for data integrity? At this point I can no longer be certain my files were not compromised?
EDIT: I guess I can check history since a lot of online providers will tell me if something was edited.
Yes that’s right.
You’ll need something stored elsewhere. That file full of checksums for instance - if you had that stored somewhere else then you could be certain that nothing was was tampered with.
Unless it is the provider (or the provider on behalf of the authorities)…
WOW. This is really, really, really good. I’ve been actually used with symmetrical ciphers in configs like bitlocker or truecrypt where there’s no extra checksum of any kind (never mind in any way vaguely crypto-secure) - understandably they want to have it one block = one block (any extra data has to be padded some place and it can create big trouble). But with this rclone becomes the tool of choice even to save local files, safe from (undetected) corruption and accessible from every platform. Sure, some files or folders might still go missing completely (making a note of the total size, another great feature of rclone Rclone is great - size command is unique AFAIK! Really! helps as well, not against malicious attacks replacing files with some of the same (total) size but in all “normal” situations).
Yes the new thinking in the crypto world is that ciphers shouldn’t be used without authenticators so called AEAD.
Glad you are enjoying rclone!
Thank you for the help.
i use shirtware “corz checksum”
it produce.1 .hash per file.
so when u move.file, just move 2 icon is ok.
possible later to add feature of 1 .md5 per file? that make more sense.thx
dear ncw thx for rclone.
yet, i do strongly think using a 3rd party
encryption is more reasonable.
if i only use google drive and rclone,
yeah google only see rubbish, but rclone
see my plain text. yes rclone is open source i know and i do trust ncw.
but…how about try cppcryptfs (my choice after 3 month of testing), others include encfs,.cryptomator etc.(all open source)
in that case.
plain text --cppcryptfs–> encrypted txt and then
pass to rclone for upload to google drive.
google and rclone only see encrypted text.
cppcrypts can be used without network.
so if somone is serious, one should use the 3rd party, open source, cloud encryption method.
ps ncw again i love rclone, pls dont mind for that.
ps: pls google gocryptfs compare.
cppcryptfs is a c++ clone of it.
all open source. with the .exe signed on windows. with pgp signature.
these cloud enCryption are file based,
unlike truecrypt with fixed folder size.
btw tc is another great foss.
like rclone