# What size should the HMAC key be with SHA-256?

I'm trying to generate a secret key to be used for HMAC SHA-256 signature processing. I've seen many sample of keys with variable length from 32 characters to 96 characters.

What is the ironclad rule for this key size?

• 64 byte is the block size of SHA-256. Apr 26, 2016 at 14:36
• You could always expand a 256-bit key with a 512-bit hash such as SHA512, if you do not have a shortage of cpu power Apr 27, 2016 at 0:22

Short answer: 32 bytes of full-entropy key is enough.

Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger keys; that's because in the later case, the key is hashed to 32 bytes before use. It is an argument to use a 64-byte key: it's the size giving the maximum resistance to brute force key search; and beside the key being harder to manage than a 32-byte one, using 64 bytes does not harm security, and leaves speed almost unchanged (there is no additional hashing done).

On the other hand, 256 bits of security is way more than enough for anything even vaguely foreseable, including quantum computers. If MACs are computed at a rate of $$2^{88}$$ per year (less hashing effort than dilapidated in bitcoin mining each year in [2018-2023]), and they could be checked among known MACs for $$2^{32}$$ different keys at that rate (arguably requiring more additional effort than hashing), and we wanted residual odds of $$2^{-35}$$ that any key is found within 32 years, 160 bits of key entropy is enough, at least ignoring CRQC.

HMAC-SHA-256 is designed for 256-bit (32-byte) cryptographic resistance in mind, with no strong argument that using a key with more entropy improves the security; beyond that, there is no assurance given by the best security proof available (Mihir Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance, with extended abstract in Crypto 2006 Proceedings). Thus if the key is full-entropy, there is no strong argument to use a key of more then 32 bytes.

If the key is not known to be full-entropy, there is an obvious, reasonable argument that large keys are necessary. For example, if the key was a Diceware passphrase, which has an entropy of $$5\log_2(6)\approx12.9$$ bit/word, there needs to be 20 words in the key, that is up to 139 characters (with 6 characters per word, and space between words), to reach 256 bits of entropy.

Originally an answer to this question.

• Thanks...that makes sense. I plan to use PBKDF2 with a user-supplied password, 256-bit salt, and a high number of iterations to derive a 256-bit master key. Then I plan to use HKDF-Expand to derive a 256-bit AES key and a 256-bit HMAC key from the master key. It seems like the likely attack vector would be a dictionary attack on the password, and thus bumping the HMAC key up from 256 bits to 512 bits wouldn't provide much of an increase in practical security. Would you agree? Apr 26, 2016 at 15:33
• @Ralph P: That seems to make sense. The weakest links are likely to be the quality of the password combined with the entropy-stretching of PBKDF2 (which is far from being the best entropy-stretching function around), the ability of the user to recognize where s/he can safely type the password, and the integrity of the device used to process the password; any of these will be incomparably weaker than 256-bit.
– fgrieu
Apr 26, 2016 at 15:59
• @fgrieu A MAC key of 256 bits is indeed far beyond the capabilities of a brute force attack, but technically for a MAC we need EUF-CMA which has birthday bound. So would the security level of a 256 bit MAC key not be 128 bits? Dec 30, 2021 at 9:17
• @eddydee123: Under CMA, $2^{k/2}$ queries of a $k$-bit MAC will find a collision with sizable probability, but not a forgery, that is computing the MAC of a message never submitted to the MAC-computing oracle. Thus birthday attacks do not work on a MAC. This was asked there recently.
– fgrieu
Dec 30, 2021 at 9:44

The only rule for the key is that it should at least contain 256 bits of randomness. If the key is smaller you may not get the full security of HMAC-SHA-256. The full security of HMAC is basically identical to the output size. Unless you are trying to protect yourself against quantum computers you should be able to get away with a key that contains 128 bits of entropy though.

Here's the text from the HMAC standard captured in RFC 2104:

The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. In any case the minimal recommended length for K is L bytes (as the hash output length).

So preferably the entropy of the 256 bit key should be condensed into 32 bytes. What you are talking about is probably the hexadecimal representation of those 32 bytes. If the key is too large it may affect performance and efficiency of the HMAC function. Many libraries only allow binary to be inserted using octets bytes anyway, so in that case it makes sense to hex decode the key before you use it.

HMAC uses a hash internally, which is defined for any bit string. This hash is used both for the key as for the value. So in principle you can feed it anything you want up to the maximum hash size (which you will never reach).

Definition from Wikipedia:

{\begin{aligned}\operatorname {HMAC} (K,m)&=\operatorname {H} {\Bigl (}{\bigl (}K'\oplus opad{\bigr )}\parallel \operatorname {H} {\bigl (}\left(K'\oplus ipad\right)\parallel m{\bigr )}{\Bigr )}\\K'&={\begin{cases}\operatorname {H} \left(K\right)&K{\text{ is larger than block size}}\\K&{\text{otherwise}}\end{cases}}\end{aligned}}

Note the repetition of the key with regards to efficiency.

• HMAC has proven to be relatively resilient to abuse, but nothing can protect a cryptographic primitive against keys with too little entropy.... Dec 23, 2015 at 10:37
• I would say that even 256 bits is not ironclad. If 128-bit security is the target you still probably don't want to use MD5 or SHA-1 so SHA-256 it is.
– otus
Dec 23, 2015 at 11:12
• @otus If I remember correctly the 256 bit (or, more precisely, the output size of the hash) is in the HMAC standards. I was just parotting those. I would not bat an eye if I saw smaller key sizes, but I'm a bit worried about recommending them. Dec 23, 2015 at 11:35
• The RFC "strongly discourages" keys shorter than the hash length, but allows any length. NIST says only that keys must match or exceed the required security level for the data. Also, even keys longer than the hash length can give extra security (because the padded keys differ).
– otus
Dec 23, 2015 at 11:46
• @archie, I meant longer than the hash output. Keys longer than the block size are hashed down initially, but for SHA-2 the block size is twice the output length.
– otus
Jan 20, 2016 at 8:16

The concrete answer is B, as defined in RFC 2104

The authentication key K can be of any length up to B, the block length of the hash function. (B=64 for all the above mentioned examples of hash functions)

It is difficult to determine what is meant by "the block length of the hash function", so let's go digging in another RFC for information!

SHA256_Message_Block_Size = 64

Then a lot further down, on Pages 69-70:

/*
* USHABlockSize
*
* Description:
*   This function will return the blocksize for the given SHA
*   algorithm.
*
* Parameters:
*   whichSha:
*     which SHA algorithm to query
*
* Returns:
*   block size
*
*/
int USHABlockSize(enum SHAversion whichSha)
{
switch (whichSha) {
case SHA1:   return SHA1_Message_Block_Size;
case SHA224: return SHA224_Message_Block_Size;
case SHA256: return SHA256_Message_Block_Size;
case SHA384: return SHA384_Message_Block_Size;
default:
case SHA512: return SHA512_Message_Block_Size;
}
}

Picking anything greater than B will get hashed to L, the output of the hash function H.

B offers more security than L, so pick B.

• In most uses, the security of HMAC is bounded by the length of the MAC, which is L. So a larger key (assuming full entropy, which is normally the case for a key) does not offer more security. The block length is irrelevant (it's always larger than the hash length). Aug 31 at 17:00