I’m in process determining how I’m going to use ACD as my backup provider, and rclone seems to be the best option. The one question I have is the crypt functionality seems to be fairly new, and I’m curious if any type of auditing or security standardization was implemented when the crypt process was developed.
I ask because as I look at encryption solutions, I see there are also potential issues with EncFS when a cloud provider has historical files and you alter one, then alter back (Reference CryFS: https://www.cryfs.org/comparison#encfs which references the security audit: https://defuse.ca/audits/encfs.htm)
I’ve always used LUKS or Truecrypt in the past, so I’m new to file-by-file encryption.
The file encryption is based on NACL secretbox which was designed by DJB one of the world’s best known cryptographers and has very strong confidentiality and integrity. The weakest part is the file name encryption which is difficult to do and still preserve properties that rclone relies on.
There is a project to implement a higher security file name encryption mode here: https://github.com/ncw/rclone/issues/637 which will tradeoff some speed and resilience for better encryption of the file names. The file data encryption won’t change though.
Thanks for the info! As I’m not a cryptographer by any stretch of the imagination, the only thing I can’t figure out from that write-up is if the time issue that exists with EncFS exists with Rclone. For instance, if you have a file that is encrypted with EncFS at 1PM, then you change the file, then change it back at 2PM, then an attacker who has access to both the 1PM file and the 2PM file can use the time difference to determine how the file is being encrypted and decrypt. Any idea if Rclone is vulnerable to this type of attack?
rclone will encrypt the file using a difference nonce. This is a 24 byte random number taken from your OS’s supply of random numbers. Only if those nonce’s match would you have that problem, and there is only a miniscule chance that these will match (1 in 6×10⁵⁷).
Making it so you could convert an existing one would be desirable but may not be possible depending on exactly what we decide to do with the high security file name encryption mode.
Sorry for the epic bump here, but are there any updates on this? Mostly asking because the issue is still open. I’m planning to start using rclone crypt for more sensitive files - What I currently do is to use a VeraCrypt container and upload that to the cloud every time. Currently this container is very small, so this is no big problem right now, but my process is a bit cumbersome.
I have seen all the improvements crypt has received in the last year or so, and I do use it for some files, but still hesitant to use it for overly sensitive files. Has it received much scrutiny in the past 6 months or so? Anywhere I could read the commentary?
I think the comments as above stand. The underlying data encryption is very secure.
The filename encryption is pretty secure, but has a weakness “filenames with the same name will encrypt the same” because it uses what is effectively a very wide ECB cipher block mode and doesn’t use a nonce because we require file names to have a unique mapping from plain to cipher text. Because the cipher is a wide cipher over the whole path element it doesn’t have the normal weakness of ECB mode unless you have identical path elements.
We haven’t made any progress on a more secure file name encryption mode.
Thanks for your response. That weakness is understandable and I’m not sure how you would go about it without trying to add more metadata to the encrypted filename, which would be a problem for remotes with path limits, but it is not a big deal for me, as long as an attacker can’t get the actual filename of a file in any way.