1

If a PPT adversary can influence the key of a MAC function, is it still secure?

For example, if we define $f$ as follow:

$f(r,x) = HMAC_{(k\oplus r)}$(x)

If the adversary has oracle access to $f$, how likely he can predict the key $k$?

For respecting the persons who have answered the above question, I do not change it. The actual scenario is as follows:

I have a module that gets $(m,r)$ and generates $(m,x,HMAC_{k \oplus r}(m \parallel x))$ where the $k$ is the secret of the module and $x$ is the message added by the module. So:

$f(m,r)=(m,x,HMAC_{k \oplus r}(m \parallel x))$

Can I claim that every tuple $(m,x,t)$ s.t. $t=HMAC_{k \oplus r}(m \parallel x))$ is generated by the module?

P.S. I am still curious about the above claim. But, I just noticed that if I change $f$ as follows:

$f(m,r)=(m,x,HMAC_k(m \parallel x \parallel r))$

then, I can claim every tuple $(m,x,t)$ s.t. $t=HMAC_k(m \parallel x \parallel r))$ is generated by the according to the definition of MAC.

Reza
  • 75
  • 6
  • What can $r$ depend on? – Maeher Oct 27 '19 at 09:36
  • If an adversary has access to such an f, this is called related-key attack security. – SEJPM Oct 27 '19 at 11:23
  • @Maeher $r$ is an arbitrary input – Reza Oct 27 '19 at 13:19
  • It's an adversarially chosen input. I get that. But you fail to specify the exact scenario. If $f$ an oracle the attacker can query? How often can they query it? What other inputs and/or oracles does the attacker have? Specify the exact security definition you have in mind. – Maeher Oct 27 '19 at 13:29
  • @Maeher I edited the question. Hope it is clear now :) – Reza Oct 27 '19 at 13:43
  • 1
    When you say ‘HMAC’, do you really mean only HMAC (with an unspecified hash function) and not an arbitrary MAC? – Squeamish Ossifrage Oct 27 '19 at 15:35
  • @SqueamishOssifrage I mean SHA256 if it effects the answer – Reza Oct 27 '19 at 15:37
  • It makes the question substantially different. You asked about PPT, but this means you're talking about a family of MACs indexed by a security parameter—which is not what you get by specifying HMAC-SHA256. You started by seeming to ask in general whether a secure MAC remains secure if the adversary is granted access to a to a related-key oracle (answer: no; counterexample: AES-256 related-key attacks), but for the specific case of HMAC-SHA256, it's probably fine. – Squeamish Ossifrage Oct 27 '19 at 15:42
  • Correction: nope, not fine. Related keys are a mess. Just don't do it! – Squeamish Ossifrage Oct 27 '19 at 15:50
  • @SqueamishOssifrage Any reason why you changed your mind on HMAC? – Maarten Bodewes Oct 31 '19 at 15:20
  • 2
    @MaartenBodewes Because in HMAC, the key $k$ is used once via $k \oplus \mathrm{ipad}$ and once via $k \oplus \mathrm{opad}$, which will interact rather easily with the pattern of related keys allowed, potentially leading to trouble. (Also see SEJPM's citation. on HMAC with related keys.) – Squeamish Ossifrage Oct 31 '19 at 16:32

1 Answers1

1

If a PPT adversary can influence the key of a MAC function, is it still secure?

In general probably no if you make no restrictions on the ways the key can be influenced. In particular the answer is "no" when you rely on your MAC actually being a PRF for your security proof (like HMAC does). This means that if your MAC relies on this then you need some additional argument for related-key security, as PRFs cannot be secure against all classes of related-keys. For a proof and more background on this see Proposition 8.4 of the original paper that introduced this (PDF).

If the adversary has oracle access to $f$, how likely he can predict the key $k$?

Cryptography isn't about "can you predict the key" because you can usually build schemes that don't use their key-input and are thereby trivially secure if all you want is the key.

A more interesting question would be, if an attacker has access to (this concrete) $f$, how easy is it to forge tags? This has in fact been studied for HMAC and keys related by a constant leading to an attack that runs in time $2^{n/2}$ with $n$ being the HMAC's output length.

SEJPM
  • 45,967
  • 7
  • 99
  • 205
  • "In particular the answer is "no" when your MAC also happens to be a PRF (like HMAC is)." Just because it's no longer a PRF under a related key attack does not mean it can't still be a secure MAC. But the actual attack scenario in the question is still underspecified. – Maeher Oct 27 '19 at 14:31
  • @Maeher ok, I edited to clarify that "only" the proof breaks and not neccessarily security (though of course one shouldn't rely on unproven security) – SEJPM Oct 27 '19 at 14:40