Is it possible to keep the masterkey.cryptomator file offline?

This is a frequently asked question. Developers of the Cryptomator state that keeping the masterkey.cryptomator file offline does not add to the security. They mention, for example, that the encrypted master key is not more important than the encrypted data.

This is false. Putting the encrypted masterkey next to the encrypted data lowers the security, sometimes substantially. One obvious case is when te password is not strong enough. However, there are other reasons too, depending on the situation.

Why not providing a custom path? It should be one line of code.

If its just “one line of code”, why not make a contribution? Doesn’t sound to difficult. :slight_smile:


If the password is not strong enough, it was the deliberate choice of the user. Cryptomator can only motivate the user to use a strong password. An additional thought: If the user chooses a weak password, why should they care about the masterkey location?

That said, as @overheadhunter stated in Rename masterkey file to prevent attackers from deleting it, it is a good thing to let the user decide, but this needs a new vault format. And one does not easily introduce a new format! (as it can be seen from the switch from format 6 to 7^^)

Bizarre arguments on anything other than the issue itself!

A password is not a cryptographic key. For any password that contains less than 250 bits entropy, it’s better to keep the file offline. 250 bits is 38 diceware words. Most very good human-supplied passwords might include around 70 bits.

There are other important issues as well.

I could make a contribution, but you are already familiar with the code. The question was why not setting a $PATH.

That would make crytomator more secure!

You cannot compare a 256-bit cryptographic key and a X-bit password directly. You have to consider that the X-bit password derives the 256-bit cryptographic key using scrypt (a key derivation function), see https://docs.cryptomator.org/en/1.5/security/architecture/#masterkey-derivation.

Edit: If you are worried about a brute-force attempt, there are two ways to do that…

  1. Either brute-force a X-bit password that has to run through scrypt though, which adds a lot of computation!
  2. Or brute-force a 256-bit cryptographic key, which takes forever.

So yes, if the bit count of the password is too low, it’s bad. But it’s not true to say that a password has to be 256-bit in size in order to be as secure as a 256-bit cryptographic key.

I am familiar with these points. A key obtained from a password with X bits will have an entropy less than or equal to X bits, regardless of the key derivation function.

I mention another issue. Versioning on clouds. A vault on a cloud with versioning is secured by the security of the weakest master key (unless Cryptomator regenerates the final master key and re-encrypts data with that. I suppose it only re-encrypts the master key). So changing a password to something stronger is pointless.

Still other issues too.

There is really no reason to enforce this file on the cloud. That’s why GPG master keys are strongly gaurded, even though they are encrypted with users passwords. They are held offline, outside user’s computer. Masterkey.cryptomator should be treated as such.

A good practice in security i to assume users are not familiar with crypto, and do things properly on their behalf, rather than expecting them using 256 bits from password managers.

You have to consider that Cryptomator was designed to be “simple to use” and “without much configuration usable between many devices, including mobile devices”. It was a well-thought design choice to put the masterkey file inside the “vault folder” so that it’s instantly accessible from many devices.

Maybe my “edit” in my last post was too late but you don’t need a 256-bit password. I understand your suggestions and as you’ve seen, we had many discussions in the past and we’re making sure that we consider this issue from many angles.

You can’t just think about technical feasability. In that case, yes of course you could just define a custom path for the masterkey file and this could probably be “one line of code”.

But that’s not how designing and developing a product works. This would have many implications like:

  • How do I know which masterkey file belongs to which vault? Yes, you could solve it with an identifier or something like that but that’s not currently defined in the vault format. Yet another change.
  • How do I make sure that I have access on my mobile devices? You would probably need lengthy instructions on how to import the masterkey file from your Desktop computer to your mobile device (and vice versa). Yet another change.
  • How do I make sure that there are backups of the masterkey file? What if your computer/laptop breaks and the masterkey file is getting lost, even though your encrypted data is still in the cloud. That means they become useless? This is a hell of a big problem that can’t be just ignored, you have to think about usability as well.

There may be further points that I haven’t thought of spontaneously right now but I just wanted to say that it’s not “just one line of code”, which is an absurd statement for such a huge change.

5 Likes
© 2020 Skymatic GmbH • Privacy PolicyImpressum