18
$\begingroup$

This question already has an answer here:

After reading a bunch of past stack exchange posts like this one and RFCs 5869, 2104, and 4868 I felt comfortable that a 32-byte key was sufficient for HMAC-SHA256. However, I am implementing my code in C# and someone pointed out to me that the Microsoft HMAC-SHA256 documentation recommends a 64-byte key:

The key can be any length. However, the recommended size is 64 bytes.

Is there any good reason to use a 64-byte key instead of a 32-byte key?

$\endgroup$

marked as duplicate by otus, yyyyyyy, e-sushi Apr 27 '16 at 12:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • $\begingroup$ 64 byte is the block size of SHA-256. $\endgroup$ – Artjom B. Apr 26 '16 at 14:36
  • $\begingroup$ 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 $\endgroup$ – Richie Frame Apr 27 '16 at 0:22
22
$\begingroup$

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 (requiring hashing effort slightly superior to what's devoted to bitcoin mining), 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, ignoring quantum computers.

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.

$\endgroup$
  • 1
    $\begingroup$ 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? $\endgroup$ – Ralph P Apr 26 '16 at 15:33
  • 3
    $\begingroup$ @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. $\endgroup$ – fgrieu Apr 26 '16 at 15:59

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