# 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?

WARNING: above only shows KDF1/2 in their least complex form, using only a single output block and with an empty $OtherInfo$. I'll work on a better formulated question that takes this into account.

-
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? –  owlstead Apr 19 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 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... –  owlstead Apr 21 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 at 12:26
I should, perhaps, have mentioned the optional "OtherInfo" concatenated on, e.g. $H(x | y | OtherInfo)$. –  Matt Nordhoff May 11 at 12:45
@MattNordhoff I guess that if you conclude that $OtherInfo$ is malleable by an attacker that you may run into length extension attacks, which are not applicable to KDF1 & 2 if they don't contain $OtherInfo$, I'll check out the issue further. –  owlstead May 11 at 13:03
@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 at 13:30
Yes, possibly, that's why I want to check out this issue further :) Normally, the $OtherInfo$ is controlled by the party that creates the keys though, so in that case the attack does not apply at all. You'd better be sure about that though. –  owlstead May 11 at 14:02