Message authentication codes: HMAC, CMAC, GMAC & Poly1305

A message authentication code (MAC) is a short tag computed from a secret key and a message. Anyone who holds the same key can recompute the tag and compare: if it matches, the message came from someone holding the key (authenticity) and wasn't modified on the way (integrity). Without the key, producing a valid tag for any message the attacker hasn't already seen tagged should be infeasible, even after watching as many genuine message/tag pairs as they like. That property has a name, existential unforgeability under chosen-message attack, and it's the bar every construction in this module is measured against.

Two things a MAC does not do. It doesn't hide the message: the tag travels next to readable data unless you also encrypt. And it doesn't give non-repudiation: the verifier holds the same key as the sender, so either of them could have produced the tag, and a third party can't tell which. When you need 'only the sender could have made this', you need a digital signature instead.

The four MACs in this module come from three different building blocks. HMAC is built from a hash function. CMAC is built from a block cipher. GMAC and Poly1305 are built from a universal hash (polynomial evaluation over a finite field) masked with a one-time value, a design that goes back to Wegman and Carter in 1981. That last family is very fast, and it comes with a hard rule the other two don't have: never reuse the nonce or one-time key.

HMAC (RFC 2104, standardized by NIST as FIPS 198-1) wraps a hash function H around the key and message in two nested passes. The key is first brought to the hash's block size (64 bytes for SHA-256): a key longer than that is hashed down first, and a shorter one is padded with zero bytes, giving K′. K′ is XORed with two fixed constants, ipad (0x36 repeated) and opad (0x5c repeated), to make an inner key and an outer key. The inner hash covers the message; the outer hash covers the inner hash's output.

The nesting is what defeats the length-extension attack covered in the hash functions module. A naive H(K ‖ m) with SHA-256 leaks its internal state as the tag, so an attacker can append data and keep hashing. In HMAC the tag is the output of a second, separately keyed hash, so there's no exposed state to continue from. HMAC's security proof also needs less from the hash than you might expect: it relies on the compression function behaving like a pseudorandom function, not on collision resistance. That's why HMAC-SHA-1 isn't broken the way SHA-1 signatures are, though new designs should still use HMAC-SHA-256 or stronger.

HMAC is everywhere a shared secret needs to vouch for data: JWTs signed with HS256, webhook signatures, AWS Signature Version 4, TLS 1.3's Finished messages and its HKDF key schedule, and IPsec (where HMAC-SHA-256 is truncated to 128 bits as HMAC-SHA-256-128, RFC 4868). The HMAC Playground tool computes one in your browser.

Worked example, from RFC 4231's test case 2 and checked against Node's crypto module and OpenSSL: key 'Jefe', message 'what do ya want for nothing?'. Both are shorter than a block, so K′ is the four key bytes followed by 60 zero bytes. The tag is 5bdcc146 bf60754e 6a042426 089575c7 5a003f08 9d273983 9dec58b9 64ec3843.

The oldest way to build a MAC from a block cipher is CBC-MAC: encrypt the message in CBC mode with a zero IV and keep only the last ciphertext block. Each block is XORed into the running state and encrypted, so the final block depends on every bit of the message. For messages that are all the same, fixed length, CBC-MAC is provably secure. Payments has used it for decades: the 3DES CBC-MAC behind EMV application cryptograms is the same construction (this site's DES library implements it for the ARQC/ARPC simulator), and ISO 9797-1 standardizes several variants with extra output transformations.

Once message lengths can vary, plain CBC-MAC falls apart. Suppose an attacker has seen the tag t of a one-block message m. CBC-MAC of the two-block message m ‖ (m ⊕ t) is computed as E(E(m) ⊕ m ⊕ t) = E(t ⊕ m ⊕ t) = E(m) = t. So the attacker has a valid tag for a brand-new message without ever touching the key. We checked this with AES-128 in Node: the one-block message 'PAY 100 EUR TO A' and the forged 32-byte message both get the tag 4b97ca5b740a7096c14c034d2df294b2.

CMAC (NIST SP 800-38B, with the AES version also published as RFC 4493; it's Iwata and Kurosawa's OMAC1, and ISO 9797-1:2011 lists it as MAC algorithm 5) repairs CBC-MAC by treating the last block differently. From the key it derives two subkeys: encrypt an all-zero block to get L, then 'double' L in the field GF(2¹²⁸) to get K1, and double again for K2. Doubling is a one-bit left shift, plus an XOR of the constant 0x87 into the last byte whenever the bit shifted out was a 1 (for 64-bit ciphers like 3DES the constant is 0x1B).

If the message ends on a full block, that last block is XORed with K1 before the final encryption. If it doesn't (including the empty message), the last block is padded with a single 1 bit and then zeros, and XORed with K2. Because the attacker can't know K1 or K2, they can't predict how a message will be closed off, and the m ‖ (m ⊕ t) trick stops working. Using different subkeys for the two cases is also what stops a padded message from colliding with an unpadded one.

CMAC is the MAC to reach for when you have AES (or 3DES) but no hash function, which is common in smart cards, HSM-based payment schemes, and embedded radios. TR-31 / ANSI X9.143 key blocks versions B and D use TDES-CMAC and AES-CMAC both to derive their keys and to MAC the block (see the TR-31 Playground tool). LTE and 5G protect signalling integrity with AES-CMAC (the 128-EIA2 algorithm), and IPsec has AES-CMAC-96 (RFC 4494). Its cost is one block-cipher call per 16 bytes, run strictly in sequence, so it can't be parallelized the way GMAC can.

Worked example, from RFC 4493 and checked with OpenSSL and a from-scratch implementation in Node: key 2b7e151628aed2a6abf7158809cf4f3c.

AES-GCM (covered in the AES module) authenticates its ciphertext with GHASH, a polynomial hash in GF(2¹²⁸). The hash key H is the encryption of an all-zero block, H = E_K(0¹²⁸). The data (additional authenticated data, then ciphertext, then a block holding both lengths) is split into 128-bit blocks X₁ … Xₙ, and GHASH evaluates them as a polynomial at H. The result is masked by XOR with E_K(J₀), an encryption of the nonce-derived initial counter block, to give the tag.

GMAC (also defined in NIST SP 800-38D) is GCM with nothing to encrypt: every input goes in as additional authenticated data, and the output is just the tag. That makes GMAC a nonce-based MAC, unlike HMAC and CMAC. It's useful exactly where you want integrity without confidentiality at line rate: MACsec (IEEE 802.1AE) runs GCM-AES on Ethernet links and can operate in integrity-only mode, and IPsec defines AES-GMAC for ESP and AH (RFC 4543). GHASH's multiplications are independent of each other, and modern CPUs have a carry-less multiply instruction (PCLMULQDQ on x86, PMULL on Arm), so GMAC parallelizes and runs very fast.

The price is the nonce. If two messages are ever tagged under the same key and nonce, XORing the two tags cancels the E_K(J₀) mask and leaves a polynomial equation in H that an attacker can solve for its roots. With H in hand they can forge tags for any message under that key, not just one. This is Joux's 'forbidden attack', and it has been found in real TLS servers that reused GCM nonces. Short tags are also weaker than they look with GCM: SP 800-38D allows 96 to 128 bits generally and 32 or 64 bits only under strict limits on usage.

WebCrypto can compute a real GMAC: run AES-GCM encryption over an empty plaintext and pass the message as additionalData. As a check against the GCM specification's first test case, an all-zero key and nonce with no data at all gives the tag 58e2fccefa7e3061367f1d57a4e7455a, which Node and OpenSSL both reproduce.

Poly1305, designed by Daniel J. Bernstein (published 2005 as Poly1305-AES), takes a 32-byte one-time key split into two halves, r and s. The message is cut into 16-byte chunks; each chunk gets a 0x01 byte appended (so trailing zeros still count) and is read as a little-endian number. An accumulator adds each chunk and multiplies by r, all modulo the prime 2¹³⁰ − 5, which gives the algorithm its name. At the end, s is added and the result is truncated to 128 bits to form the tag. Before use, r is 'clamped': certain bits are forced to zero so the multiplication can be done quickly with ordinary 64-bit arithmetic.

Poly1305 is secure only if each key (r, s) authenticates a single message. Tag two messages with the same key and the attacker can solve for r and forge freely. That's why it's always paired with something that hands it a fresh key per message. In ChaCha20-Poly1305 (RFC 8439, covered in the stream ciphers module), the one-time key is the first 32 bytes of ChaCha20's keystream for that nonce, block counter 0. So the rule becomes the familiar one: never reuse a nonce under the same ChaCha20 key. The construction is what TLS 1.3, QUIC, WireGuard, and OpenSSH's chacha20-poly1305@openssh.com cipher use.

Poly1305 needs no block cipher and no special CPU instructions, so it's fast in plain software. That's a big part of why ChaCha20-Poly1305 is preferred on phones and small devices without AES hardware.

Worked example, RFC 8439 section 2.5.2, checked with OpenSSL and a 20-line BigInt implementation in Node: the 34-byte message 'Cryptographic Forum Research Group' under the key 85d6be78 57556d33 7f4452fe 42d506a8 0103808a fb0db2fd 4abff6af 4149f51b gives the tag a8061dc1305136c6c22b8baf0c0127a9.

In practice the choice is usually made for you by the primitive you already have. If you're using an AEAD (AES-GCM or ChaCha20-Poly1305), the MAC is built in; don't add another. If you need a standalone MAC and have a hash function, HMAC-SHA-256 is the default: no nonce to manage, hard to misuse, and available in every library including WebCrypto. If you have only a block cipher, as in a smart card or a payment HSM's TDES/AES scheme, use CMAC. Reach for standalone GMAC when you need integrity-only protection at very high data rates and can guarantee unique nonces. The modes & AEAD module covers how a cipher and a MAC are combined safely, and the AEADs that do it for you.

Compare tags in constant time. A byte-by-byte comparison that stops at the first mismatch leaks, through timing, how many leading bytes of a guess were right, which lets an attacker build a valid tag one byte at a time. Use crypto.timingSafeEqual in Node, hmac.compare_digest in Python, or let crypto.subtle.verify do the comparison. The side-channel module covers why.

Encrypt, then MAC. When you combine a separate cipher and MAC yourself, compute the MAC over the ciphertext (and nonce and any header), and check it before decrypting anything. TLS's older MAC-then-encrypt order is the root of the Lucky Thirteen and padding-oracle attacks, and it's why RFC 7366 added an encrypt-then-MAC extension for TLS 1.2. Better still, use an AEAD and the order is handled for you.

Use separate keys for separate jobs. Don't use the same key for encryption and for the MAC, or the same MAC key in two different protocols. Derive distinct keys with HKDF, or with the CMAC-based KDF of SP 800-108 as TR-31 does. And make what you MAC unambiguous: if you MAC a concatenation of fields, include their lengths, or 'ab' ‖ 'c' and 'a' ‖ 'bc' get the same tag.

Size tags for online guessing. An attacker with no key can only guess, and each guess at a t-bit tag succeeds with probability 2⁻ᵗ. Truncating a tag is allowed and common (HMAC-SHA-256-128 in IPsec, 8-byte MACs in payments), but every bit you drop doubles the attacker's odds per attempt.