# Deriving 2 keys using HKDF

I have an encryption scheme that uses a 256-bit master key, from which 2 separate keys (one for AES-256-CTR encryption and one for a HMAC-SHA256) are derived using HKDF. However, I'm not sure exactly how to utilize HKDF without screwing it up, so straight to my concerns:

1. Is it safe to just use SHA-512 as the hashing algorithm to get a 512-bit output and split it in 2?
2. I know that using salt is not mandatory, but does using it actually improve security?
3. I know this might be a dumb idea, but still ... can the salt be the IV used for encryption?
-

1. Yes. You can either use HKDF-expand twice with different info values, or once with a longer output length.

2. Depends. If your 256-bit master key is generated using a secure RNG, a salt is unnecessary. OTOH, if it's derived from something with less entropy, like a password, having unique salts would ensure uniqueness of derived keys even if the master keys happened to match for two users or sessions.

3. Probably not a good idea, but whether it's secure depends on how the IV is chosen.

HKDF assumes that the salt is not attacker-chosen. If an attacker can influence the IV, then that's a definite no. OTOH, if the IV known to be completely independent of the key, it should be secure, since CTR doesn't place any requirements on the IV beyond uniqueness.

Still, if you can just create another random number to use as a salt, it's simpler to do that. And if you can't be sure the salt isn't attacker-controlled, it's better to leave it out altogether.

-
Great, thank you. After thinking about it again, I wouldn't be able to use the IV as salt anyway. –  Narf Jun 22 at 16:27

Although the answer is already accepted, I'll add an answer with a different look on things.

1. It's safe, but that's not what HKDF-expand should be used for. The idea of HKDF-expand is to call it twice, once for each key, using the info element to distinguish between the two (e.g. info could be an ASCII encoding of the key name). Note that HKDF should have a relatively short running time.

2. Although it is not required, it is best to use a salt. So unless there is some important reason not to, use a salt. For KBKDF's a salt is unusual, but the authors seem to think it is important; see the quote underneath this answer.

3. You could, however I would urge you to independently generate it using HKDF-expand, see answer (1).

Quote for part #2 (see 3.1 of the RFC):

We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting "source-independent" extraction, and strengthening the analytical results that back the HKDF design.

-
Thanks for the further input. My goal was to achieve maximum performance by having just one hkdf() call and possibly using already existing data for salt if that would increase security. Unfortunately, by achieving my first goal, I can't practically do the latter. –  Narf Jun 23 at 7:40
HKDF is of course the latest/greatest method to do KBKDF calculations, but you may consider using KDF1 instead. That will mean you are using a less secure KDF, but you would be using it in the way that is intended to be used. Using a NIST specified KDF in counter mode (NIST SP 800-108 if I'm not mistaken) using AES may also speed up your KDF, especially on systems that have AES instructions on the CPU. –  owlstead Jun 23 at 11:00