Each user is assigned a key, of length N bits. I'm giving the user a "password" with a full N bits of entropy, rather than letting them choose a (potentially weak) one. This is not a problem for this particular project.
The goal of this post is to help determine N. I want N to be long enough to be secure, but there is a cost to longer keys.
First, I'm thinking about the multiple between: - The amount of time I'm willing to take to hash a password on my server (say, 1 ms). - The amount of time I'm willing to give an attacker to brute-force a key (say, 100 years).
So I figure that the number of bits of entropy I need are roughly log2(100 years / 1 ms) = 42 bits. I suppose 43 since they'll get the password in half the time.
The next piece of the calculation is that the attacker could commit many more computing resources than my server has. They might have a cluster or use a botnet. (I understand that bcrypt is resistant to major speedups through GPUs e.g., but if not please let me know.)
I'm not sure how to estimate this. How big is a large botnet, for instance? But anyway, I will form an upper bound for this number and extend my key length accordingly.
Of course, I plan to update my servers regularly, and up my bcrypt work factor as needed to keep my hashing time at 1ms.
Does this sound like a reasonable way to choose a key length? Can anyone advise what that second multiple should be?