Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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? –  owlstead Apr 19 at 16:43
1  
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

1 Answer 1

up vote 4 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 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

Your Answer

 
discard

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.