Pass in external masterkey instead of reading it from vault dir

[overheadhunter]

If masterkey.cryptomator (or whatever it is called since version 1.1.0) is not located in the vault directory, there must be some other possibility to pass in the required data, such as a plain byte array.

This is needed in order to support storing the masterkey outside the vault.

[markuskreusch]

@overheadhunter Would either recommend to pass in a path (because the masterkey must also be written on initial creation of a cryptofs) or some object which may either read or receive and persist the encrypted masterkey contents somehow.

Would prefer the second approach and provide a default implementation operating on a path.

[overheadhunter]

Agree, so something like

interface MasterkeyFile {
  byte[] load();
  void save(byte[]);
}

[Vesnyx]

Doesn't seem like this has been worked on in a while, but couldn't modifying this and a few other areas where the "masterkey.cryptomator" is declared help fix this issue?

[markuskreusch]

An external masterkey would in fact require modifcations to the code you are referring too, but some additional tasks which make this more complex would have to be considered:

• The UI must be adapted to let the user choose the external masterkey from any location
• The user muste be able to distinguish vaults with external masterkey from vaults containing one
• The apps must be adapted to support external masterkeys as well.
• How does the user transfer the masterkey? Does our application provide any means for this or is this up to the user?
• All UI changes must be presented in a way which can easily be understood. The requirement of key transfer must be made clear to the user.

Workaround For now, experienced users may just use a long, generated password. A random password of 43 characters made of [a-zA-Z0-9] corresponds roughly to a 256-bit key.

[overheadhunter]

fixed in a041c5e