Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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$.

share|improve this question
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
up vote 5 down vote accepted

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.

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.