Does Size of Bitstring Matter in Hashing Functions?

I'm trying to create an implementation of PBKDF2 to generate a key to encrypt a file with AES-256, but I have a question about salt size. I plan to use SHA-256 and concatenate with the passphrase, so does it make a 开发者_JAVA百科difference if the size of the concatenated bitstring is greater than 256 bits, or would it be considered more secure if both the salt and passphrase were 256 bits each, making their concatenation 512 bits?

---

First, let's back up and quickly review PBKDF2:

PBKDF2 generates an output that is a desired number of bytes long. It generates these bytes by computing a number of 'blocks'. Each block is the size of the selected hash. For example, if you wish to derive a key that is 64 bytes long, and you wish to use SHA-256 which produces 32-byte hashes, you will generate 2 PBKDF2 blocks. The final output is the concatenation of these blocks.

So how to generate each block?

Well, (and I'll use the RFC nomenclature here), blocks are generated by a function, F. This function takes in the users password P, your salt S, a desired iteration count c and the index of the block you're generating i (one-based).

For your first block, your function call will be similar to: F ("MySecretPassword", "random_salt", 100000, 1) (Notice I'm using 100k iterations. For more information about choosing this value, refer to this post.)

Referring back to the RFC:

F(P, S, c, i) = U_1 \xor U_2 \xor U_3 ... U_c
U_1 = PRF(P, S || INT(i))
U_2 = PRF(P, U_1)
U_3 = PRF(P, U_2)
...
U_c = PRF(P, U_{c-1})

PRF stands for pseudorandom function. Which, for SHA-256 should be a SHA-256 based HMAC. The function works by first generating the SHA-256 HMAC for your password P, using your salt S concatenated with the block number i. Then, the function iterates (c times), and XOR's the result with the prior result. Each iteration uses SHA-256 HMAC (again) to hash the password P but uses the prior result as the HMAC key.

So - to jump back to your question - because we're using HMAC, the salt length doesn't matter** and can be more than 256 bits. When HMAC is supplied a key (your password in this case) longer than the length of your hash output, it will hash the key to get exactly 256 bits. If a key shorter than 256 bits is supplied, it's padded to get exactly 256 bits. In a sense, these details are hidden from your implementation so you need not worry about how long a salt you're passing into PBKDF2.

** Well, it does matter to some degree. See owlstead's comment on the other answer. It should be long enough to frustrate the use of rainbow tables. (Although because PBKDF2 applies your hash function a large number of times, a long salt is less important than in traditional 'straight hashing' applications.) For my application I use a 32 byte random salt, unique for each users account where I'm hashing their password with PBKDF2.

Hope that helps!