Skip to content

Message Authentication Code

A secret-key-dependent tag and verification test that binds a specified message to a key-holding group for integrity and origin assurance, without itself supplying secrecy or freshness.

Version
v1 · 2026-10-03 · History
Domain-specific #
13431
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Cryptography, Message Integrity → Computer Science & Software Engineering

Core Idea

A message authentication code (MAC) is a short, secret-key-dependent tag over specified message data, together with a key-holder's verification test. If the construction, key handling and input boundaries are sound, matching the tag supports integrity of the covered bytes and origin from someone able to use the key. It does not identify one holder among several who share that key.[ref-e08727d052e0][ref-90ae999daeab]

HMAC implements the relation using a keyed cryptographic hash; AES-CMAC uses a block cipher. They are distinct algorithms but instantiate the same keyed message–tag–check pattern. A MAC is therefore not simply a “keyed hash function.”[ref-90ae999daeab][ref-0a7ad92573e9]

Scope of Application

In RFC 7366's negotiated TLS/DTLS block-cipher encrypt-then-MAC mode, a record MAC covers selected record metadata and ciphertext and is checked before decryption. The cipher provides secrecy separately; the extension does not apply to AEAD suites.[^ref-2c17f33f6990] In RFC 4494, AES-CMAC-96 authenticates IPsec AH/ESP packet material; IPsec AH sequence-number anti-replay is another, separately enabled receiver service.[ref-dbd26aeb7c2b][ref-b8d145cc61d1]

Both are literal MAC instances but differ in underlying algorithm and protocol envelope. A bare replay of a valid message/tag pair can still pass its MAC check. Public non-repudiation is also not a property of a shared-key MAC, because ordinary key holders can both check and generate tags.[ref-b8d145cc61d1][ref-e08727d052e0]

Clarity

The useful distinction is between covered-data integrity, key-holder origin, freshness, and Confidentiality. A MAC supports the first two within its threat model; a replay check and encryption answer the latter questions. This avoids treating a valid but stale tag as a cryptographic break or an encrypted record as automatically authenticated.[ref-2c17f33f6990][ref-b8d145cc61d1]

Manages Complexity

The many bits of a message are reduced to a bounded keyed tag whose verification tests the selected input. Analysis then concentrates on the key group, exact covered bytes, algorithm assumptions, tag length and receiver decision rather than an unspecific claim that the whole transmission is “secure.” Protocols can combine this component with distinct secrecy or anti-replay mechanisms.[ref-e08727d052e0][ref-90ae999daeab][^ref-b8d145cc61d1]

Abstract Reasoning

For a candidate use, identify message \(m\), key context \(k\), tag \(t\), and test \(V_k(m,t)\). Ask which bytes enter \(m\) and who can make a new valid \(t\). If covered data are altered while an old tag is kept, sound verification should reject. If the original pair is merely replayed, the MAC relation still matches, so a separate freshness rule must decide whether to accept the event.[ref-90ae999daeab][ref-b8d145cc61d1]

Tag truncation is a further contextual choice. RFC 4494 uses a 96-bit truncated AES-CMAC tag for IPsec; fewer transmitted bits save space but reduce blind-guessing margin. That tradeoff cannot be judged apart from a specified construction and protocol.[^ref-dbd26aeb7c2b]

Knowledge Transfer

The same keyed tag-and-check relation is recognizable in record and packet protection, even when HMAC and CMAC use different internal machinery. It does not literally transfer to unkeyed hashing, digital signatures or every AEAD/GCM tag. Live Authentication is a related but non-parent identity because its structural signature requires freshness, which a MAC alone does not provide. A broader keyed-attestation skeleton remains a future-prime question; the staged MAC node is deliberately unparented.[ref-90ae999daeab][ref-0a7ad92573e9][^ref-2c17f33f6990]

[^ref-e08727d052e0]: NIST Computer Security Resource Center, “Message authentication code (MAC)” glossary, definitions from NIST SP 800-38B and SP 800-63-4. https://csrc.nist.gov/glossary/term/message_authentication_code [^ref-90ae999daeab]: Hugo Krawczyk, Mihir Bellare and Ran Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104 (1997), §§1–3 and §6. https://www.rfc-editor.org/rfc/rfc2104.html [^ref-0a7ad92573e9]: JH. Song, R. Poovendran, J. Lee and T. Iwata, “The AES-CMAC Algorithm,” RFC 4493 (2006). https://www.rfc-editor.org/rfc/rfc4493.html [^ref-dbd26aeb7c2b]: JH. Song, R. Poovendran and J. Lee, “The AES-CMAC-96 Algorithm and Its Use with IPsec,” RFC 4494 (2006), §§1–4. https://www.rfc-editor.org/rfc/rfc4494.html [^ref-2c17f33f6990]: Peter Gutmann, “Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” RFC 7366 (2014), §3. https://www.rfc-editor.org/rfc/rfc7366.html [^ref-b8d145cc61d1]: Stephen Kent, “IP Authentication Header,” RFC 4302 (2005), §§2.5 and 3.4.3–3.4.4. https://www.rfc-editor.org/rfc/rfc4302.html

Neighborhood in Abstraction Space

Message Authentication Code sits in a moderately populated region (60th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Network Security Vulnerabilities & Trust (26 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08