# Security consequences of HMAC(m, K) instead of the correct way HMAC(K, m)

I am wondering what is the security loss or consequences of accidentally misusing an HMAC API library in this context:

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))


Misused HMAC (the inputs to HMAC were accidentally swapped):

HMAC(m, K) = H((m ⊕ opad) || H((m ⊕ ipad) || K))


In this context the 'm' is actually some encrypted random data (used in the standard "Encrypt then MAC" scheme) and could be considered public from an attacker's perspective. The key is 256 bits. The HMAC is HMAC-SHA-256.

Does this swapping of the inputs to HMAC mean that there is now a complete break or complete loss in security or the MAC? Is there now a length extension attack applicable? Or is it not so easily exploitable, seeing that the data is still hashed together by the outer hash?

## 1 Answer


What about single-block messages? Well, it's unlikely that an attacker could find a structured pair of collisions $(\ipad\xor m_0, \ipad\xor m_1)$ and $(\opad\xor m_0, \opad\xor m_1)$ in $H$ for $m_0 \ne m_1$, but if they could, and if $H$ is Merkle–Damgård as is assumed in the usual HMAC security reductions (and if it's in the BLAKE2 or SHA-3 family, why bother with HMAC?), then $(m_0, m_1)$ would collide under $m \mapsto \HMAC_m(k)$ for any key $k$, enabling an attacker to immediately distinguish it from a random function or to forge messages authenticated under it.

• Thanks for your answer. I determined that the data size 'm' is 448 - 576 bits and the block size of SHA-2-256 is 512 bits. So that means some of the 'm' will get hashed directly i.e. the messages > 512 bits are vulnerable to collisions in H as you say. But can you quantify how vulnerable it is? Completely vulnerable or something like 2^64 more vulnerable? – b s Sep 2 '17 at 19:34
• The point is that, viewing HMAC as a generic way to build a PRF out of an MD hash function H, the PRF security of HMAC does not depend on H to be collision-resistant. However, the PRF security of your construction does depend on H to be collision-resistant. Thus the security of your construction relies on more hypotheses than the security of HMAC relies on. Collision resistance is necessary. Is collision resistance sufficient? I don't know. Is it secure if specifically instantiated with H = SHA-256? I don't know. These are separate questions that take more work to answer. – Squeamish Ossifrage Sep 4 '17 at 1:41
• For example, HMAC-MD5 appears to be a good PRF. But CAMH-MD5, if we call your construction HMAC backwards, is completely broken as a PRF. Thus the generic construction CAMH is broken in general because there are specific instances that are broken, but maybe there are also specific instances of it that are not broken. I don't know a specific attack on SHA-256 in that construction—but it's a bad idea to rely on the strength of imagination of a stranger on crypto.se as a criterion for security. – Squeamish Ossifrage Sep 4 '17 at 1:46