If you are using the output for password hashing, then the output length:

• Must be no more than the native hash's output size
• SHA-1 is 20 bytes, SHA-224 is 28 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, SHA-512 is 64 bytes
• Must be no less than your risk tolerance. In practice, I'd say anything less than 20 bytes (SHA-1 native output size) is too small.

If you are using the output directly as only a single encryption key:

• Should be equal to the size of the encryption key you need
• Ideally is also no more than the native hash's output size (see above)

If you are using the output as both an encryption key and a MAC, or any other case where you're using the output for more than one purpose:

• See the answer @CodesInChaos gave to How to salt PBKDF2, when generating both an AES key and a HMAC key for Encrypt then MAC?
• the critical point is that if you use the output for both key and HMAC, "he [the attacker] can verify correctness of his password guess after one key was derived, he doesn't need both"

The reason for "no more than the native hash's output size" is that RFC2898 section 5.2, in the PBKDF2 definition, specifies that if more output bytes (dkLen) are requested than the native hash function supplies, you do a full iteration count for the first native hash size, then another full iteration count for the second, and continue until you're done or you have to truncate the output because the remainder of what you need is less than the native output size.

If you are using the output for password hashing, then the output length:

• Must be no more than the native hash's output size
• SHA-1 is 20 bytes, SHA-224 is 28 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, SHA-512 is 64 bytes
• Must be no less than your risk tolerance. In practice, I'd say anything less than 20 bytes (SHA-1 native output size) is too small.

If you are using the output directly as only a single encryption key:

• Should be equal to the size of the encryption key you need
• Ideally is also no more than the native hash's output size (see above)

If you are using the output as both an encryption key and a MAC, or any other case where you're using the output for more than one purpose:

• See the answer @CodesInChaos gave to How to salt PBKDF2, when generating both an AES key and a HMAC key for Encrypt then MAC?
• the critical point is that if you use the output for both key and HMAC, "he [the attacker] can verify correctness of his password guess after one key was derived, he doesn't need both"

The reason for "no more than the native hash's output size" is that RFC2898 section 5.2, in the PBKDF2 definition, specifies that if more output bytes (dkLen) are requested than the native hash function supplies, you do a full iteration count for the first native hash size, then another full iteration count for the second, and continue until you're done or you have to truncate the output because the remainder of what you need is less than the native output size.

If you are using the output for password hashing, then the output length:

• Must be no more than the native hash's output size
• SHA-1 is 20 bytes, SHA-224 is bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, SHA-512 is 64 bytes
• Must be no less than your risk tolerance. In practice, I'd say anything less than 20 bytes (SHA-1 native output size) is too small.

If you are using the output directly as only a single encryption key:

• Should be equal to the size of the encryption key you need
• Ideally is also no more than the native hash's output size (see above)

If you are using the output as both an encryption key and a MAC, or any other case where you're using the output for more than one purpose:

• See the answer @CodesInChaos gave to How to salt PBKDF2, when generating both an AES key and a HMAC key for Encrypt then MAC?
• the critical point is that if you use the output for both key and HMAC, "he [the attacker] can verify correctness of his password guess after one key was derived, he doesn't need both"

The reason for "no more than the native hash's output size" is that RFC2898 section 5.2, in the PBKDF2 definition, specifies that if more output bytes (dkLen) are requested than the native hash function supplies, you do a full iteration count for the first native hash size, then another full iteration count for the second, and continue until you're done or you have to truncate the output because the remainder of what you need is less than the native output size.

If you are using the output for password hashing, then the output length:

• Must be no more than the native hash's output size
• SHA-1 is 20 bytes, SHA-224 is 28 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, SHA-512 is 64 bytes
• Must be no less than your risk tolerance. In practice, I'd say anything less than 20 bytes (SHA-1 native output size) is too small.

If you are using the output directly as only a single encryption key:

• Should be equal to the size of the encryption key you need
• Ideally is also no more than the native hash's output size (see above)

If you are using the output as both an encryption key and a MAC, or any other case where you're using the output for more than one purpose:

• See the answer @CodesInChaos gave to How to salt PBKDF2, when generating both an AES key and a HMAC key for Encrypt then MAC?
• the critical point is that if you use the output for both key and HMAC, "he [the attacker] can verify correctness of his password guess after one key was derived, he doesn't need both"

The reason for "no more than the native hash's output size" is that RFC2898 section 5.2, in the PBKDF2 definition, specifies that if more output bytes (dkLen) are requested than the native hash function supplies, you do a full iteration count for the first native hash size, then another full iteration count for the second, and continue until you're done or you have to truncate the output because the remainder of what you need is less than the native output size.