Reasonable Password Entropy given a certain Set of argon2 Parameters

Question

I followed the recommendation of choosing threads, memory consumption and the number of iterations (in that order) on my machine. But now I wonder which passwords (by means of entropy) are actually secured by this set of parameters.

Clearly, a single letter is not secure, regardless of the parameters; but on the other hand, using a 256-bit entropy password renders the usage of argon2 pointless. So the security of my hash certainly depends on the relation between password strength and argon2 parameters. Since I am using old and not powerful hardware I am concerned, that the time it takes for me to calculate the hash is negligible for a large scale attacker. (This might be even worse for hashing on mobile phones or embedded devices.)

So the question is: Given a certain set of argon2 parameters, what is the minimal entropy a password should have so that the hash can be assumed to be secure?

Alternatively: Given a certain set of argon2 parameters, how many passwords can the fastest supercomputer available today (in 10/20/50 year) check in a second?

Edit: I am using a strong (>= 128-bit) password for locking my password manager, but entering this several times is tedious. So I thought using a key file that is protected by a simpler password. Since I am syncing stuff to the cloud, the hash of the simpler password can not be considered a secret. In order too choose a simpler password that is still considered secure, I need to be able to estimate the protection gain from using a strong KDF (e.g. argon2).

Edit 2: This question and answer tackle my question in a general context (not Argon2 specific) very well.

Answer 1

You should have ≈128 bits or more entropy in any password you want to remain secure regardless of the password hashing function.

Rationale: slow password hashing functions only add a constant-time factor to brute-force search. Since you don’t know the processing capabilities of any potential attacker, the only safe path is to use a very high-entropy password Such a password would be securely stored even if hashed with a single iteration of MD5 without salt.

So what do fancy iterated, “memory hard” functions buy us?

They help against, but do not prevent, attacks on low entropy passwords, the sort that humans can actually memorize. In effect, they increase the work factor required for a dictionary, brute-force, or hybrid search by a fixed amount. You could view this as “extra bits of security”, but you’ll only know how many bits you still need “to be secure” if you know with fair certainty the computational abilities of your attacker.

If your adversary is a nation-state’s security apparatus, the number of “bits of entropy you need” in the password differs vastly from that when your adversary is me. So the only truly safe thing to do is to always use a high-entropy input password, which renders the fancy hash function pointless.

Slow password hashes are implemented to mitigate the costs to users of a breach of the password hash database. They cannot make low-entropy passwords “always secure” unless they themselves utilize 2^100 operations, making them completely impractical.