1
$\begingroup$

I have been asked to make a HMAC-SHA256 password digest from:

  • a password
  • some salt, and
  • an 80-bit secret key.

I've been advised that I should be using a key of 256 bits or more for HMAC-256.

The key I have is only 80 bits.

Is there any value in using sha256(key80bit) as the key for HMAC-SHA256, as it will not increase the entropy?

Are other KDFs or key-stretching algorithms preferable?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

I've been advised that I should be using a key of 256 bits or more for HMAC-256.

For HMAC the key size is more or less identical to the key strength. Although you should be using 256 bits for the key to have 256 bit strength other sizes are certainly possible.

Is there any value in using sha256(key80bit) as the key for HMAC-SHA256, as it will not increase the entropy?

No. HMAC will already hash the (padded) key together with the data as part of the algorithm, see the HMAC algorithm for details. If the key is too large ten it will be pre-hashed as well, but that doesn't seem to be the case in your protocol. You could see this as SimpleKDF(OKKDF(secret)); removing the SimpleKDF, i.e. the hash doesn't make any difference.

Are other KDFs or key-stretching algorithms preferable?

Yes, it makes sense to use a password hash / PBKDF instead, as that will at least increase the workload for an adversary. Use the salt for the PBKDF otherwise rainbow table attacks may be possible. The 80 bit secret can be used as "pepper". The salt input parameter would then be e.g. 128 bit salt + 80 bit pepper.

Of course, if you have an 80 bit key from a source then you might question the source. Keys should be 128 bit minimum nowadays.

As it is so short, please find the HMAC algorithm below, copied from the RFC:

  1. append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K will be appended with 44 zero bytes 0x00)
  2. XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad
  3. append the stream of data 'text' to the B byte string resulting from step (2)
  4. apply H to the stream generated in step (3)
  5. XOR (bitwise exclusive-OR) the B byte string computed in step (1) with opad
  6. append the H result from step (4) to the B byte string resulting from step (5)
  7. apply H to the stream generated in step (6) and output the result
Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ I think HMAC pre-hashes the key only when it's larger than the block size? For shorter keys, there's a 0-padding. $\endgroup$
    – Marc Ilunga
    Dec 14, 2022 at 11:12
  • 1
    $\begingroup$ Yeah, but the O-padding is a XOR of the value with a (larger) constant, it still includes the hashing part of the input. So regardless if the pre-hashing is used, the input message consisting of the password / salt / whatnot will still be hashed. $\endgroup$
    – Maarten Bodewes ♦
    Dec 14, 2022 at 11:58
  • $\begingroup$ I was more referring to the proposition of pre-hashing the key to then get the actual key that gets used for HMAC. And not just the part where the compression function is applied when computing the inner layer for HMAC. Which can be tested for by using a 65 bytes key with sha256 on hand and using sha256(65-bytes-key). But all inputs to HMAC get hashed : ) $\endgroup$
    – Marc Ilunga
    Dec 15, 2022 at 22:13
  • $\begingroup$ I got that, but I don't know what a difference it would make. If you can think of any I'll be all ears. $\endgroup$
    – Maarten Bodewes ♦
    Dec 15, 2022 at 22:16
  • $\begingroup$ I also don't think it would make a difference. I was just mentioning in which case we have actual functional equivalence. But otherwise I agree with your answer : ) $\endgroup$
    – Marc Ilunga
    Dec 17, 2022 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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