Lets say that i’m very happy with the security of the vault protected by its 256 bits keys.
Lets also say i do not really understand the intricacies of cryptographic keys, entropie and such.
Let say further i have no need for a simple master password because a password manager is used.
Lastly lets say i would like to have a master password complex enough that a brute force attack on the master key is as difficult as a brute force attack directly on the vault (i.e. without using the information in masterkey.cryptomator)
Question: wat kind of master password should i use? Do i understand correctly that this should be a password with 256 bits of entropy? (because the vault keys are 256 bits and these keys are presumably fully random)
You can use any kind of password you want.
The more characters/entropy provided at vault creation ,significantly increases the security against brute force attacks.
@overheadhunter did a little math on how much time and/or energy and invest is actually needed to bruteforce a vault protected with a 12 digit password.
His post in is in German.
The result of his math was: either round about 1.2 quadrillion years of time or 46 billion euro together with round about 32 Gigawatt of energy and 1 Year of time.
(with some assumptions and exclusions)
I think this gives a pretty good idea what can be done with a 12 character password
Here’s the link: Master-Key in der Cloud?!
So if I understand this correctly, a 12 character password in cryptomator requires a vastly different amount of computing power to brute force than a common 12 character password elsewhere due to the specific algorithm used?
Interesting. Does this mean that a relatively short master password, with much less entropy than the 256bit encryption key witch is derived from it, can be as save as the 256 bit key itself, due to the time, memory and energy expensive KDF which is needed to derive the 256 bit key?
But how does this add-up with the remark as pointed out above: “there is no security benefit of entering a password with more entropy than the 256 bit key that is used after key derivation, i.e. a hundred random ascii characters”?
It seems that at the one hand a (very long) password with about the same entropy as the 256 bit vault keys is cryptographically safest, but on the other hand a way shorter password (at least 10 characters is suggested in de Cryptomator documentation) should be super-safe, due to the KDF which kind of “protects” brute-force attacks.
If the KDF protection is so strong, i wonder “how short can you go”. If i understand all this correctly, one should presumably compare the cost of (directly) brute forcing the 256 bit key space to the cost of brute forcing the way smaller keyspace of the master key, including the added KDF cost.
Lets say the key space of a 10 char master password is about 50 bits (62 char alphabet). Then every KDF protected try of the keyspace of the master password should be as expensive -or more expensive- as brute forcing (256 - 50 is) a complete keyspace of 206 bits. To be honest, i have no idea if this is the case, but traversing a keyspace of 206 bits seems like a daunting task compared to 1 KDF try?!
That all depends on what the “elsewhere” application is using the password for. The key space of the password is identical (amount of possible passwords), no difference there.
But lets say a password is used to protect entrance to a webiste. And suppose this website only lets you try one password each 5 seconds. Then it takes quite some time (on average) to brute-force your way into it (of course most websites nowadays often lock you out after too much failed attempts). If the web site just compares your hopefully salted and hashed password and grands you unlimited tries, restricted only by cpu-cycles and io, brute-forcing could go fast.
If the “elsewhere” is another encryption tool, they probably also use KDF and whatnot.
Let there be some minimum number of bits of entropy in the passphrase 0 < n < 256 from which onwards any bruteforce attempt that includes the KDF is more expensive than skipping the KDF and directly bruteforcing the derived key (i.e. 256 bit keyspace).
Since we do not know where exactly n lies (and it isn’t a constant but depends on the hardware capabilities of the attacker), we recommend using long passwords, 10 chars just being the minimum.
Let me be perfectly clear about this: We do not claim that this recommended minimum is “as save as the 256 bit key itself”.
The only thing we can say for sure is that n exists and therefore it is pointless to add any further characters once you have reached this point.
That makes sense. Any reasonable estimate of n if we are not talking about a state actor with unlimited funds, but more like a hacker that wants to gamble spending a few thousand dollars to rent computing power for a few days (or has access to a university supercomputer or some botnet etc) to try to brute force this. What is some rough number of characters that would make you feel safe against this example, and what number would start being overkill level?
Yes. All clear. Users with a password manager might just as well simply opt for an about 256 bit entropy password and never worry about n anymore (btw, then you need around 50 chars@5 bit/char, i suppose the 100 chars mentioned in this thread is a small error).
The 100 mentioned above are just the threshold where we stop putting the passphrase into zxcvbn to get a quality rating.
It really depends on the alphabet size it can be way shorter. 40 evenly distributed printable ascii chars would already be exceeding the entropy of the derived key (96^40 > 2^256).
The 12 chars (assumming not just being aaaaaaaaaaaa) preivously mentioned are what I feel perfectly comfortable with. That said, I often use words instead of chars, in which case you need to keep dictionary attacks in mind.
(btw, then you need around 50 chars@5 bit/char, i suppose the 100 chars mentioned in this thread is a small error).