The Cryptomator vault is protected with two 256 bit encryption keys which are generated when creating a new vault. These keys are not under control of the user. This is all very nice.
To provide a usable system, the encryption keys are further encrypted based on the user supplied password (with a salt etc) and stored in the cleartext file masterkey.cryptomator as the key encryption key, KEK. Also, due to this multi-step process, is it possible to change the user password/KEK without changing the 256 bit encryption keys.
The security of the system now depends on the user password, which must be “human-rememberable” or managed by a password manager, or stored somewhere safe. I assume that this password (often) will be less safe than the 256 bit encryption keys. Currently the KEK is stored together with the encrypted data, so that could be a nice attack vector. After gaining access to the encrypted vault, the key encryption keys come with it for free, including the KEK’s based on previous user passwords.
There is no strict need to store masterkey.cryptomator in the vault. If stored locally, the 256 bit encryption keys cannot be “degraded” with weaker user passwords/KEK’s, al least not until the locally kept KEK is also obtained.
Feature request: Optionally store masterkey.cryptomator locally.
I tend to disagree and here is why: If you want to go trough the trouble of choosing a different key directory you could simply choose a more secure password and it would be perfectly fine.
I would argue, that the average user who would not even be able to use a secure password would certainly be overwhelmed with the option of choosing another masterfile location and even less so understanding the implications. If you are a pro user it’s not that difficult to choose and manage a secure password.
So the feature you are suggesting sounds interesting on first glance, but it adds little benefit for noobs nor pros.
On the downside it would break compatibility and adding unnecessary complexity, so I strongly vote against it.
I don’t know the details of the key encryption, but if it is done properly (which I assume) it would be incredible difficult to decrypt the key even if the passphrase is less then 265 bits long.
Yeah, i agree. Probably leads to too much helpdesk trouble and no real benefit. Thanks for taking the time to point this out. (I’d like to add withdrawn to the subject line of this thread, but i fail to discover an option to edit it.)