When creating a hash with PBKDF2, it allows the developer to choose the size of the hash. Is longer always better? Also, what about the size of the random salt? Should that be the same size as the hash?
EDIT: Particularly in hashing passwords.
Tell me more
×
IT Security Stack Exchange is a question and answer site for
IT security professionals. It's 100% free, no registration required.
|
|
|||||||||||
|
|
For the hash function, you want to use a function for which the most efficient platform type (the one which will produce the more hash computations per second and per dollar) is the machine that you intend to use (i.e. a PC). That's because you are in a weapon race with the attacker, and the attacker can buy other kinds of hardware to get an edge over you (such as a GPU). GPU are very good at 32-bit arithmetics, but not at 64-bit arithmetics, whereas a PC (in 64-bit mode) will be quite fast at the latter. Thus, use a hash function which runs on 64-bit arithmetic operations. This points at SHA-512. PBKDF2 is a key derivation function: it produces an output of configurable size. For password hashing, you want the size to be large enough to deter generic preimage attacks (i.e. trying random passwords until a match is found), so this would need, say, at least 80 bits of output. If only for making the security more convincing for the unwary, and also for aesthetics, go for the next power of 2: a 128-bit output. It is not useful to go beyond that. The salt must be unique -- as unique as possible. An easy way to achieve unique salt values is to generate salts with a cryptographically strong PRNG: probability of reusing a salt value will be sufficiently low to be neglected if these random salts are large enough, and "large enough" means "128 bits". So use random 128-bit salts. Personally, I prefer bcrypt over PBKDF2 for password hashing. |
|||
|
|
According to the PBKDF2 standard, the minimum recommended size for the salt is 64 bits, though I'd personally recommend 128 bits or higher for a decent safety margin. The size of the salt is independant to your choice of hash. As far as security is concerned, I recommend choosing a derived key length of at least the same size of your salt's output, with a minimum of 256 bits. Any hash size less than 256-bit is below the security boundary of most modern hash functions anyway. Choosing a derived key length that is less than the output length of the hash function makes little sense, unless you're using the key for a block cipher that can't handle a key of that size. In terms of optimal security, I'd suggest SHA-512 as the PRF, with a 512-bit derived key, a 128-bit salt, and as many iterations as your situation can warrant. |
|||
|
|
