Recommended Crytomator configuration and deployment

[ryan]

@overheadhunter

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.

Which process is responsible for the creating of the files? I would have thought the Cryptomator application would invoke the CreateFileA API.

@overheadhunter

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.

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.

Plaintext file (create hash) → Encrypt file (create hash) → decrypt (validate plaintext has) → finalize encryption.