

Key length with bcrypt - uonce

I'm working on an authentication system that is a little different than a traditional username and password scheme.<p>Each user is <i>assigned</i> 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.<p>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.<p>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).<p>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.<p>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.)<p>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.<p>Of course, I plan to update my servers regularly, and up my bcrypt work factor as needed to keep my hashing time at 1ms.<p>Does this sound like a reasonable way to choose a key length?  Can anyone advise what that second multiple should be?
======
dchest
How will you distribute these random keys to users?

~~~
uonce
Via mail in a security envelope. Will need to look into the potential attacks
on that separately....

