Talk:HKDF

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Cryptography: Computer science

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

Untitled

The python example doesn't take into account some limitations over variables imposed by the RFC, such as length<=255*hash_len, and both length and ikm mustn't be empty. — Preceding unsigned comment added by Hackancuba (talk • contribs) 8 March 2017 (UTC)

The wikipedia page does not explain how HKDF works, or the steps performed within the algorithm. HappyDragon* (talk) 04:03, 18 August 2017 (UTC)[reply]

The python example also incorrectly concatenates the byte-value of "i" -- in my testing, it added the bytes for "[1]" (the ascii for the brackets plus the number in between). This should probably just be "t + info + chr(1+i)", also with bounds checking on lengths > 255 * hashlen as suggested above. (though the error resulting when it tries to generate chr(256) will provide bounds checking too. :) )) Dschuetz (talk) 18:23, 5 September 2018 (UTC)[reply]

I don't like having code example without explaining HKDF() parameters first, in general, too. About some missing checks, you're right. However, bytes([1]) is not "[1]", but b"\x01", unless you are using ~obsolete Python2 :) . Applying first two RFC test cases,

testcases = [
    ("0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b",
     "000102030405060708090a0b0c",
     "f0f1f2f3f4f5f6f7f8f9",
     42,
     "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5",
     "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865"),

    ("000102030405060708090a0b0c0d0e0f"
     "101112131415161718191a1b1c1d1e1f"
     "202122232425262728292a2b2c2d2e2f"
     "303132333435363738393a3b3c3d3e3f"
     "404142434445464748494a4b4c4d4e4f",

     "606162636465666768696a6b6c6d6e6f"
     "707172737475767778797a7b7c7d7e7f"
     "808182838485868788898a8b8c8d8e8f"
     "909192939495969798999a9b9c9d9e9f"
     "a0a1a2a3a4a5a6a7a8a9aaabacadaeaf",

     "b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
     "c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
     "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
     "e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
     "f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff",

     82,

     "06a6b88c5853361a06104c9ceb35b45c"
     "ef760014904671014a193f40c15fc244",

     "b11e398dc80327a1c8e7f78c596a4934"
     "4f012eda2d4efad8a050cc4c19afa97c"
     "59045a99cac7827271cb41c65e590e09"
     "da3275600c2f09b8367793a9aca3db71"
     "cc30c58179ec3e87c14c01d5c1f3434f"
     "1d87")
]

for t in testcases:
    ikm, salt, info, l, prk, okm = [ bytes.fromhex(x) if isinstance(x, str) else x for x in t ]
    k = hkdf(l, ikm, salt, info)
    if k == okm:
        print("OK")
    else:
        print("FAIL")

it passes. —Mykhal (talk) 20:55, 13 April 2021 (UTC)[reply]

Uses

The Uses section states: "To "extract" (condense/blend) entropy from a larger random source to provide a more uniformly unbiased and higher entropy", however, section 4 of the RFC is very clear that this is not possible (emphasis mine): "The extract step in HKDF can concentrate existing entropy but cannot amplify entropy" — Preceding unsigned comment added by ColinA3 (talk • contribs) 20:49, 9 May 2018 (UTC)[reply]

Example code

I hope it's not too much to ask that contributors test the example code when editing it. The previous couple of edits were blatantly wrong. Ewx (talk) 19:18, 18 February 2022 (UTC)[reply]

High min-entropy vs low min-entropy

@Ciphergoth In the last edit you changed the line to

taking a potentially non-uniform value of high min-entropy and generating a value indistinguishable from a uniform random value

The issue here is that, in the limit, a high min-entropy value would imply a uniform distribution already -- a low min-entropy value would imply a non-uniform distribution, which is what I'd think we would input here. The relevant line from the ietf:

One significant example is the derivation of cryptographic
keys from a source of low entropy, such as a user's password.  The
extract step in HKDF can concentrate existing entropy but cannot
amplify entropy

The original edit I did says nothing about magically adding entropy, but this is probably a good point to make clear, that there is *extraction* of existing entropy guarded by the hash rather than addition of entropy. TheDemx27 (talk) 16:33, 19 August 2024 (UTC)[reply]

"in the limit, a high min-entropy value would imply a uniform distribution already" - not if the input is longer than the output. Consider a 256-bit random value prefixed with 256 0s. That has a min-entropy of 256 bits, but it is not a uniform distribution, and it's HKDF's job to output a uniform distribution given that input. But a low min-entropy input necessarily means a low min-entropy output, which is therefore distinguishable from a uniform random value. ciphergoth (talk) 04:00, 20 August 2024 (UTC)[reply]

Have a look at the HKDF paper and do a search for the phrase "min-entropy" ciphergoth (talk) 14:20, 20 August 2024 (UTC)[reply]