2
$\begingroup$

I have a key size of 128 bits. My message size is fairly short (e.g., 32 bits - and widely known). Although I am doing a SHA256, the result of the HMAC will be truncated to 128 bits.

So my question is: is there a significant strength difference between the following?

  1. HMAC256(K,m)
  2. HMAC256(K,m||K)
  3. HMAC256(K,K) 'note that in this case, there is no message) - I just need the result of the hash).

I am trying to prevent someone who knows m and the 128-bit result from figuring out the 128-bit key.

$\endgroup$
3
  • 4
    $\begingroup$ HMAC is secure, why do you think that you need the 2. and 3rd? $\endgroup$ – kelalaka Dec 7 '20 at 18:38
  • 1
    $\begingroup$ "I am trying to prevent someone who knows m and the 128-bit result from figuring out the 128-bit key." HMAC is for a situation where both parties share a key and message. It provides no actual guarantees about keeping either the key or the message secret, since those aren't design goals. What are you actually trying to do? $\endgroup$ – SAI Peregrinus Dec 7 '20 at 21:19
  • $\begingroup$ A MAC certainly guarantees that it keeps the key secret (it is one-way in the key). However it doesn't guarantee secrecy of the message. $\endgroup$ – cisnjxqu Dec 7 '20 at 23:30
0
$\begingroup$

So my question is: is there a significant strength difference between the following?

From a theoretical perspective, yes.

Namely the first one requires us to assume that the SHA-256 compression function behaves like a dual-input PRF whereas the last two add the assumption of circular security on-top. While assuming circular security is not entirely unheard of, it's one of those "non-standard" assumptions (PDF) - because you can't achieve it using only simple one-way functions - and should thus be avoided if it doesn't bring significant gains.

  • HMAC256(K,m) - Assuming that the SHA-256 compression function is a dual-input PRF (which is very reasonable as this even applies to the MD5 compression function), HMAC-SHA256 is a PRF and therefore when keyed with a uniformly random key any unique (per-key) message will output a value that is indistinguishable from a random string. Relevant papers are these three here.
  • HMAC256(K,m||K) - This likely has the same security properties as above but you'll also have to assume that HMAC offers circular security (which is not entirely unreasonable but gains you nothing over the first construction).
  • HMAC256(K,K) - This requires circular security again and because the message is not involved is more likely prone to repeat keys where repetition is unecessary thus potentially allowing easier higher-level attacks.
$\endgroup$
3
  • $\begingroup$ Thank you - I think that answers my questions. To answer some of the questions, I am trying to minimize the length of m - preferably to 0 (there are good reasons for this). I'm not trying to authenticate or protect m - I'm really trying to produce an HMAC result that can only be verified if one knows the original Key $\endgroup$ – user1655466 Dec 9 '20 at 15:31
  • $\begingroup$ @user1655466 The standard way to go about this would be to use HKDF-Expand or replace m with a fixed label (string) then. $\endgroup$ – SEJPM Dec 9 '20 at 15:34
  • $\begingroup$ I will look into that. Once again, thank you for your help. $\endgroup$ – user1655466 Dec 9 '20 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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