# 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

As far as I know (which, admittedly, might be limited; I do not claim to possess encyclopedic knowledge of attacks on KDFs), there are no known practical attacks against KDF1 or KDF2 (which are also mentioned on this page, following ISO-18033-2) when instantiated with a secure hash function.

Regarding the relative security of these KDFs vs. HMAC-based KDFs like HKDF, it's worth noting that the HMAC security proof is based on the assumption that the compression function of the underlying hash is itself a PRF. Therefore, when used with any hash function to which the standard HMAC security proof applies, it seems that KDF1 / KDF2 should also be provably secure, at least as long as the master key length equals (or is padded to) the input block size of the hash.

-
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