up:: Foundations MOC

Message Authentication Code (MAC)

A Message Authentication Code (MAC) is a short fixed-size tag computed from a message and a secret key that two parties share, such that anyone holding that key can confirm two things about the message: that nobody altered it in transit, and that it came from someone who holds the shared key. Because the same secret both produces the tag and checks it, a MAC delivers integrity and authenticity between parties who already trust each other, and it is fast enough to protect every packet in a session. The one guarantee it cannot give is non-repudiation, since either party holding the shared key could have produced any given tag, which is the exact line that separates a MAC from a digital signature. The everyday constructions are HMAC (built on a hash function), GMAC, and CMAC (both built on a block cipher).

The short version:

1. A MAC proves two things at once: a message is intact (integrity) and it came from a holder of the shared secret (authenticity). You compute the tag with the key, and you check it with the same key.
2. It is a symmetric primitive. Both sides hold one shared secret key, which makes it fast and small, and rules out non-repudiation, because either holder could have made the tag.
3. That shared-key model is the whole difference from a digital signature. A signature uses a private key only one party holds, so it can prove which party signed; a MAC cannot.
4. The standard constructions are HMAC (hash-based, FIPS 198-1), GMAC (block-cipher-based, NIST SP 800-38D), and CMAC (block-cipher-based, NIST SP 800-38B).
5. MACs survive the quantum transition. They are symmetric, so Grover’s algorithm only halves the brute-force strength of the key, and a longer key and a wide tag restore the full margin without changing algorithms.

Picture two people who share a jar of secret ink. Before sending a note, the sender stirs the note’s exact wording together with a drop of the ink and presses a small colored smudge at the bottom. The receiver, who owns the identical ink, stirs the received note the same way and checks that the smudge comes out the same color. If anyone changed a word along the way, the color won’t match, and a stranger who has never seen the ink can’t fake the smudge. The catch is the reason a MAC can’t prove authorship in a dispute: since both people own the same ink, the smudge tells you it was one of the two of them, and it can’t tell you which one.

What is a MAC?

A MAC is a value, often called a tag or an authenticator, computed by a keyed algorithm over a message, where the key is a secret shared between the sender and the verifier. It belongs to the family of symmetric primitives, alongside symmetric encryption like AES-256, and it is the symmetric tool for integrity and authenticity in the same way a digital signature is the public-key tool for them.

NIST defines a MAC as a cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications, and that provides assurance the message came from a party sharing the key. Those two assurances are worth separating:

1. Integrity. The tag is computed over the message content, so changing even one bit of the message makes the recomputed tag fail to match. A passing check means the message is byte-for-byte what the sender tagged.
2. Authenticity (data-origin authentication). Only a holder of the shared key can produce a tag that verifies, so a passing check also means the message came from a party inside the shared-key relationship, and not from an outsider who never had the key.

The property a MAC deliberately does not provide is non-repudiation. A digital signature can prove a specific individual produced something, because only that individual holds the private signing key. A MAC’s key is held by at least two parties, so a valid tag proves membership in that group without pinning down which member. That makes MACs the right tool between mutually trusting endpoints and the wrong tool when a verifier needs proof that holds up against the signer’s own later denial.

Source: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

How does a MAC work?

A MAC runs on a single shared secret key and a keyed algorithm, in two operations that are mirror images of each other:

1. Generation. The sender feeds the message and the shared key into the MAC algorithm, which produces a fixed-size tag. The sender transmits the message together with the tag.
2. Verification. The receiver takes the received message and the same shared key, recomputes the tag with the identical algorithm, and compares it against the tag that arrived. If the two match, the message is intact and came from a key holder. If they differ, the receiver rejects the message.

Two details decide whether a MAC is actually safe in practice:

1. The key stays secret and shared only among trusted parties. The entire guarantee rests on outsiders not knowing the key. Anyone who learns it can forge tags for arbitrary messages, so key distribution and storage carry the same weight they do for symmetric encryption.
2. Verification compares in constant time. A verifier that bails out of the comparison at the first mismatched byte leaks timing information an attacker can use to reconstruct a valid tag one byte at a time. Correct implementations compare the full tag in constant time, which is one of the most common places a MAC deployment goes wrong.

A related choice is the tag length. A MAC that outputs an n-bit tag gives a blind forger only a 1-in-2ⁿ chance of guessing a valid tag for a chosen message, so truncating a tag too far weakens forgery resistance directly. NIST gives minimum tag-length guidance for exactly this reason.

Source: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

What is a MAC used for?

MACs sit inside almost every protocol that moves data between two endpoints that already share a secret, doing the quiet work of making sure each message is intact and genuinely from the other end. The high-traffic surfaces:

1. Encrypted sessions. TLS, IPsec, and SSH authenticate every record or packet with a MAC (or with an authenticated-encryption mode that embeds one), so an attacker can’t tamper with ciphertext undetected. This is where GMAC, riding inside AES-GCM, does enormous volume.
2. API request authentication. Cloud APIs and webhooks sign each request with an HMAC over the request body and a shared API secret, so the server can confirm the request is authentic and unmodified before acting on it.
3. Session tokens and cookies. Web frameworks MAC their session cookies so a user can’t edit the contents and have the server trust the change.
4. Key derivation and protocol internals. HMAC is the engine inside HKDF, the key derivation function that TLS 1.3 uses to turn a raw shared secret into working keys, so MAC constructions appear even where the goal isn’t message authentication directly.
5. Stored-data integrity. Systems that need to detect tampering with data at rest can tag records with a MAC under a key the storage layer holds.

Because this is the integrity-and-authenticity layer between trusting parties, a broken or missing MAC shows up as undetected tampering: modified messages, forged API calls, or altered tokens that the receiver wrongly accepts as genuine.

How is a MAC different from a digital signature?

A MAC and a digital signature both prove a message is intact and authentic, and they diverge on one structural point that decides everything else: a MAC uses one secret key shared between the parties, while a signature uses a private key that only the signer holds plus a public key anyone can verify with. That single difference is what gives a signature non-repudiation and leaves a MAC without it.

The consequence runs in both directions. Because a MAC’s key is symmetric, both the sender and the verifier can generate valid tags, so a tag proves the message came from within the shared-key pair while leaving open which of the two produced it. Because a signature’s key is asymmetric, only the private-key holder can generate a valid signature, so a signature singles out the signer and holds up as evidence even against that signer’s later denial. The tradeoff is cost and reach: a MAC is fast, produces a small tag, and needs a pre-shared secret, while a signature is slower, larger, and lets any stranger verify origin without sharing anything.

Property	MAC (e.g. HMAC)	Digital signature
Key type	Symmetric, one shared secret	Asymmetric, private signs and public verifies
Who can create it	Any holder of the shared key	Only the private-key holder
Who can verify it	Only holders of the shared key	Anyone with the public key
What it proves	Integrity and authenticity between key holders	Integrity, authenticity, and identity of the signer
Non-repudiation	No, either key holder could have made it	Yes, only the signer could have made it
Typical cost	Fast, small tag	Slower, larger signature
Quantum verdict	Survives, symmetric, Grover only halves the margin	Classical schemes broken by Shor’s algorithm

The practical rule is to reach for a MAC when the two parties already share a secret and want speed and integrity on every message inside a session, and for a signature when many independent parties need to verify origin without sharing a secret, or when the proof has to stand as evidence in a dispute.

Source: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

What are the common MAC constructions?

There are two families of standardized MAC, split by what they are built on. One builds the MAC out of a hash function, and the other builds it out of a block cipher:

1. HMAC (hash-based). HMAC wraps a standard hash function like SHA-256 with the secret key in a specific nested construction, and it is the most widely deployed MAC on the internet. It is specified in FIPS 198-1, and its security follows from the properties of the underlying hash.
2. CMAC (block-cipher-based). CMAC builds a MAC from a block cipher such as AES, chaining the message through the cipher to produce the tag. It is specified in NIST SP 800-38B and is a good fit where a system already has a hardware AES engine and prefers to reuse it.
3. GMAC (block-cipher-based). GMAC is the authentication-only component of Galois/Counter Mode (GCM), specified in NIST SP 800-38D. When AES-GCM protects a TLS session it is providing encryption plus a GMAC-style tag in one pass, which is why GMAC quietly handles some of the largest MAC volume in the world.

Construction	Built on	NIST standard	Where it shows up
HMAC	Hash function (e.g. SHA-256)	FIPS 198-1	API request signing, HKDF, tokens, TLS
CMAC	Block cipher (AES)	NIST SP 800-38B	Constrained and hardware-AES environments
GMAC	Block cipher (AES), inside GCM	NIST SP 800-38D	AES-GCM authenticated encryption in TLS, IPsec

The reason there are several is coverage rather than competition. HMAC suits systems oriented around hashing, CMAC and GMAC suit systems oriented around a block cipher, and GMAC in particular exists to authenticate alongside encryption in a single efficient pass.

Sources: NIST, “The Keyed-Hash Message Authentication Code (HMAC),” FIPS 198-1, July 2008, FIPS 198-1.

NIST, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” SP 800-38B, May 2005 (updated 2016), SP 800-38B.

NIST, “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, SP 800-38D.

Does the quantum threat break MACs?

The quantum threat leaves MACs standing, and this is the reassuring half of the whole transition: a MAC is a symmetric primitive, so it faces Grover’s algorithm rather than Shor’s algorithm, and Grover is far weaker. Shor’s algorithm dissolves the number-theory problems under public-key cryptography, which is what breaks classical digital signatures outright. Grover’s algorithm only speeds up a blind brute-force search of the key, and it delivers a square-root speedup, which cuts the effective strength of a symmetric key in half rather than eliminating it.

What that means in numbers, per NIST’s post-quantum analysis:

1. The key search shrinks by half. A MAC with a 128-bit key drops to roughly 64 bits of security against a quantum attacker, and a 256-bit key drops to roughly 128 bits, which stays comfortably out of reach.
2. The fix is size, not a new algorithm. Restoring the full margin takes a longer key and a wide tag, the same answer symmetric encryption uses when it moves from AES-128 to AES-256. There is no need to invent a post-quantum MAC the way signatures and key exchange needed post-quantum replacements.
3. The hash underneath is safe too. HMAC rests on a hash function, and hashes also face only Grover-style square-root attacks, so a wide hash like SHA-256 carries HMAC through the transition with margin to spare.

NIST states this directly: symmetric-key algorithms and hash functions are expected to remain secure with adequate key and output sizes, while it is the public-key algorithms that require replacement. So the quantum migration is a public-key replacement job, and the symmetric integrity layer, MACs included, carries forward with a size adjustment at most.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NISTIR 8105.

Common misconceptions

1. “A MAC encrypts the message.” It doesn’t. A MAC proves integrity and authenticity while leaving the message fully readable. Confidentiality is a separate job handled by encryption, which is why modern protocols pair the two in authenticated-encryption modes like AES-GCM.
2. “A MAC and a digital signature are basically the same.” Both prove a message is authentic and unaltered, but a MAC uses a shared secret that both parties hold, so it can’t prove which party produced the tag. Only a digital signature, built on a private key one party holds, delivers non-repudiation.
3. “A MAC proves who sent the message in a legal sense.” It proves the message came from a holder of the shared key, and since at least two parties hold that key, a MAC can’t single out one of them. For proof that holds up against the signer’s denial, you need a signature.
4. “A quantum computer will break my MACs.” MACs are symmetric, so Grover’s algorithm only halves the key’s brute-force strength, and a longer key restores the margin. The quantum exposure in a system sits in its public-key key exchange and signatures, not in its MACs.
5. “Any hash function makes a MAC if I just prepend the key.” Naively hashing a key concatenated with a message is vulnerable to length-extension attacks on common hashes, which is exactly why HMAC uses its specific nested construction instead. Use a standard MAC, not a homemade one.
6. “A MAC and a plain checksum do the same thing.” A checksum like CRC catches accidental errors but has no secret, so an attacker can recompute it after tampering. A MAC’s secret key is what makes tampering detectable against a deliberate adversary.

Questions people ask

What is the difference between a MAC and a hash? A hash is keyless, so anyone can compute it, which means it proves a message wasn’t accidentally corrupted but not that it came from a trusted party. A MAC adds a secret key, so only a key holder can produce a valid tag, which is what turns integrity into authenticated integrity.

What is the difference between a MAC and a digital signature? A MAC uses one secret key shared by both parties, so either can create and verify tags, and it can’t prove which party made a given tag. A digital signature uses a private key only the signer holds, so it proves the specific signer’s identity and provides non-repudiation, at the cost of being slower and larger.

Is HMAC still safe to use today? Yes. HMAC with a strong hash such as SHA-256 is a NIST-approved MAC under FIPS 198-1 and remains secure, including against quantum attackers, as long as the key length is adequate. It is one of the most heavily analyzed and widely deployed constructions in cryptography.

Do I have to replace my MACs for post-quantum security? No new algorithm is required. Because MACs are symmetric, Grover’s algorithm only halves their strength, so using an adequate key size (a 256-bit key gives about 128-bit quantum security) carries them through the transition. The migration effort belongs on the public-key layer.

Which MAC should I use, HMAC, CMAC, or GMAC? HMAC is the general default and fits systems built around hashing. CMAC suits environments that already have a hardware AES engine and want to reuse it. GMAC is the natural choice when you’re already using AES-GCM, since it authenticates alongside the encryption in one pass.

Does a MAC keep my data secret? No. A MAC proves a message is intact and from a key holder, and the message stays fully readable. If you also need secrecy, you combine the MAC with encryption, which is what authenticated-encryption modes like AES-GCM do in a single operation.

How long should a MAC tag be? Long enough that blind forgery is infeasible, since an n-bit tag gives a forger only a 1-in-2ⁿ chance per guess. NIST gives minimum tag-length recommendations for exactly this reason, and truncating a tag too aggressively weakens forgery resistance directly.

Why can’t a MAC provide non-repudiation? Because the key is shared. Non-repudiation requires that only one party could possibly have produced the proof, and a shared-key MAC lets every key holder produce valid tags, so a tag can’t be pinned on one specific party. That requires the asymmetric key model of a digital signature.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, sized and sequenced against your own systems, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.