HMAC256(K,m) vs HMAC256(K,K) 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?

HMAC256(K,m)
HMAC256(K,m||K)
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.
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 &quot;non-standard&quot; 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.