How is HKDF-Expand better than a simple hash?

Question

Why do we need HKDF-Expand if we can simply hash the pseudorandom key to make it longer? The docs (in the link) say:

The second stage "expands" the pseudorandom key to the desired length...

Is it only to allow for longer keys? So that if all we need is, say, 32 bits - we can simply use SHA256? Or is there another need to it?

Answer 1

Short: In some simple cases, hash could be adequate. However, HKDF is intended to be a generic construct you can commonly apply for needs requiring Extract-Expand (such as when you have a shared secret agreed using DH or ECDH). It aims to be largely compatible with existing practices and thus makes it easy to apply the same pattern to multiple uses. It allows simple extensibility (for instance if you need to output more key material in future)

---

HMAC-based key derivation is commonly used instead of Hash-based key derivation because:

1. In some uses of Hash-based key derivation there is risk of length extension attack (by choosing $OtherInfo$ field correctly).
2. When using hash for key derivation there are often multiple fields to concatenate (like previous hash, secret, info, counter). This is bad, because it kind of mixes together key data that is to be protected and other non-critical data (which is often known by the attacker). With PRF (pseudo-random function), it is possible to keep key and the other data separate.
3. The standard constructs for key expansion, the ones defined in standards like NIST SP 800-108 or IKEv2 already are PRF-based (use HMAC function).
4. Security features of PRF-based constructs can be easily proven using Random Oracle. (Though such proofs are only approximations of reality if using HMAC-SHA-X.)

In case of HKDF-Expand, using HMAC to implement HKDF-Extract means that both extraction and expansion stages are more similar if both of them are based on HMAC. For using HMAC in HKDF-Extract stage, Krawczyk has provided good rationale in Cryptographic Extraction and Key Derivation: The HKDF Scheme. Especially interesting may be the chapter 8, which compares HKDF against more traditional constructs.

In case of using, HKDF-Expand when the output size is just one block and no info is used (it is empty string), the function will reduce to (assuming 32 bytes output is needed):

$HKDF\text{-}Expand(PRK, info, L) = HKDF\text{-}Expand(PRK, "", 32) = HMAC\text{-}SHA256(PRK, 0x01)$

This is somewhat more complex, than e.g. $SHA256(PRK)$, but using such as key derivation function would no longer be compliant with the most important standards (NIST SP 800-108, RFC 5869/HKDF).

---

Overall, this way of doing key expansion appears extensible, good practice, well proven and deployed in practice. I would use HKDF-Expand (or NIST SP 800-108 KBKDF) instead of any home-baked scheme, and feel more secure on selection of algorithm, and know that it will better serve me even if needs will change in the future.