Message Authentication Code (MAC).

A Message Authentication Code (MAC) is a fixed-length tag computed over a message using a symmetric secret key, such that verification requires the same key. It provides integrity and authenticity but not non-repudiation, because both parties hold the key. Common constructions include HMAC (hash-based, RFC 2104), CMAC (CBC-MAC, NIST SP 800-38B), GMAC (used in GCM), Poly1305 (paired with ChaCha20 in ChaCha20-Poly1305, RFC 8439) and KMAC (built on Keccak/SHA-3, NIST SP 800-185).

The reason HMAC exists rather than a naive MAC = H(key ‖ message) is that Merkle–Damgård hashes such as MD5, SHA-1 and SHA-256 are vulnerable to length-extension attacks: an attacker who knows a valid tag can append data and compute a valid tag for the longer message without the key. HMAC's nested H(key ⊕ opad ‖ H(key ⊕ ipad ‖ msg)) structure defeats this and has a formal security proof.

MACs must be verified in constant time — comparing tags byte-by-byte with early return leaks their length via timing, which enabled the 2009 forgery against Keyczar. They underpin TLS record authentication, IPsec AH, JWT HS256, API request signing and every AEAD mode. A MAC over ciphertext (encrypt-then-MAC) is preferred over MAC-then-encrypt, which contributed to padding-oracle attacks like Lucky Thirteen.

flowchart LR
  subgraph Sender
    M1[Message] --> T1["MAC(key, message)"]
    K1[Shared secret key] --> T1
    T1 --> S[Send message + tag]
  end
  subgraph Receiver
    S --> R["Recompute MAC(key, message)"]
    K2[Shared secret key] --> R
    R --> C{"Constant-time<br/>compare with sent tag"}
    C -->|Equal| OK[Accept: authentic & intact]
    C -->|Differ| NO[Reject: forged or altered]
  end