# What is the use of key iterations?

I read about PBKDF2 on Wikipedia and seen few apps. having option to manually enter number of iterations. I am still not clear on this.

(1) With what I understood, key iterations can be used only with symmetric encryption. If a file/text is encrypted using passphrase, HASH is calculated and encrypted with AES for 'n' number of times. If iterations selected is 100 then this is done 100 times. This is done to defend against brute-force attack.

(2) Key iterations have no use with public-key encryption.

(3) Some apps. by default take 100 iterations. Few apps by default takes 2000 iterations when using AES. How many iterations are considered secure with AES-128 and AES-256?

• For PKBDF2 the iteration count is to make the operation deliberately more expensive to defend against attack, yes. But I've not heard iterations in the context of symmetric crypto or hashes: do you mean the round count? That's not exactly the same thing in that it's not commonly varied and not expected to be: the values chosen by the designers are chosen to be sufficient for all known attacks plus a margin of safety, and it's to defeat cryptographic advances not just raw computing power.
– Rup
Oct 8 '16 at 11:02
• 1) The standard is to use a hash function in HMAC mode as the underlying PRF. Yes, if the number says "100", you iterate the hash 100x before you use the result as your key. Yes, this is done to slow-down attacks. 2) They have to encrypt private keys with passphrases. 3) Anything below 10k or 50k is way too less today IMO.
– SEJPM
Oct 8 '16 at 12:18
• @SEJPM In that case, while decrypting again it has to be iterated those number of times to get back the correct hash to authenticate?
– RPK
Oct 8 '16 at 12:52
• yes, you have to do the same key derivation during decryption again.
– SEJPM
Oct 8 '16 at 12:53
• PBKDF2 doesn't 'encrypt[] with AES' and doesn't involve AES at all, although it can be used in a scheme (e.g. an app) that also uses AES; if you read the Wikipedia article you should know this. PBKDF in general is mostly used for symmetric cryptography (mostly but not solely encryption) because one feature of passwords it that they are relatively easily shared and symmetric keys often need to be shared while asymmetric private keys should (practically) never be shared. Oct 8 '16 at 19:52

With what I understood, key iterations can be used only with symmetric encryption. If a file/text is encrypted using passphrase, HASH is calculated and encrypted with AES for 'n' number of times. If iterations selected is 100 then this is done 100 times. This is done to defend against brute-force attack.

First things first: PBKDF2 (and comparable schemes) are called password hashing schemes (PHSs) (or more popularly password-based key derivation functions). All they do is take a password, preferably some randomness (aka a salt) and return a uniformly random-looking bitstring which can only be derived using the previously mentioned inputs and is suitable as a symmetric key. The special thing about PHSs compared to normal key derivation functions (KDFs) is that they also take one or more cost parameters. Usually at least one of them allows you to linearly scale execution time which is the case with the iteration count in PBKDF2.

Now the usual flow for using PHS is the following:

1. Gather password and salt
2. Run both through the PHS with some specified iteration count - AES is usually not involved in this step
3. Use the derived key to key some symmetric operation
4. Use the keyed symmetric operation for whatever it is that you need to do, e.g. encrypt / decrypt data

Indeed the key idea of the above is the observation that if you invest effort $$E$$ into deriving your password an attacker not knowing your password will have to invest $$2^{H(P)}\cdot E$$ effort where $$H(P)$$ is the (min-)entropy of your password. This then allows you to derive your password in say 1 second and an adversary to spend a lot of ressources to brute-force it - even if it is only moderately complex.

(2) Key iterations have no use with public-key encryption.

Well, you could feed the output of your PHS into a private key generator allowing you to immediately recover it from the password. In fact this is what BIP-39 does. Alternatively you could use a PHS to generate a symmetric key to encrypt / decrypt you private keys - which is what GPG does.

(3) Some apps. by default take 100 iterations. Few apps by default takes 2000 iterations when using AES. How many iterations are considered secure with AES-128 and AES-256?

The usual advice is "use as many as you can afford" where "afford" is a time(-memory) budget that you specify and then measure out the relevant parameter set. However if you prefer cold, hard standards, NIST SP800-63B is the relevant one and recommends at least 10,000.

• OK, so how is a random string as a password not as good as a random string password iterated a 1000 times? Is the usecase that you have a not-so-random string, such as "password" or similar that is susceptible to dictionary attacks. That is, someone else got to choose a weak password that we now have to make better via hasing it multiple times...? But basically, if I chose a very good password myself I wouldn't have to do this at all, right? And also, if I use "password" as input and "salt " as salt and iterated 1000 times, I would always end up with the same password in the end, correct? Nov 12 '21 at 9:21
• @JohnyTex Indeed, the primary intent of expensive password hashing is to turn a borderline bad password into an acceptable one. Turning an excellent one into an excellent one doesn't hurt in the process and doesn't require this mechanism. However you as a server typically don't want to decide what a good and bad password is because that's a property of its generation and not the string you see. And yes, these schemes are deterministic in their inputs, so if you repeat the same inputs, e.g. password, salt, cost parameters, you'll always get the same output.
– SEJPM
Nov 12 '21 at 14:20
• Great. Exactly the answer I wanted to hear. Thank you. Nov 12 '21 at 14:38