This is the code I use to "hash" (or derive key as called in the PBKDF2 implementation of the PKCS standard) passwords strings with the Rfc2898DeriveBytes class provided in .NET:
int saltSize = 256;
int iterations = 1000;
int keySize = 20; // The parameter I'm not sure of
var deriveBytes = new Rfc2898DeriveBytes("mypassword", saltSize, iterations);
byte[] salt = deriveBytes.Salt;
byte[] key = deriveBytes.GetBytes(keySize);
Now, I understand that the salt size doesn't matter much (as long as it is enough to ensure that random salts will be unique), but what about the key size? Does a longer key provides more security against attacks?
(Notes:
1. Performance matters do not import for me here, it is obvious that a longer salt or a longer key will take more time for GetBytes
to return a value.
2. I want to use this "hash" to store them in a database, not to use them afterwards in a encryption scheme)
keysize is the size of desired key; So if you want to get a big derived key, use bigger keySize.
The time needed for bigger keysize is proportional to int(keysize/hashsize), so you should set keysize to at least the same length as hashsize.
Also, you should use derived keys of recommended length, when they are used in some cypher, e.g. AES (128 - 256 bit).
Generally you use PKCS#5 v2 / RFC2898 to create a symmetric key from a user password. The size is important because it must match the required size of the symmetric algorithm you'll be using.
However you seems to be looking at keeping an hash of passwords, not for a key, so the size is not as important in your specific case. You can safely fix it to the hash size (20 bytes for SHA1) if you want a specific value.
General note (for people where performance matters): using PKCS#5 v2 (or older) will take a lot longer (iteration count) than using a salted hash or an HMAC.