In a bid to backup information securely to online backup providers such as DropBox, I’m currently evaluating the setup of Cryptomator.
To ensure an optimal deployment, it would be valuable to have guidance on its configuration. The lay of of the land is as follows;
Windows 10 and Linux (Ubuntu derivatives) devices as well as mobile devices Android and iOS.
Data stored locally and externally i.e. hard drives.
Total collection of data exceeds 5TB and is an amalgamation of small (10KB), medium (1MB) and large files(1GB to 1TB). These vary from documents such as PDFs, design files to media files photos, videos. These also include archives such as zip and 7zip including ISOs and executables.
The directories and files have both short and long names.
The directories and files have varying permissions.
The primary focus is to backup data from local and external drives on PCs and laptops. The next phase is to migrate data from Android and iOS.
Objectives.
Performance - The ability to encrypt the files and commit them should be performant.
Integrity - The integrity of the files should be maintained i.e. file corruption to be avoided, retaining file permissions and the like.
Availability - The data should be accessible from any device.
Questions
What is the recommended Crytomator configuration?
Are there any prerequisites? If yes, what are these and what needs to be considered?
What limitations should be considered?
Any other suggestions or things to look out for?
Are there any costs? My understanding is that the Crytomator application needs to be purchased for Android and iOS. Is this a single license for each device? Can multiple be purchased? If yes, is there volume licensing? Is there a commercial support model for the paid version?
I prefer the WebDAV File-System, other prefer dokany as filesystem. As you want to deal with very large files, You must use dokany (which is the standard configuration), as WebDAV comes with some limitations. Other than that there is no reccomendation in copnfiguration. It depends strongly on your needs and usage. Just try it
no.
Cryptomator itself has no limitations. The limits are primary your disc space and your online storage space.
The iOS app and the Android App needs to be purchased. The desctop apps are provided for free. The licensing is typical for iOS and Android. You purchase once per Appe and/or Google Account. If you have more than one device connected with this account, feel free to use the cryptomator apps on all these devices.
Not as far as I know. If you are looking for Enterprise solutions, please check this page Enterprise
If you are looking for a enterprise server solution, please check this https://server.cryptomator.org/en/
In former versions there were some problems with very long file names under windows, but that is solved with dokany. No limits regarding file size with dokany either. Only with windows WebDAV. All metadata of files inside the vault will be preserved. Just give it a try and check if you want to.
I assume that unicode is fully supported. Would this be a fair assumption?
As to the availability of metadata, is the only metadata that is exposed the following?
access, modification, and creation timestamp of files and folders,
number of files and folders in a vault and in the folders, and
size of the stored files.
Can this (metadata) be restricted and/or removed?
I am assuming that there is no limit to the size of the vault regardless if it’s a local disk or an external disk. Would this be correct?
When setting up a new vault, what is the recommendation when transferring large volumes of files (in excess of hundreds of thousands)? For example, should these be copied across in a particular method? If yes, what would this be?
What is the risk of corruption and is there the option to validate file integrity e.g. checksum?
Correct. You can not “remove” this metadata. Cryptomator is made for the cloud and the cloud sync tools need those timestamps in order to know what to sync. If you want to encrypt stuff for local use, rather use Veracrypt or similar tools, that will hide those metadata.
If any bit of a file flips, the file is can no longer be decrypted (but it won’t affect other files in the vault). There are checksums in various places (and they are required to prevent accidental decryption of tampered ciphertexts - which would allow some attacks). However, it is possible to recover the file as a whole or at least parts of the file depending on the position of the damaged byte. For the exact probabilities, see this post.
Thanks @overheadhunter. If files include characters that are not yet supported by Cryptomator, does the application fail gracefully? For example, if I were to copy 1000 files and 100 of them had unsuppported characters, are the remaining files (900) encrypted and written successfully? If yes, would Cryptomator log the entries for the 100 files that had failed to be copied so that I could change the filenames and it would resume copying them?
What could cause the corruption? For instance, should files be copied using a specific method? Should the files be copied using a specific tool that would perform these tasks to detect corruption and/or failures? Would the checksums identify corrupted files?
Nope, Cryptomator doesn’t log filenames that failed, because the failure happens before the filename even reaches Cryptomator. For Cryptomator filenames are just byte sequences - it doesn’t matter which characters are in them. All names are supported. However it seems like some some 3rd party systems don’t trust the filesystem to support full unicode. Maybe we can somehow improve this by setting a flag to signify this ability. I don’t know.
Bit rotting, attempts to edit ciphertext files with other applications, … Could be anything. Cryptomator protects the confidentiality and verifies the integrity, but it can not guarantee the integrity. For this use case you need backups.
Yes. Any change to a ciphertext file will cause Cryptomator to report an error when trying to access said file. You will see the file in the directory listing but you can’t open it.
Interesting as I would have thought that Cryptomator is defining a filesystem of its own at the point of creating a container. If yes, the issue of non-recognized characters would be triggered by the filesystem.
If there is a failure in the meanwhile does it result in a complete failure of the file transfer? For example, if 1000 files are being copied and 500 of successfully committed, the following sequence i.e 501 fails, will the remaining 499 continue or will these stop?
To clarify, does Cryptomator verify the integrity pre and post encryption. As to the assurance of integrity and backups, what would you recommend whilst maintaining confidentiality?
Does these validation occur pre and post encryption to ensure the integrity of the file?
Cryptomator provides the file system and returns error codes to the process that attempts to access it. In the case of unicode filenames, said filename is not even passed by the process to the filesystem. I.e. the process decides to show an error before even attempting to create the file. In that case I can not tell you how said process will proceed with further files. Cryptomator itself is capable of using unicode chars in filenames, as you can see in the iOS app.
Cryptomator uses an encrypt-then-mac approach. I.e. it creates a checksum over the ciphertext and metadata. Cryptomator never creates any hash or mac over the cleartext file contents. Or to use your words: It creates a checksum post encryption and verifies it pre decryption. As long as the CPU doesn’t create bit errors, the cleartext will therefore be undamaged, whenever the ciphertext is, too. Of course Cryptomator can not verify if a cleartext is meaningful, as it can not know all well-formed data formats and doesn’t care about file types.
That’s a too broad question that I would recommend to discuss in a separate topic. It vastly depends on your setup, too.
Which process is responsible for the creating of the files? I would have thought the Cryptomator application would invoke the CreateFileA API.
Is there any reason that Cryptomator does not create and validate a hash for cleartext files? In what scenarios would the CPU create bit errors? I wouldn’t expected Cryptomator to validate semantic meaning. I may be missing the implications however I would thought it would be possible to do the following. It may result in additional time however maybe Cryptomator could provide the option to either bypass the check, enforce the check for all files or sample files.
If you use Word, it is Word. If you use Excel, it is Excel. If you just browse around in Windows Explorer, it is Windows Explorer.
Cryptomator implements an API that is provided by Dokany and consumed by the Windows Kernel, that in turn provides an I/O API for user-level applications.
If Word asks Windows to create a file, Windows will ask Dokany and Dokany will ask Cryptomator to do so. If Cryptomator doesn’t like the idea (e.g. because a file with this name already exists), it will throw an error that propagates upwards to Dokany, the Windows Kernel and finally to Word. If, however, the Windows Kernel decides to throw an error, neither Dokany nor Cryptomator will ever learn about the attempt to create a file. Neither are they informed how the Word deals with an error.
Because it is not necessary. If the ciphertext is intact, the cleartext will be. The only exception would be if decryption would produce invalid output. Which can’t happen unless your CPU is broken. Why would it be broken? Because you smashed an axe into your PC. That’s pretty much the only scenario, as all parameters are checked before decryption.
This is necessarily true if there is a failure by another inter-dependent component such as the Windows kernel that may result in a corrupted file at the point of creation for example and assuming I have understood you correctly i.e. File → Application → Cryptomator → Dokan → Windows Kernel
Good point but there are a whole lot of other things, too:
failing memory chips on either side (presumably the cloud system use ECC memory or other integrity checks, but given how cheap cloud storage is I do have some doubts)
bugs in the network stack that allow transmission of errors to be undetected in rare cases
bugs in disk error recovery coupled with a failing disk.
Admittedly all of these things are quite rare but they do occur. The only protection against loss of data is full redundancy (e.g. backing up your files to multiple cloud systems, ideally using different backup software). And even that is an imperfect solution.
Correct. And encryption doesn’t help against data losses, it only guarantees the privacy of a file.
And in all of your examples Cryptomator would notice the damaged ciphertext. An additional checksum of the cleartext would not add any further information unless the damage happens after calculating said checksum and before encrypting the cleartext (i.e. errors in very short-lived caches).
