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

I know that the HMAC is a message authentication code that uses a cryptographic key in conjunction with a hash function (SHA1 , MD5, etc.). The HMAC output is 160 bits for HMAC-SHA160 and 256 bits for HMAC-SHA256 bits that can be truncated according to the intented application. My quesion is about input...

What is the maximum input size of HMAC-SHA160 and HMAC-SHA256 ?

share|improve this question
up vote 7 down vote accepted

Well, SHA-1 and SHA-256 are both limited to inputs of no more than $2^{64}-1$ bits; the HMAC architecture itself prepends a logical IPAD (which is 512 bits); hence both HMAC-SHA160 and HMAC-SHA256 are both limited to inputs of no more than $2^{64} - 513$ bits, which is about 2 exabytes.

I rather suspect that this is not a serious limitation to your application...

As for potential security weaknesses if you hash messages this large, I am unaware of anything significant. Here is the most serious I can think of: if we assume HMAC-SHA160, and modify the first block of a $2^{55}$ block message (where each block is 512 bits), we might run into an internal hash collision (which would mean that the HMAC result wouldn't be affected); if the attacker asks us to HMAC $2^{53}$ such huge messages (all of which are the same except for the first block), then there is a good probability of having an internal collision somewhere (and this collision is detectable because the HMACs will be exactly the same); this collision would allow him to generate two other messages that will HMAC to the same value).

However, the amount of work this would take is huge (we're talking about HMACing a total of $2^{114}$ bytes of chosen text; that in itself is totally unrealistic).

share|improve this answer
Why do we need such huge messages for an internal collision? Wouldn't this work just as well for small messages? – Paŭlo Ebermann Aug 29 '13 at 7:39
@PaŭloEbermann: well, if the metric you're trying to optimize is "number of chosen plaintexts that are HMACed", huge messages are better (because there are more places for an internal collision to occur). If the metric is "total amount of chosen plaintext", then small messages are better (because you get better advantage from the birthday paradox) – poncho Aug 29 '13 at 12:20

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.