Need help understanding the new vault format

Hey, so I was going through https://github.com/cryptomator/cryptofs/issues/95 to understand what is planned for vault format 8.
If I understand it correctly this allows for masterkey (which contains the scrypt params and wrapped encryption keys) to be stored somewhere else (which is great), but we will store vault.cryptomator in the folder to be synced to external sources.
Now this is the part that I’m a little confused the new vault.cryptomator, is the JWT token signed by the same masterkey which is used to encrypt the files? If so I want to understand why is that? why not derive another key from masterkey and use that to sign the JWT token?
My concern (which might be a little unfounded) is that signing with the same masterkey, in the very very unnlikely case someone figures out the signature which verifies the claim of token, it should still not lead to the actual masterkey which can be used to unencrypt the files.
Again my understanding could be very wrong, please feel free to correct me


Edit : Also just out of curiosity what was the issue with the older approach that others would follow such as storing the masterkey.cryptomator outside the folder, that seems like a simpler approach, why is this approach with a vault.cryptomator with signed master key preferred over just giving the user the option to store masterkey.cryptomator in some other directory (or a password mananger backend like you’re planning to do with the keepasxc backend)

1 Like

It is in fact very easy to “figures out the signature”: It is the last part of the JWT. But this is no problem: A signature is intended to be public, there is no risk in exposing it.

The whole purpose of the signature is to verify the authenticity of the signed message. You can not derive the key from a signature.

The old masterkey.cryptomator evolved over time. It started with just the parameters required during key derivation, but later we added vault configuration metadata. This was a design mistake which we corrected by splitting those parameters into two files:

  • vault.cryptomator contains (public) vault-related parameters
  • masterkey.cryptomator contains (public) key-related parameters

Among other things, the vault.cryptomator specifies where to get the key from (and it verifies that a given key matches the vault). For existing vaults this is always the masterkey.cryptomator file, however it allows other sources in the future.

So to answer your question: This new structure allows alternative key sources, which is a prerequisite for various long-standing feature requests (e.g. aforementioned alternative storage location without the risk of using a wrong key with the give vault).

2 Likes