PBEKeySpec what do the iterationCount and keyLength parameters influence?

Question

Delving into the java encryption and hashing world I see examples of the constructor for the PBEKeySpec class with various values for the iterationCount

Answer 1

The iteration count is the number of times that the password is hashed during the derivation of the symmetric key. The higher number, the more difficult it is to validate a password guess and then derive the correct key. It is used together with the salt which is used to prevent against attacks using rainbow tables. The iteration count should be as high as possible, without slowing your own system down too much. A more generic term for iteration count is work factor.

The key length is the length in bits of the derived symmetric key. A DESede key can be either 128 or 192 bits long, including parity bits. An AES key can be 128, 192 or 256 bits long. The problem is that it is not specified by the API which key length (bits / bytes, with- or without parity) is meant; for PBEKeySpec the key size is bits, including the parity bits as shown in this section.

The key derivation function normally just outputs "enough" random bits, so that's why you can still specify the required key size.

---

Notes:

• For more info, please have a look at the standard, PKCS standards tend to be relatively easy to read.
• The salt just needs to be unique; generally this is achieved by creating a 64 to 256 bit fully random salt using a secure random number generator (which, for Java means using new SecureRandom() and then nextBytes(int amount)). The salt can be public and stored with the ciphertext or password hash.
• Specifying any value larger than the output size of the hash (by default this is SHA-1, 160 bits output size) for the key size may fail (for PBKDF1) or result in an additional slowdown (for PBKDF2). Not recommended; just use a hash function such as SHA-256, SHA-512 in the algorithm specification.
• SHA-1 (sometimes just called SHA as SHA-0 was never used) and even MD5 are still completely secure for this kind of function (as it doesn't rely on collision resistance) but you should still go for a more secure option such as SHA-256 or SHA-512 for new protocols.