4

Older hash functions like SHA-256 and SHA-512 are vulnerable to the length extension attack, which is problematic in the context of a MAC. There are several ways to prevent this:

  1. Use a newer hash function/XOF.
  2. Use HMAC or suffix MAC or envelope MAC.
  3. Truncate the output.
  4. Length prepending.
  5. Zero prepending.
  6. Double hashing.

However, is the length extension attack possible in the context of a KDF? Can we get away with avoiding these preventions? For example, if using this KDF based on prefix MAC:

KM = SHA-256(SKM || "1" || info) || SHA-256(SKM || "2" || info) || ...
samuel-lucas6
  • 1,783
  • 7
  • 17
  • I noticed this question hasn't clearly been answered on here so thought I'd ask to clarify for other people. – samuel-lucas6 Jan 20 '24 at 15:16
  • I don't get it. With a real key derivation function like HKDF, what is a length extension attack? Can you define it? What is the attack example if one accesses your derived key and uses it as an extension attack? – kelalaka Jan 20 '24 at 19:13
  • 1
    @kelalaka HKDF doesn't suffer from this attack, but it was also designed to prevent this. The issue is that KDFs, generally, depend on other inputs than the entropy source. Furthermore, it's not necessary for these inputs to be secret, and the "info" input is even allowed to attacker controlled. In such a case, we still expect the KDF to produce random looking keys (although we can't let the attacker control the salt). – Marc Ilunga Jan 20 '24 at 20:24
  • 1
    Imagine an application that uses unique "userId" as info to derive a key that is known sent to the user for some purpose, then uses "userId|stuff" to derive a key that stays on the server for some other purposes. With a good KDF like HKDF, we can expect that compromise of the key derive from "userId" is limited to that. However, with other KDF like a prefix key on MD hashes, this is not necessarily the case. But prefix MD hash would be a good KDF (expander) if we did restrict the info to say fixed lengths values for all invocations of the KDF. – Marc Ilunga Jan 20 '24 at 20:28

1 Answers1

2

Length extension attacks make sense for a key derivation function. For a good KDF, we expect that sub-keys are indistinguishable from randomly generated keys even if the attacker provides the info values. Suppose we limit ourselves to the tasks of key expansion; that is, we want to create sub-keys from a random primary key. A simple and elegant way to solve this is to use a secure pseudo-random function $f$ and generate subkeys $k_i = f(k, info_i)$. Now $f$ may be vulnerable to length extension that is given $f(k, x)$, it is possible to compute $f(k,x|y)$ without knowing $k$. Cleary outputs of $f$ are not indistinguishable from random values if the attacker controls the info value. Here's a distinguisher $D$ that works with overwhelmingly high probability.

  • $D$ queries the KDF on input $x$ and gets $k$
  • $D$ performs a length extension attack for $k, y$ assuming the KDF is $f$ and gets $k'$
  • $D$ queries the KDF on $x|y$ and gets $k''$. $D$ asserts that the KDF if $f$ if $k' = k''$.

It's clear that if $f$ has length-extension vulnerabilities, the outputs of $f$ are not indistinguishable from random. Hence $f$ is not a good KDF. Note that $f$ may still be a good KDF if we put some restrictions on the info value.

In general, KDF security roughly considers an adversary with some information about the entropy source and knows the salt. In one experiment, the adversary is given a key derived from using some entropy source, a salt and an info value provided by the attacker (only the info value); in the other, the adversary is given a randomly sampled key. Furthermore, the adversary can ask for other keys derived from the same randomness source. So if the KDF has the length-extension property, it's theoretically broken. This might also be a practical issue in certain circumstances.

The prefix-key KDF is not secure without restrictions on the info value. That is because given $k = k_1|k_2|...|k_n$; the attacker can mount a length extension on each $k_i$ when the hash is an MD hash. However, if all the info values were restricted to a prefix-free set, this would be a secure KDF. The reason is that key MD hash is also a cascade of PRF evaluation under the assumption that the compression function is a PRF which is a very reasonable assumption if the compression function is built following the Davis-Meier paradigm.

Marc Ilunga
  • 3,188
  • 1
  • 9
  • 22
  • Thanks for your answer. Do you think this influenced the design of NIST's One-Step KDF where the counter is put before the IKM - H(counter || IKM || info)? Rather than the KDF example I gave. As the HKDF paper points out, there's no official rationale. They also don't mention the length extension attack but perhaps because the info isn't attacker controlled by their definition of FixedInfo. – samuel-lucas6 Jan 21 '24 at 10:56
  • 1
    @samuel-lucas6, I will also be speculating here. But I have the same understanding as you have. The NIST specs seem largely focus on key establishment. In that scenario, the FixedInfo only provides minimal control. In those scenarios the attack is probably not feasible. But I could see the specs wanting to have some minimal defence there. In general for well-defined key schedule in AKE, the attack generally doesn't seem to apply since, the info values are usually fixed length providing minimal attacker control. I'll add this to the answer. – Marc Ilunga Jan 23 '24 at 11:26