RFC 4493 specifies AES-CMAC, a message authentication code built on the AES block cipher. It sounds obscure, but if you've ever used IKEv2, IPsec ESP with GMAC fallback, IEEE 802.1AE (MACsec), 802.11i (WPA2), Bluetooth pairing, EMV chip cards, or the SIV mode from RFC 5297, you have almost certainly relied on CMAC. It's one of those quiet primitives that shows up everywhere once you start looking.

The problem it solves. Before CMAC, the standard block-cipher MAC was CBC-MAC. CBC-MAC is elegant — encrypt the message in CBC mode, throw away everything but the last block — but it has a nasty catch: it is only secure for fixed-length messages. If an attacker sees MACs for messages M1 and M2, they can forge a MAC for a longer concatenated message. Various patches existed (EMAC, XCBC, TMAC, OMAC), each fixing part of the problem at the cost of extra keys or extra block cipher calls. NIST standardized OMAC1 as CMAC in SP 800-38B in 2005, and RFC 4493 is the IETF's version pinned to AES-128.

The clever trick. CMAC uses a single AES key. From that key it derives two subkeys, K1 and K2, by encrypting an all-zero block and then doing a left shift with conditional XOR against the constant 0x87 — this is multiplication by x in the finite field GF(2^128). To MAC a message:

• Split the message into 16-byte blocks.
• CBC-encrypt them normally, except XOR the final block with K1 if the message length is an exact multiple of 16, or with K2 after 10... padding otherwise.
• The last ciphertext block is the tag.

That one XOR distinguishes between "message ended cleanly" and "message was padded," which kills the length-extension attack that broke plain CBC-MAC. No extra keys to distribute, no extra block-cipher call per message, provably secure for arbitrary-length inputs.

Design decisions worth noticing. The authors chose to leave truncation to the caller — the tag is always 128 bits, but protocols routinely use 64 or 96 bits. They also specified byte-level behavior meticulously, with test vectors, because subtle bugs in the subkey derivation (especially the 0x87 reduction polynomial and the shift-vs-XOR ordering) had bitten earlier implementations. Reading the RFC feels less like a spec and more like a defensive walkthrough for implementers.

Why it still matters in 2026. AEAD modes like GCM and ChaCha20-Poly1305 have absorbed most new authenticated-encryption work, but CMAC remains the workhorse whenever you need a MAC and already have an AES engine — which describes essentially every embedded chip, HSM, and smartcard shipped in the last fifteen years. It is the PRF inside IKEv2's PRF_AES128_CMAC, the integrity check inside MACsec, and the building block of SIV mode used for key wrapping and deterministic encryption. When constrained devices (RFC 7228 territory) need authentication, CMAC is often the answer because it reuses silicon they already have.

A quirky footnote. The 0x87 constant is the low-weight irreducible polynomial x^128 + x^7 + x^2 + x + 1. The same polynomial powers GHASH inside AES-GCM. Two of the most-deployed MACs on Earth share their algebraic backbone with a five-byte constant most engineers have never noticed.