Computing IV for CBC from PBKDF2 + HKDF

Question

Note that this question is somewhat similar to Can I use my random IV (for AES) as a salt for PBKDF2?

My current encryption format computes two random PBKDF2 salts (encryption and HMAC, 8 bytes each) and also a random IV (16 bytes) to use with AES-CBC. This adds 32 bytes to the final message, which can be a lot for short messages (plus another 32 bytes of HMAC and a couple of bytes of "header").

My thinking is that I can generate all three values (IV and two keys, 640 bits) from the salt and password:

• Generate a 16-byte salt
• Use PBKDF2 (for some number of iterations) to stretch salt+password into 512-bit pseudo-random key (PRK).
• Use HKDF-Expand on PRK to generate IV, enc_key, and hmac_key.

The full specification is available at RNCryptor-Spec v4.

I believe that generating the IV this way is secure, and possibly marginally more secure than generating and sending a random IV, since the attacker cannot manipulate the IV if it is computed from the PRK. The inclusion of a 16-byte per-message random salt means that key/IV combinations should not repeat any more often than for a randomly-selected IV.

OpenSSL's enc format uses a somewhat similar approach, but I have never seen a cryptanalysis of it. TLS 1.0 computed the IV in a non-random way which could be manipulated by the attacker, which led to vulnerabilities (however, my approach includes a random seed, and I believe is not vulnerable to that, even if an implementation fails to verify the HMAC).

This approach is space efficient and seems possibly more secure than an independent random IV. However, I can't find any reference that explicitly approves it (other than Thomas Pornin's answer linked above, which at this point is good enough for me).

Are there problems with using a KDF to generate the IV with a random salt? Is there any document that explicitly evaluates it?

Answer 1

If I'm reading your specs correctly, you do this: $IV||VAL||K_E||K_A=KDF(PBKDF(PW,Salt,Iterations))$. (Order doesn't matter here)

As far as I know this is common practice and shouldn't pose any security threats, as the IV is in fact unpredictable as it needs to be.

If I may I'd suggest you using EAX, CCM GCM mode if available, as this is easier than using CBC+AES and HMAC. If you can't use EAX/GCM/CCM, you may want to use CTR, as this poses you at less severe constraints regarding the IV (unique instead of unpredictable).