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?
$\begingroup$
$\endgroup$
$\begingroup$
$\endgroup$
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.
Preferably this 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 (of course). Many libraries only allow binary to be inserted using octets (bytes).
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:
${HMAC}(K,m) =H{\Bigl (}(K\oplus opad)\;||\;H{\bigl (}(K\oplus ipad)\;||\;m{\bigr )}{\Bigr )}$
note the repetition of the key with regards to efficiency.
answered Dec 23 '15 at 10:04
-
$\begingroup$ HMAC has proven to be relatively resilient to abuse, but nothing can protect a cryptographic primitive against keys with too little entropy.... $\endgroup$ – Maarten Bodewes♦ Dec 23 '15 at 10:37
-
2$\begingroup$ 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. $\endgroup$ – otus Dec 23 '15 at 11:12
-
1$\begingroup$ @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. $\endgroup$ – Maarten Bodewes♦ Dec 23 '15 at 11:35
-
1$\begingroup$ 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). $\endgroup$ – otus Dec 23 '15 at 11:46
-
2$\begingroup$ @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. $\endgroup$ – otus Jan 20 '16 at 8:16
$\begingroup$
$\endgroup$
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!
From RFC 4634, Page 18
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.
