A message authentication code (MAC) proves that a message came from someone who knows a shared secret key, and that the message has not been changed in transit. Unlike a digital signature, which uses public-key cryptography and can be verified by anyone, a MAC uses a symmetric key shared between sender and receiver. The trade-off: less infrastructure, faster computation, but no public verification.
MACs are used in TLS records (alongside encryption), in network protocols (IPsec authenticates packets), in API authentication (HMAC-based signed requests), in storage systems (data integrity tags), and in countless other places where two parties already share a key.
The international standard for MACs is ISO/IEC 9797. It is a multi-part document maintained by ISO/IEC JTC 1 / SC 27. Part 1 covers MACs based on block ciphers (CBC-MAC, CMAC). Part 2 covers MACs based on dedicated hash functions (HMAC, GMAC). Part 3 covers MACs using universal hashing (UMAC, Poly1305).
This post walks through each part, explains the security properties, and shows where each MAC fits in modern protocols. Understanding ISO/IEC 9797 matters for anyone building protocols, validating cryptographic modules, or making compliance claims internationally.
What a MAC Provides
A MAC takes a message and a secret key, and produces a tag (typically 16 to 32 bytes). The recipient, who has the same key, recomputes the tag from the received message and compares. If the tags match, the message is authentic and unchanged. If they differ, something is wrong.
What MACs do NOT provide:
- Confidentiality: anyone watching the wire sees the message in clear (unless it is also encrypted)
- Non-repudiation: the sender can deny sending it, because the recipient could have forged the same MAC
- Replay protection: an attacker can replay an old message; the MAC checks out, but the recipient gets stale data
For confidentiality plus integrity, you combine a MAC with encryption. The modern preferred form is AEAD (authenticated encryption with associated data), where encryption and MAC are computed together in a single primitive (AES-GCM, ChaCha20-Poly1305).
Part 1: Block Cipher MACs
ISO/IEC 9797-1:2011 covers MACs built from block ciphers. The basic idea: chain through the message using the block cipher in a way that produces a tag depending on every byte.
Algorithms in Part 1:
- CBC-MAC: chain the message through CBC mode and use the last ciphertext block as the tag. Secure for fixed-length messages, breakable for variable lengths without modifications.
- EMAC: encrypted CBC-MAC, fixes variable-length issues.
- CMAC (also called OMAC): cipher-based MAC, the modern preferred construction. Standardized in NIST SP 800-38B.
- PMAC: parallelizable MAC, faster on multi-core.
- TMAC, XCBC, RMAC: various variants for different use cases.
CMAC is the most widely deployed today. It is simple, secure, and standardized in NIST SP 800-38B as well as ISO/IEC 9797-1. It uses AES (or another block cipher) in a way that authenticates the message with one key.
Block-cipher MACs are quantum-resistant if the block cipher is. AES-256-CMAC is considered safe against Grover's algorithm.
Part 2: Hash Function MACs
ISO/IEC 9797-2:2021 covers MACs built from cryptographic hash functions. Algorithms include:
- HMAC (Hash-based MAC): the most widely deployed MAC. Standardized in IETF RFC 2104 and FIPS 198-1.
- MDx-MAC: older MAC built directly from MD5 / SHA-1, not recommended.
- GMAC: Galois MAC, used in AES-GCM. Specified in NIST SP 800-38D.
HMAC dominates. It works with any hash function (HMAC-SHA-256, HMAC-SHA-512, HMAC-SHA-3, etc.) by combining the message with two key-derived blocks and hashing twice. The double hash defeats length-extension attacks that would break a naive hash-based construction.
HMAC-SHA-256 is the default in most modern protocols. HMAC-SHA-3 is gaining ground as SHA-3 deployment grows.
Part 3: Universal Hashing MACs
ISO/IEC 9797-3:2011 covers MACs based on universal hashing. The technique: use a fast, mathematically simple hash that is universal (any two distinct messages have a low probability of colliding under a random key) and combine with encryption to produce a secure MAC.
Algorithms in Part 3:
- UMAC: universal MAC, fast on modern CPUs.
- VMAC: 64-bit universal MAC variant.
- Poly1305: used in ChaCha20-Poly1305 AEAD. Very fast, simple to implement.
Poly1305 is the most widely deployed. It powers AEAD in TLS 1.3 (when ChaCha20 is the cipher), in WireGuard, in age, and in QNSQY. The combination ChaCha20-Poly1305 is sometimes called "ChaPoly" and is favored in environments without AES hardware acceleration.
How MACs Fit in TLS
TLS uses MACs in several places. Looking at TLS 1.3 specifically:
- Record protection: AEAD (AES-GCM or ChaCha20-Poly1305) provides confidentiality and integrity together. The MAC is built into the AEAD.
- Handshake transcript: HMAC-based key derivation (HKDF, RFC 5869) computes intermediate secrets from the handshake transcript. HMAC-SHA-256 or HMAC-SHA-384 are typical.
- Resumption tickets: TLS resumption uses HMAC to authenticate ticket integrity.
- Finished messages: Each side sends a Finished message authenticated with HMAC over the handshake transcript.
So even a simple TLS connection involves several different MAC instances behind the scenes. ISO/IEC 9797 provides the international reference for all of them.
How AEAD Replaces Standalone MACs
Modern cryptographic design favors AEAD over separate encrypt-then-MAC. Reasons:
- Single key: one key for confidentiality and integrity, simpler to manage
- No combination mistakes: encrypt-then-MAC has subtle pitfalls (do you MAC the plaintext or ciphertext? Include the IV?) that AEAD avoids
- Performance: AEAD typically processes data once, not twice
AEAD constructions standardized today:
- AES-GCM: AES with Galois/Counter Mode. Uses GMAC (Part 2 of ISO/IEC 9797). FIPS approved (SP 800-38D).
- ChaCha20-Poly1305: ChaCha20 with Poly1305. Uses Poly1305 (Part 3 of ISO/IEC 9797). RFC 8439.
- AES-CCM: AES with Counter with CBC-MAC. Uses CBC-MAC variant. Common in IEEE 802.15.4.
- XChaCha20-Poly1305: extended-nonce variant. Used in age, WireGuard.
QNSQY supports both AES-256-GCM and ChaCha20-Poly1305 for AEAD. The choice depends on platform: AES is faster on hardware with AES-NI, ChaCha20 is faster in pure software.
MAC Verification: Constant-Time Comparison
A subtle but critical implementation detail: when comparing the computed MAC tag to the received tag, the comparison must be constant-time. A naive byte-by-byte compare that returns early on the first mismatch leaks timing information about how many bytes match. An attacker can use this to forge a valid tag byte by byte.
The standard fix is constant_time_eq or subtle::ConstantTimeEq (in Rust): compare all bytes, accumulate differences, return only at the end. ISO/IEC 9797 does not specify implementation details, but conformance testing under ISO/IEC 19790 includes side-channel resistance requirements.
QNSQY uses the subtle Rust crate for all MAC and tag comparisons. Hospital and military deployments cannot afford timing leaks.
MACs in PQC Protocols
Post-quantum cryptography mostly affects key exchange and signatures. MACs are largely unaffected because their security depends on hash function or block cipher security, both of which are quantum-resistant at sufficient parameter sizes.
So in a PQC-enabled TLS handshake using ML-KEM:
- ML-KEM produces a shared secret (post-quantum)
- HKDF (built on HMAC, ISO/IEC 9797 Part 2) expands the shared secret into traffic keys
- AES-GCM or ChaCha20-Poly1305 protects records (using GMAC or Poly1305, both ISO/IEC 9797)
The MAC components stay the same. Only the key exchange changes. This is one reason PQC migration is more tractable than it could have been: the symmetric layer (block ciphers, hash functions, MACs) is already quantum-resistant.
MAC Key Sizes
ISO/IEC 9797 specifies minimum key sizes for each MAC. Practical guidance:
- CMAC over AES-256: 256-bit key, 128-bit tag
- HMAC-SHA-256: 256-bit key (more is fine), 256-bit tag (truncated to 128 or 192 in some uses)
- Poly1305: 256-bit key (combined with cipher), 128-bit tag
- GMAC in AES-GCM: 128-bit or 256-bit key matching AES, 96-bit to 128-bit tag
For long-term security, prefer 256-bit keys and full-length tags. Truncated tags (the older 64-bit MACs) are vulnerable to forgery attempts at scale.
Key Management for MACs
A MAC is only as secure as its key. ISO/IEC 11770 (key management) covers how MAC keys should be derived, distributed, stored, and rotated. See ISO/IEC 11770 key management.
Common patterns:
- Per-session keys: derive a fresh MAC key for each TLS connection from the handshake secret
- Per-message keys: in some protocols, derive a unique key for each message
- Long-term keys: pre-shared MAC keys for paired devices, rotated periodically
QNSQY's file format derives a unique MAC key for each encrypted file from the file's KEM-encapsulated secret using HKDF-SHA-256 with file-specific context labels. No two files share a MAC key.
MAC Forgery Bounds and Tag Truncation
ISO/IEC 9797 specifies the security bounds for each MAC construction. The relevant numbers tell you when truncation is safe and when it leaks security.
For a MAC with a 128-bit tag, the forgery probability per attempt is 2^-128, which is cryptographically negligible. Over the lifetime of a session a server might process billions of MAC checks, but even at 2^40 checks per second the forgery probability per second remains around 2^-88. NIST SP 800-38D requires 96-bit tags for AES-GCM as the minimum, and 128-bit tags for any high-assurance use. Tags below 64 bits are explicitly disallowed for new deployments because the birthday-bound forgery probability becomes practical.
A separate concern is the "nonce reuse" problem in AES-GCM. If two messages are encrypted with the same key and nonce, the MAC key (the GMAC subkey) is recoverable. This means an attacker can forge any subsequent message under that key. Implementations must guarantee nonce uniqueness. QNSQY uses 96-bit random nonces with a built-in counter check that fails closed if a duplicate is observed.
For ChaCha20-Poly1305, nonce reuse is similarly catastrophic but the failure mode differs: the Poly1305 key is part of the key stream, so reused nonces leak the Poly1305 key directly. XChaCha20-Poly1305 fixes this by using a 192-bit nonce, large enough that random selection produces no collisions in practice.
MACs in IPsec and SSH
ISO/IEC 9797 MACs appear throughout enterprise networking. IPsec uses HMAC-SHA-256 (or AES-GMAC in newer profiles) to authenticate every IP packet inside a tunnel. The IETF IPsec working group is currently extending IKEv2 to support PQC key exchange while keeping the same MAC layer, since the symmetric primitives remain quantum-safe.
SSH uses HMAC over SHA-256 or SHA-512 for record integrity in older modes, and ChaCha20-Poly1305 in newer modes. The OpenSSH project added Streamlined NTRU Prime as a hybrid KEX in 2022 and has been tracking ML-KEM for inclusion. Once added, the SSH transport will use ML-KEM for key exchange and the same HMAC or Poly1305 layer for record MAC, mirroring the PQC TLS migration pattern.
For QNSQY users running over SSH (e.g. SCP-ing encrypted .qs files between systems), the SSH layer's MAC adds an additional integrity check on top of QNSQY's own AEAD. This is a defense-in-depth posture that the layered protocol stack naturally provides.
FAQ
What is the difference between a MAC and a digital signature?
A MAC uses a symmetric key shared between sender and receiver. Anyone with the key can produce or verify the MAC. A digital signature uses a private key (only the signer has it) and a public key (anyone can use it to verify). Signatures provide non-repudiation; MACs do not.
Is HMAC-SHA-1 still safe?
HMAC-SHA-1 has not been broken in practice (HMAC-SHA-1 is more resistant to SHA-1 collisions than other uses of SHA-1). But SHA-1 is deprecated and HMAC-SHA-256 should be used for new deployments. NIST and ISO/IEC both deprecate SHA-1 broadly.
Does QNSQY use MACs?
Yes. QNSQY uses AEAD (AES-256-GCM and ChaCha20-Poly1305), which integrates MACs (GMAC and Poly1305 respectively). Encrypted file headers also use HMAC-SHA-256 for additional integrity over metadata. All MAC comparisons are constant-time.
What is the relationship between Part 3 of ISO/IEC 9797 and Poly1305?
Part 3 of ISO/IEC 9797 covers MACs based on universal hashing. Poly1305 is a universal hash MAC. The IETF specification of Poly1305 (RFC 8439) is more commonly cited, but ISO/IEC 9797-3 provides the international standardization framework that Poly1305 fits into.
Are MACs quantum-resistant?
Yes, MACs based on hash functions (HMAC) or block ciphers (CMAC) are quantum-resistant if the underlying primitive is. SHA-256, SHA-3, and AES-256 all retain enough security against Grover's algorithm. The PQC transition does not require replacing MACs.
How does GMAC differ from CMAC?
CMAC is built from a block cipher (typically AES) using a CBC-style chain. GMAC is built from a Galois field multiplication using the same hash subkey as AES-GCM. CMAC is typically used standalone, while GMAC is almost always paired with AES-CTR to form AES-GCM. CMAC has a 1.5x slower throughput than GMAC on modern x86 with PCLMULQDQ acceleration.
What is the recommended tag length for a long-term archival MAC?
128 bits at minimum. For data that will be kept for decades and verified across many machines, 256-bit tags using HMAC-SHA-256 or HMAC-SHA-512 are appropriate. The cost of the longer tag is negligible compared to the value of preserving integrity over a 30-year archive lifetime.
Sources
- ISO/IEC 9797-1:2011, "IT Security techniques, Message Authentication Codes (MACs), Part 1: Mechanisms using a block cipher." https://www.iso.org/standard/50375.html
- ISO/IEC 9797-2:2021, "IT Security techniques, Message Authentication Codes (MACs), Part 2: Mechanisms using a dedicated hash-function." https://www.iso.org/standard/75296.html
- ISO/IEC 9797-3:2011, "Information technology, Security techniques, Message Authentication Codes (MACs), Part 3: Mechanisms using a universal hash-function." https://www.iso.org/standard/51618.html
- NIST SP 800-38B, "Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication." https://csrc.nist.gov/pubs/sp/800/38/b/upd1/final
- IETF RFC 2104, "HMAC: Keyed-Hashing for Message Authentication." https://datatracker.ietf.org/doc/html/rfc2104
- NIST SP 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC." https://csrc.nist.gov/pubs/sp/800/38/d/final
- IETF RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols." https://datatracker.ietf.org/doc/html/rfc8439
Related Articles
- ISO/IEC PQC standards
- ISO/IEC 11770 key management
- ISO/IEC 19790 modules
- NIST FIPS guide
- Hybrid encryption
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.