Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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, like HMAC("T"), HMAC("Th"), HMAC("The"), HMAC("The "), etc.

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.

share|improve this question
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. – yarek May 4 '12 at 20:40
How do you expect to decrypt your "ciphertext"? – yarek May 4 '12 at 22:11
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 5 '12 at 8: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 6 '12 at 22:46
up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
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 4 '12 at 11:46
I thought HMAC was a specific few algorithms (i.e., HMAC-MD5,HMAC-SHA1,HMAC-SHA256, perhaps others). – Ricky Demer May 4 '12 at 13:09
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 4 '12 at 18:46
fixed ${}{}{}\:$ – Ricky Demer May 4 '12 at 22:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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