What is the purpose of using HKDF?

Question

I saw a code snippet that generates an AES key by the following steps:

1. Generate a 16-byte random value array.

   SecureRandom random = new SecureRandom();
   byte[] key = new byte[16];
   random.nextBytes(key); 
   

2. apply the HKDF to the key to generate a new encryption key.

encrypt_key = KeyDerivation.hkdfSha256(Key,
                           /* inputSalt =*/ null,
                           hkdfInfoString.getBytes("UTF-8"),
                           16);

I am confused why we need two steps. The SecureRandom seems to give enough entropy for the key, right? Two questions:

1. Can we use the key in 1) directly for an AES encryption?
2. What's the impact of the null salt in 2)? I am considering maybe an extra step 2) is to protect the key being leaked (just a guess). If it is, does the null salt invalidate the purpose? Because we can precompute the linkage between the input key material of HKDF and its output.

The HKDF claims the salt is optional although using a random salt does strengthen it. I am confused that when is the scenario that an HKDF is required (especially without salt). If we already have a key with enough entropy, why we need it? If we have a weak key without enough entropy, how does HKDF (without salt) help this situation? I am imagining that the attacker can precompute the mapping between the weak key to the generated key, right?

Answer 1

1. Can we use the key in 1) directly for an AES encryption?

Yes, you can. However, there are reasons why you would want to change keys ever so often, e.g. algorithm / scheme restrictions, not leaking the (master) key, expanding the key material, deriving multiple keys and / or IV values etc. etc.... well anything that you need a KBKDF for in the first place (HKDF is a hash based Key Based Key Derivation Function).

However, if there is just one 128 bit key derived from another 128 bit key then I don't see much benefit. The only thing where this might be useful is if you don't trust the security of your SecureRandom implementation, as the KDF lays down another layer of HMAC to break through when an attacker tries and guess the state of the (apparently weak) random number generator.

Of course, as you've indicated in your question, the attacker could still guess the state of the random generator, but at least the attacker cannot obtain information about the state by e.g. reversing the calculation or gaining statistical information about the state.

2. What's the impact of the null salt in 2)? I am considering maybe an extra step 2) is to protect the key being leaked (just a guess). If it is, does the null salt invalidate the purpose? Because we can precompute the linkage between the input key material of HKDF and its output.

No, the key derivation function is one-way if the salt is present or not. The salt is used in the security proof of HKDF. However, it is not really needed to provide sufficient security. If you can add / store / transmit a salt then it would benefit security, but there are plenty of KBKDF's that don't (explicitly) allow for a salt in the first place. On the other hand: password based KDF's like PBKDF2 really need a salt to be secure.