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.
Core Idea¶
A message authentication code (MAC) is a secret-key-dependent relation among a message, a short tag, and a verification decision. A holder of a secret key generates a tag over a specified message; a verifier with the corresponding key context tests whether that message and tag match. Under an appropriate construction, key and threat model, successful verification supports the claim that the covered data have not been changed and that the tag was made by someone able to use the key. It does not distinguish individual holders of a shared key.[1][2]
The structural idea is not “hash the message.” HMAC realizes the relation with a keyed cryptographic-hash construction, whereas CMAC realizes it with a block cipher. Both can instantiate the same message–key–tag–check architecture without being the same algorithm. An unkeyed digest can reveal accidental or even deliberate changes only when independently trusted; its public recomputability does not itself establish key-holder origin.[2][3][4]
Structural Signature¶
Sig role-phrases: shared secret and key context → specified message input → keyed tag generation → keyed verification decision → bounded assurance within a protocol.
- Shared secret and key context. The key selects a private mapping and defines the group of parties authorized to generate or check tags. Its secrecy and authorized distribution matter: a party that knows the generating key can make a fresh valid tag.[2][1]
- Protected message input. The tag covers the exact input chosen by the enclosing protocol, not every nearby datum. In a record or packet protocol, covered sequence fields, headers and ciphertext may matter as much as the application content. Omitted fields receive no assurance merely by proximity to a protected field.[5][6]
- Keyed tag generation. A MAC algorithm produces a bounded authentication value from key and input. HMAC's hash-based construction and CMAC's block-cipher-based construction implement this role differently; the generic role is not identical with either one.[2][3]
- Keyed verification decision. A verifier checks the received message/tag pair in the agreed key context and accepts or rejects it. Agreement on message boundaries and algorithm parameters is essential to interpreting the result.[1][5]
- Security and protocol boundary. Tag acceptance has force only under construction, key-management and tag-length assumptions. Encryption, replay rejection, identity binding beyond the key group, and public dispute resolution require additional mechanisms or assumptions; they are not hidden outputs of the MAC operation.[2][6][1]
What It Is Not¶
A MAC is not encryption: a tag can accompany readable plaintext, and its verification does not conceal that text. RFC 7366 explicitly composes a separate block-cipher encryption operation with a record MAC. Nor is every AEAD or GCM authentication tag simply a standalone MAC instance: an authenticated-encryption cipher combines operations under its own nonce and security rules. The RFC 7366 extension does not apply to AEAD cipher suites.[5]
It is not an unkeyed cryptographic hash or ordinary checksum. A publicly recomputable digest lets an adversary alter data and recompute the digest unless some separate trusted binding exists. A keyed MAC makes unauthorized production of a matching tag the security question. It is also not a digital signature: designated holders of a shared secret can both verify and ordinarily generate tags, whereas public verification with an asymmetric key is central to signatures. A MAC therefore gives no public non-repudiation on its own.[2][1]
It is not replay protection. Recording and resending the same valid message/tag pair does not create a forgery, so the primitive can accept it again. IPsec AH handles receiver sequence-number anti-replay as a distinct service from integrity-check-value verification.[6]
Scope of Application¶
The literal home is symmetric-key message protection. A message may be a stored datum, a communications record or a network packet, provided the protected bytes and key context are defined. RFC 2104 describes HMAC's hash-based keyed integrity mechanism. RFC 4493 specifies AES-CMAC as a block-cipher-based MAC. RFC 4494 places a truncated AES-CMAC tag within IPsec AH and ESP; RFC 7366 places a separate MAC around a negotiated TLS/DTLS block-cipher record.[2][3][4][5]
These settings share the keyed check but not all surrounding services. TLS record encryption and IPsec packet processing have different input selection, ordering, sequence state and trust scopes. The MAC entry covers the common primitive; protocol-specific assurances must be read from the protocol specification rather than imported into every MAC.
Clarity¶
The abstraction separates three questions that often disappear into “authenticated”: which bytes were covered, which key holders could have produced the tag, and whether this occurrence is fresh. A valid tag answers the first two only within the scheme's assumptions; it does not answer the third without protocol state. This prevents a replayed valid pair from being misdiagnosed as a cryptographic forgery, or an uncovered header change from being treated as a failure of the tag calculation.[6][5]
It also resolves the misleading phrase “keyed hash function.” HMAC is one MAC construction, but AES-CMAC uses a block cipher. Naming the common primitive at the keyed-tag/verification level makes the relationship between those constructions visible without collapsing their internals.[2][3]
Manages Complexity¶
A system with many records could compare every field to an independently secured original. A MAC reduces that integrity question to a bounded tag, an agreed input boundary, a key context and a verification decision. The reduction is useful only when key distribution and scheme assumptions are controlled; otherwise a small tag cannot carry the claimed assurance.[1][2]
Separating the primitive from its envelope also localizes design responsibility. The MAC provides the keyed check; encryption governs secrecy; a sequence-number window can govern replay; a key-distribution or identity process determines what “origin” means. RFC 7366 and RFC 4302 show those responsibilities placed in different protocol fields and stages rather than smuggled into one algorithm.[5][6]
Abstract Reasoning¶
To evaluate a proposed MAC use, write down the protected message \(m\), shared key context \(k\), tag \(t\), and acceptance test \(V_k(m,t)\). Then ask who can compute a fresh matching \(t\), which bytes are inside \(m\), and which algorithm and parameters the checker assumes. A valid result supports key-holder origin and covered-data integrity under the selected threat model; it does not identify one member if several share \(k\).[1][2]
Next test an altered and a replayed case separately. If covered bytes change but the old tag is reused, a secure verification should reject. If the entire original message/tag pair is replayed, the MAC equation has not changed; a separate sequence or freshness check must decide whether the event is acceptable. That contrast locates a missing protocol service without claiming that the MAC failed cryptographically.[6]
Finally ask how tag length and construction affect the security claim. RFC 4494's AES-CMAC-96 deliberately truncates a 128-bit result to 96 bits. This is not just formatting: output length bears on blind tag-guessing margin, while shorter tags reduce transmission overhead. The acceptable balance depends on the chosen standard and context rather than a universal number for all MACs.[4][2]
Knowledge Transfer¶
The literal transfer is from one symmetric-key protected message setting to another. TLS/DTLS records and IPsec packets use different protocol envelopes and distinct constructions can be chosen, yet both require a defined input, shared key, tag-generation rule and checking decision. This lets a reader recognize the MAC role within a larger protocol without mistaking the entire protocol for the MAC.[5][4]
Outside cryptography, a generic “evidence bound to data for checking” analogy may be useful, but the named MAC identity does not travel without secret-key cryptographic semantics. Live Authentication has a broader identity-evidence vocabulary but additionally requires freshness in its own structural signature. Whether a more portable keyed-attestation relation deserves a separate prime is a future-prime question, not a parent asserted here.
Examples¶
Negotiated TLS/DTLS encrypt-then-MAC record. In RFC 7366's block-cipher setting, a negotiated extension places a separate MAC on the encrypted record and checks it before decryption. Shared secret and key context: the direction-specific MAC write key. Protected message input: specified record metadata, sequence number and ciphertext. Keyed tag generation: the negotiated record-MAC algorithm, which can be HMAC where the selected cipher suite specifies HMAC. Keyed verification decision: reject a bad tag before decrypting. Security and protocol boundary: the cipher supplies confidentiality, while record sequence semantics come from TLS/DTLS rather than from the MAC equation itself. Mapped back: the MAC is the keyed integrity test over selected record material, not the encryption step or the entire protocol. This is a specified protocol case, not a claim that every TLS version or suite uses this mode; RFC 7366 excludes AEAD suites.[5]
IPsec AES-CMAC-96 packet authentication. RFC 4494 defines use of a block-cipher CMAC construction for IPsec AH/ESP, truncating its output to 96 bits. Shared secret and key context: the security-association key. Protected message input: the packet material selected by the IPsec authentication rules. Keyed tag generation: AES-CMAC-96, distinct internally from HMAC. Keyed verification decision: check the packet's authenticator under that association. Security and protocol boundary: AH's selectable sequence-number anti-replay service is separate from the integrity-check-value test; ESP encryption, when selected, is likewise not the MAC itself. Mapped back: the same five roles now operate on a network packet and block-cipher construction rather than a TLS encrypted record and negotiated record MAC.[4][6]
Structural Tensions¶
Shorter tags versus guessing margin. A shorter transmitted tag reduces record or packet overhead, but offers fewer candidate values against blind guessing; a longer tag consumes more bytes. RFC 4494's 96-bit truncated CMAC and RFC 2104's discussion of HMAC truncation make this a real design choice, not a claim of one universally safe length.[4][2] Diagnostic: What tag length meets the chosen protocol's forgery bound and size budget?
Shared-key local checking versus public attribution. Letting designated peers share a key makes verification local, but ordinarily lets those same peers generate a new valid tag. A dispute with an outsider cannot be settled by the tag alone as proof of which peer sent it. Moving to public-key signatures changes the primitive, key infrastructure and checking audience; it does not merely lengthen the MAC.[1] Diagnostic: Is assurance inside a key-sharing group enough, or must an independent third party attribute one originator?
Stable authenticity versus event freshness. Rechecking the same valid data is valuable for integrity, but a replayed valid pair remains cryptographically valid. Adding sequence numbers and receiver state can reject duplicates, while increasing protocol state and recovery complexity. IPsec AH explicitly separates these checks.[6] Diagnostic: Must the receiver establish only that these bytes match the key, or that this occurrence is new?
Structural–Framed Character¶
The MAC lies near the structural end within a cryptographic frame: the same message–key–tag–check relation survives unlike algorithms and protocols, yet its assurance claim requires cryptographic security assumptions. Evaluative weight: “authentication” expresses an assurance judgment, not just an observed bit pattern; without a threat model, matching bits are too weak a conclusion. Human-practice dependence: people or systems choose trust boundaries and keys, but once fixed the tag relation is algorithmic rather than dependent on an evaluator's taste. Institutional origin: standards specify HMAC, CMAC and protocol uses, but the general keyed relation is not pinned to one standard or institution. Vocabulary travel: “tag” and “verify” travel widely, whereas MAC here means symmetric-key cryptographic integrity/origin and cannot be read as an arbitrary label. Import versus recognition: the role structure can be recognized in a new cryptographic protocol without importing a particular cipher suite; its formal security claims still require domain-specific assumptions.[2][3][1]
Its character: a domain-specific structural primitive with an explicit assurance boundary, not a universal authentication template. The named entry retains secret-key generation, adversarial forgery resistance and verifier key possession as domain cargo.
Structural Core vs. Domain Accent¶
Core: a message and key determine a short tag that another key holder can test, producing an integrity/key-holder-origin decision for the specified input. Domain accent: secret-key handling, cryptographic forgery assumptions, algorithm families, tag length, and protocol input boundaries determine whether the decision has security force. Removing these leaves a generic data-and-evidence check, not a MAC.[1][2]
The portable skeleton of binding evidence to a claimed origin resembles live Authentication, but its signature requires a freshness condition that bare MAC verification lacks, so it is not an actual strict parent here. A narrower cross-domain keyed-attestation skeleton is explicitly a future-prime question. The MAC stays domain-specific because its reusable identity is a cryptographic shared-secret construction, not a general identity test.
Instantiates / Related Primes¶
Authentication is related by its origin-testing vocabulary, but the live prime requires freshness and a trust-anchor procedure; a replayed valid message/tag pair is a counterexample to strict subsumption. Hashing is not a universal genus because AES-CMAC is block-cipher based. Live Cryptographic Hash Function contributes to HMAC but not every MAC; Encryption is optional, and Digital signature substitutes asymmetric public checking rather than supplying a strict parent. These are neighbor comparisons, not asserted edges.[2][3][5]
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
- Tagged architecture — 0.87
- Proof-Carrying Code — 0.86
- Key–Value Database — 0.85
- Mass Assignment — 0.85
- Data Extraction Through Prompting — 0.84
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
HMAC is a hash-based member of the MAC family; CMAC is a block-cipher-based member. Neither name exhausts the family, and neither is an alias for the other.[2][3] An AEAD/GCM tag is related, but belongs to a combined authenticated-encryption construction with its own rules; “authentication tag” is therefore too broad as an unconditional synonym for this standalone MAC identity.[5]
“MAC” is also a collision-prone abbreviation: the live catalog has Multiply–accumulate operation with “MAC operation,” while network contexts use “MAC address” for media-access-control addressing. This draft preserves the abbreviation in prose for comprehension but does not apply it as an unqualified alias. “Message integrity code” likewise has ambiguous communications usage in the frozen Wikipedia page and remains a retrieval hold, not a proven coextensive identity.
References¶
[1] NIST Computer Security Resource Center, “Message authentication code (MAC)” glossary, definitions drawn from NIST SP 800-38B, SP 800-63-4 and related publications; especially fixed-length key-dependent authenticity/integrity value and absence of non-repudiation protection. https://csrc.nist.gov/glossary/term/message_authentication_code registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j
[2] 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 registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p
[3] JH. Song, R. Poovendran, J. Lee and T. Iwata, “The AES-CMAC Algorithm,” RFC 4493 (2006), abstract and §§1–2. https://www.rfc-editor.org/rfc/rfc4493.html registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g
[4] JH. Song, R. Poovendran and J. Lee, “The AES-CMAC-96 Algorithm and Its Use with IPsec,” RFC 4494 (2006), abstract and §§1–4. https://www.rfc-editor.org/rfc/rfc4494.html registry ↩a ↩b ↩c ↩d ↩e ↩f
[5] Peter Gutmann, “Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” RFC 7366 (2014), §§1 and 3. https://www.rfc-editor.org/rfc/rfc7366.html registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j
[6] 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 registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h