3
$\begingroup$

For background, a HKDF (hmac based key derivation function) takes the form of Ko = KDF(Ki, Label, Context, Len) where Ki is the input key and Ko is the (usually longer) output key, computed by iteratively applying HMAC (initially keyed by Ki) until the desired length is reached. See pseudocode here.

Can I assume HKDF is one-way, namely given Ko it's hard to guess Ki? It seems intuitive, as HMAC output should not lead to recovery of the MAC key.

$\endgroup$
1
  • 2
    $\begingroup$ This security property should probably follow rather straightforwardly from HKDF's formal security proofs and analysis. Here's the paper in case I don't find time to write things up myself. $\endgroup$ – SEJPM Nov 25 '20 at 21:51
1
$\begingroup$

Very shortly, yes, this is the case.

A KDF is secure if an adversary cannot make a distinction between the output of the KDF and random output (with a larger probability of ${1 \over 2} + \epsilon$). The attacker gets to know the salt and is able to choose the $Info$ parameter and output size (i.e. all the other input parameters) as well as any previous output. This is basically a plaintext excerpt of chapter 3 of the original paper "Cryptographic Extraction and Key Derivation: The HKDF Scheme".

It is easy to see that the above definition fails if the input source keying material is known to the attacker. Hence it is of vital importance that the KDF is one-way with regards to the input keying material. Usually all the output of a KDF is generated by one-way functions in the first place, usually a hash based MAC. In the case of HKDF this is HMAC. In the paper they generally talk about a one-way function as primitive.

This is rather expected; the whole idea of key derivation is to decouple the output from the input to any adversary. Other methods of establishing a key may not carry this property though; there is a reason why HKDF has decided to include a security definition of KDF inside the paper instead of pointing to another document. The fact that the security of HKDF is formalized is one of the big strengths of HKDF and has probably helped it getting standardized by NIST.

HMAC is relatively complex because it requires protection against length extension. When e.g. SHA-3 is used you could use KMAC or a similar construction instead. KMAC already generates as many output bits as required, which makes a KDF-expand function easier to define as well.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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