# Security of KDF1 and KDF2 (hash based KDF's)

It's still common to come across implementations of KDF1 and KDF2. Basically these are KDF's that simply derive multiple keys from the key seed and a counter:

$K_i = KDF(K_{master}, i) = H(K_{master} | c)$

In this function $|$ means concatenation and $c$ is the encoded value of $i$ in 4 bytes using an unsigned big endian notation. KDF1 and 2 only differ with regards to the starting value of $i$.

The issue with the KDF is that a hash is not necessarily a PRF. Actually, I've only seen MD5, SHA-1 or SHA-256 being deployed.

Are there any particular attack vectors that can be used against this construction? Is there any practical/pressing need to switch to HKDF ora NIST SP 800-108 approved hashing algorithm or are the concerns purely theoretical of nature?

Please note: above only shows KDF1/2 in their least complex form, using only a single output block and with an empty $OtherInfo$.

-
Hopefully it does not matter if $c$ is signed or unsigned, of course :P. Maybe the security of the KDF can be directly mapped to a hash vs HMAC comparison? – Maarten Bodewes Apr 19 '14 at 16:43
This should work as long as the message being hashed has constant length (or at least is prefix free). Else length extensions might bite you. – CodesInChaos Apr 21 '14 at 9:15
@CodesInChaos Yeah, I figured as much. Otherwise HMAC did not need to have additional passes. But most (if not all) of the time the input is just a key seed or an actual key, so length extensions are generally not applicable, at least not as far as I can see... – Maarten Bodewes Apr 21 '14 at 12:23

Your "this page" says, nebulously, that $H(K | c)$ has "a possible security issue" fixed by using $H(c | K)$ instead. The former is used by ISO KDF1 and KDF2, the latter by KDF3 and NIST SP 800-56A. Does it matter? – Matt Nordhoff May 11 '14 at 12:26
I should, perhaps, have mentioned the optional "OtherInfo" concatenated on, e.g. $H(x | y | OtherInfo)$. – Matt Nordhoff May 11 '14 at 12:45
@owlstead I don't get it, though. $c|K$ and $K|c$ would be equally vulnerable to a length extension attack as long as $OtherInfo$ comes last, wouldn't they? In other words, KDF3 is equally vulnerable, if that's the "possible security issue". – Matt Nordhoff May 11 '14 at 13:30