# Is PBKDF2 with 1 iteration acceptable for a simple random key expansion?

I have a 128 bit randomly generated key. I need to expand this key to 512 bits to use with an existing encryption library that does AES-256 encryption in CBC mode with HMAC-SHA256 authentication.

The encryption library I am using also has PBKDF2-SHA512 available. Is it acceptable to use PBKDF2 with just 1 iteration to do the simple key expansion that I need? I would also need a salt, for which I suppose I could just use a hardcoded value for.

Example:

generated_key = crypto_safe_rand(128)
derived_key = pbkdf2(password: generated_key, salt: 'hardcoded_salt',
iterations: 1, algorithm: 'SHA-512')


My thought is that the iteration count isn't really a factor since the original "password" is randomly generated and 128 bits long.

Or would it be better to use something like HKDF?

• Nope! you will still have 128-bit key material. Start with a uniform random 256-bit key – kelalaka Oct 28 '20 at 20:03
• This is for HKDF but a similar idea applies to PBKDF2. – kelalaka Oct 28 '20 at 20:59
• HKDF is better suited to the purpose. HKDF allows the use of a context string (the info parameter) for domain separation between your derived AES key and the HMAC key. Since you're starting with strong randomness for the input key material HKDF-extract can be skipped, only HKDF-expand is useful. – SAI Peregrinus Oct 28 '20 at 21:02

Or would it be better to use something like HKDF?

Generally? Yes. Using HKDF is preferred, if only to communicate clearer what you're actually doing here.

Is it acceptable to use PBKDF2 with just 1 iteration to do the simple key expansion that I need?

Yes.

To explain this, we first need to understand how PBKDF2 works. First, note that it compute $$\ell$$ from the input as the number of PRF (HMAC) invocations needed to get the desired key length. The key is then $$T_1\|T_2\|\ldots\|T_\ell$$. The $$T_i$$ are defined as $$T_i=F(P,S,c,i)$$ - with $$P$$ being the password, $$S$$ the salt and $$c$$ the iteration count. If we now look at $$F$$ we get $$F(P,S,c,i)=U_1\oplus U_2\oplus\ldots\oplus U_c$$ which simplifies to $$U_1$$ for our purposes. Finally we look at the definition of $$U_1=\operatorname{PRF}(P,S\|\operatorname{INT}(i))$$ - with $$\operatorname{INT}(i)$$ being a fixed-length 32-bit integer encoding.

Putting all of this together we see that PBKDF2 with 1 iteration yields

$$\operatorname{PRF}(P,S\|\operatorname{INT}(1))\|\operatorname{PRF}(P,S\|\operatorname{INT}(2))\|\ldots\|\operatorname{PRF}(P,S\|\operatorname{INT}(\ell))$$

which can be easily proven to be a variable output-length PRF with the same argument that is used to prove Counter-mode secure.

Finally, a variable output-length PRF keyed with a uniformly random key yields an output that is indistinguishable from a random string. The only assumption we need to make here is that HMAC-SHA512 is actually a secure fixed-length PRF but that one shouldn't worry you.

• The OP's initial key is 128-bit random key. Therefore, the strength cannot be larger than 128-bit for AES-256. – kelalaka Oct 29 '20 at 22:07
• @kelalaka indeed this does not give you a higher level of security it however also doesn't loose you much security – SEJPM Oct 29 '20 at 22:29