Size an HMAC tag, check how your key is padded or hashed, and count the compression calls a verification costs.
HMAC pads the key to the hash block size, XORs it with two distinct constants, and runs the hash twice. That costs one extra block on each pass, so a short message still needs at least four compression calls, and a key longer than the block is hashed before use — extra key length beyond the block adds no strength. Truncating a tag or using a 12-byte key silently drops MAC security below the level your threat model assumes, and the compression count is what determines API signing throughput at scale.
HMAC Output
HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)); the tag is the full digest length and security = min(key bits, digest bits).
HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)); the tag is the full digest length and security = min(key bits, digest bits). HMAC pads the key to the hash block size, XORs it with two distinct constants, and runs the hash twice. That costs one extra block on each pass, so a short message still needs at least four compression calls, and a key longer than the block is hashed before use — extra key length beyond the block adds no strength.
Truncating a tag or using a 12-byte key silently drops MAC security below the level your threat model assumes, and the compression count is what determines API signing throughput at scale.
This calculator takes 3 inputs: Underlying hash, Key length, Message length. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Yes — FIPS 198-1 allows truncation to the leftmost bytes, and RFC 4868 uses 128-bit truncated tags in IPsec. Security becomes the truncated length, so never go below 128 bits for a general-purpose MAC.