i failed to find explicit definition of hash output size and mac_key_size for hmac based on SHA384 and SHA512. RFC5246 specifies:
but defines only
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.Sign up to join this community
Those input key / output sizes are the most suitable because it makes sure that the minimum amount of security that can be provided by the hash is reached.
However, since the minimum security of SHA-256 is 256 bits it is not a huge problem to take the leftmost 128 bits or to use a smaller key size.
For HMAC there is no default key size, so officially it should be mentioned or be able to be calculated from the protocol. The common default is to have a key of the same size as the output size.
However, the default output size is indeed simply identical to the output size of the hash. So unless explicitly mentioned, that's the MAC output size to use.
Let's quote the relevant HMAC RFC that is listed in the references:
The key for HMAC can be of any length (keys longer than $B$ bytes are first hashed using $H$). However, less than $L$ bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than $L$ bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.)
and for the output size:
Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker).
We propose denoting a realization of HMAC that uses a hash function $H$ with $t$ bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function and with the output truncated to 80 bits. (If the parameter $t$ is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.)
I'll not dwell on making proposals in RFC's. That should just have been a requirement to name it HMAC-'H'-'t', not a proposal. If people want to ignore the RFC than that's up to them.
It seems that the RFC failed to communicate clearly that
mac_length in the table is the HMAC output size in bits. HMAC is a type of MAC, so the output size has been specified. The key size is in the rightmost column called
mac_key_size. So for the TLS protocol the key size and output size configuration parameters have been explicitly defined - no need to rely on defaults.
Given that MD5 has a size of 128 bit (16 bytes), SHA-1 of 160 bits (20 bytes) and SHA256 of 256 bits (32 bytes) and that these numbers are exactly reflected in the
mac_key_size I would assume that these sizes reflect the output size of the hash used. This also matches the definition of the HMAC used in TLS where the last step is to apply the hash and use its full output as result. Similar the HMAC definition recommends the output length of the hash as the minimal (and also probably most suitable) key length.
With this in mind the size for SHA-384 will be 384 bits (48 bytes) and for SHA-512 512 bits (64 bytes).