The security architecture document states “The JWT is signed using the 512 bit raw masterkey.”. But the masterkey is 256-bits, not 512, yes? How is the full 512-bit secret used for the signature derived? Like to update my code here: GitHub - lellis1936/CryptomatorAccessDemo for the new vault format.
There are actually “two” 256-bit masterkeys. One for encryption, one for authentication: Security Architecture — Cryptomator 1.6.0 documentation
Regarding the JWT signature, you then just concatenate the encryption and the authentication masterkey.
1 Like
OK. Just to be sure I’m not missing something… it would seem to me that the data in the JWT should not be used if the JWT fails signature validation. Yet, to perform the signature validation, you need to use the masterkey file, whose location now comes from the JWT. Chicken and egg problem?
I couldn’t find a confirmation right now and I hope I remember it correctly: That’s actually the reason why the kid key/value pair is stored in the JWT header and not in the payload. Of course, the header is also signed and can be verified but you can say the same about the alg key/value pair that is necessary to identify the signature algorithm.
You can also have a look in our VaultConfig implementation, which includes a UnverifiedVaultConfig for exactly that (and other) reason(s).
1 Like
Thanks for this. I also now have found the Security Architect documentation states that the vault configuration must first be read without validation and then again with validation. Using the documentation I was able to get my project working with validation for the new vault configuration.
1 Like