Deriving 256-bit key from PBKDF2-SHA1 I am working in .NET and their PBKDF2 only uses SHA-1.  I am using it to, given a user-supplied password and random salt, generate a 256-bit AES key.  The plaintext is encrypted with the AES key and the ciphertext and salt are then stored.  SHA-1 has a 160 bit output size.  So if I specify 100000 iterations to PBKDF2 it will actually run 200000 iterations.  Let's say an attacker did a dictionary attack on the password (running each password and the known salt through the key derivation and trying to decrypt the data with the derived key). Would he also need to run 200000 iterations, or is there a shortcut he could use that would only require 100000 iterations?

The OWASP states:


  Using PBKDF2 for password storage, one should never output more bits than the base hash function's size. With PBKDF2-SHA1 this is 160 bits or 20 bytes. Output more bits doesn't make the hash more secure, but it costs the defender a lot more time while not costing the attacker. An attacker will just compare the first hash function sized output saving them the time to generate the reset of the PBKDF2 output.


But since I am not storing passwords, is the above not concern for me?

Of course it would be nice if .NET supported PBKDF2-SHA-512, but as far as I know that is not yet the case.


Note: If I understand correctly, my 256-bit AES key only offers 160 bits of security (due to 160-bit output length of SHA-1), but that seems not too problematic considering a dictionary attack on the password would likely be much more appealing to attackers than a brute force attack on the key.
I think it's OK in this instance: an attacker cannot check the first half of the hash (160 bits) because he cannot use AES-256 yet; the key is incomplete. So he needs to run the second half too. He needs the full key to check the decryption.

The OWASP guide refers to the case where the output of the PBKDF2 function is stored directly as the hash-check in a database. In that case the first 160 bit check is already enough to discard almost all invalid passwords. In the rare case the 160 first bits match, you can do the second half to confirm, and that's no extra work, really.