6

Let's say I have a long sentence, like "The quick brown fox jumped over the lazy dog." Let's further say that I need to keep this string encrypted, so I use an HMAC. Let's further further say I want to be able to do prefix searches for this string, so I also store all possible prefixes of this string, for example:

$\operatorname{HMAC}_K(\text{"T"})$, $\operatorname{HMAC}_K(\text{"Th"})$, $\operatorname{HMAC}_K(\text{"The"})$, $\operatorname{HMAC}_K(\text{"The "})$, etc. where $K$ is the key.

I recognize there are some weaknesses between rows here involving overlap, but what I'm interested in is whether having this one row's set of HMAC values is enough to make things insecure. Could an adversary work out the key, or any part of the plaintext, given a series of HMAC values for all of a given input's prefix values?

Feel free to use any flavor of HMAC if it'll help you argue that there's a weakness.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
Brandon Yarbrough
  • 163
  • 4
  • 1
    Please note that MACs are not designed for encryption - they provide message authentication only, and may naturally leak some bits of information about the message. – yrk May 04 '12 at 20:40
  • How do you expect to decrypt your "ciphertext"? – yrk May 04 '12 at 22:11
  • 1
    HMAC (instantiated with a particular hash function, e.g. HMAC-MD5) is a function with two arguments: the key, which is supposed secret; and the message to authenticate. Therefore HMAC("T") is ill defined. – fgrieu May 05 '12 at 08:58
  • Yes, sorry. I was indeed assuming a particular secret key, and I misused "ciphertext." The actual value would be encrypted on its own. The HMACs would be for prefix lookup. Sorry for the confusion! – Brandon Yarbrough May 06 '12 at 22:46

2 Answers2

4

I'll start by assuming that your instance of HMAC is a secure MAC function, which comes down to making various assumptions about the hash function it is instantiated with.

If this assumption holds, then an adversary will not be practically able to recover the key, even if they have access to a large number of MACs and the corresponding plaintexts, or even if they get to choose their own plaintexts — if it was possible for them to obtain the key, they'd be able to compute their own MACs and thus commit existential forgery, contradicting the assumed security property.

As for plaintext recovery, in general there's nothing that prevents a MAC function which is secure against existential forgery from leaking some information about the input plaintext, and indeed it's not hard to delibrately construct examples of such MACs (as Ricky Demer's answer shows).

However, the security proof of HMAC given by Bellare actually proves a stronger property, namely that HMAC is a PRF as long as the compression function of the hash it is instantiated with is also a PRF (or, more generally, than HMAC is a privacy preserving MAC (PP-MAC) as defined by Bellare, as long as the compression function is also a PP-MAC and the hash function itself is computationally almost universal (cAU); see remark on Lemma 4.2). This is a rather strong security property, and it indeed shows that, as long as the hash function satisfies the assumptions of the proof, HMAC will not leak information about the plaintext to an adversary who does not possess the key.

Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
0

Have F be any HMAC. $\:$ Have G be given by [the first bit of G's output is [if the plaintext is not the empty string then the first bit of the plaintext else 0] and the rest of G's output is the same as F's output]. $\:$ G's output is exactly one bit longer than F's output, and G is also a MAC (since someone with black box access to F could easily simulate having black box access to G and then have their guess for F be the result of dropping the first bit from their simulated guess for G). $\:$ One can trivially work out the first bit of a non-empty plaintext from G's output on that plaintext, as the first bit of G's output on that plaintext.

It is not required that HMAC's provide privacy, it is only required that HMAC's provide authenticity.
What would work is a [pseudorandom function family
whose instances have full domain] instead of just an HMAC.

  • Please note that HMAC is a quite specific algorithm, not the name of a type of function - I think you mean MAC here where you wrote HMAC. – Paŭlo Ebermann May 04 '12 at 11:46
  • I thought HMAC was a specific few algorithms (i.e., HMAC-MD5,HMAC-SHA1,HMAC-SHA256, perhaps others). –  May 04 '12 at 13:09
  • 1
    You can build a HMAC from every (cryptographic) hash function (and the HMAC specification says how - this is what I meant with "specific algorithm"). But your construction of G quite certainly does not yield such a HMAC function, while it might create a valid (and secure) MAC. – Paŭlo Ebermann May 04 '12 at 18:46
  • fixed ${}{}{}:$ –  May 04 '12 at 22:32