Hubbry Logo
Message authentication codeMessage authentication codeMain
Open search
Message authentication code
Community hub
Message authentication code
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Message authentication code
Message authentication code
Message authentication code
View on Wikipedia
from Wikipedia

In cryptography, a message authentication code (MAC), sometimes known as an authentication tag, is a short piece of information used for authenticating and integrity-checking a message. In other words, it is used to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.

Terminology

[edit]

The term message integrity code (MIC) is frequently substituted for the term MAC, especially in communications[1] to distinguish it from the use of the latter as Media Access Control address (MAC address). However, some authors[2] use MIC to refer to a message digest, which aims only to uniquely but opaquely identify a single message. However, it is recommended to avoid the term message integrity code (MIC), and instead use checksum, error detection code, hash, keyed hash, message authentication code, or protected checksum.[3]

Definitions

[edit]

Informally, a message authentication code system consists of three algorithms:

  • A key generation algorithm selects a key from the key space uniformly at random.
  • A MAC generation algorithm efficiently returns a tag given the key and the message.
  • A verifying algorithm efficiently verifies the authenticity of the message given the same key and the tag. That is, return accepted when the message and tag are not tampered with or forged, and otherwise return rejected.

A secure message authentication code must resist attempts by an adversary to forge tags, for arbitrary, selected, or all messages, including under conditions of known- or chosen-message. It should be computationally infeasible to compute a valid tag of the given message without knowledge of the key, even if for the worst case, we assume the adversary knows the tag of any message but the one in question.[4]

Formally, a message authentication code (MAC) system is a triple of efficient[5] algorithms (G, S, V) satisfying:

  • G (key-generator) gives the key k on input 1n, where n is the security parameter.
  • S (signing) outputs a tag t on the key k and the input string x.
  • V (verifying) outputs accepted or rejected on inputs: the key k, the string x and the tag t.

S and V must satisfy the following:

Pr [ k ← G(1n), V( k, x, S(k, x) ) = accepted ] = 1.[6]

A MAC is unforgeable if for every efficient adversary A

Pr [ k ← G(1n), (x, t) ← AS(k, · )(1n), x ∉ Query(AS(k, · ), 1n), V(k, x, t) = accepted] < negl(n),

where AS(k, · ) denotes that A has access to the oracle S(k, · ), and Query(AS(k, · ), 1n) denotes the set of the queries on S made by A, which knows n. Clearly we require that any adversary cannot directly query the string x on S, since otherwise a valid tag can be easily obtained by that adversary.[7]

Security

[edit]

While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-message attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages (which were not used to query the oracle) without performing infeasible amounts of computation.

MACs differ from digital signatures as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with symmetric encryption. For the same reason, MACs do not provide the property of non-repudiation offered by signatures specifically in the case of a network-wide shared secret key: any user who can verify a MAC is also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private key of a key pair, which is public-key cryptography.[5] Since this private key is only accessible to its holder, a digital signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer non-repudiation. However, non-repudiation can be provided by systems that securely bind key usage information to the MAC key; the same key is in the possession of two people, but one has a copy of the key that can be used for MAC generation while the other has a copy of the key in a hardware security module that only permits MAC verification. This is commonly done in the finance industry.[citation needed]

See also: Key commitment

While the primary goal of a MAC is to prevent forgery by adversaries without knowledge of the secret key, this is insufficient in certain scenarios. When an adversary is able to control the MAC key, stronger guarantees are needed, akin to collision resistance or preimage security in hash functions. For MACs, these concepts are known as commitment and context-discovery security.[8]

Implementation

[edit]

MAC algorithms can be constructed from other cryptographic primitives, like cryptographic hash functions (as in the case of HMAC) or from block cipher algorithms (OMAC, CCM, GCM, and PMAC). However many of the fastest MAC algorithms, like UMAC-VMAC and Poly1305-AES, are constructed based on universal hashing.[9]

Intrinsically keyed hash algorithms such as SipHash are also by definition MACs; they can be even faster than universal-hashing based MACs.[10]

Additionally, the MAC algorithm can deliberately combine two or more cryptographic primitives, so as to maintain protection even if one of them is later found to be vulnerable. For instance, in Transport Layer Security (TLS) versions before 1.2, the input data is split in halves that are each processed with a different hashing primitive (SHA-1 and SHA-2) then XORed together to output the MAC.

One-time MAC

[edit]

Universal hashing and in particular pairwise independent hash functions provide a secure message authentication code as long as the key is used at most once. This can be seen as the one-time pad for authentication.[11]

The simplest such pairwise independent hash function is defined by the random key, key = (a, b), and the MAC tag for a message m is computed as tag = (am + b) mod p, where p is prime.

More generally, k-independent hashing functions provide a secure message authentication code as long as the key is used less than k times for k-ways independent hashing functions.

Message authentication codes and data origin authentication have been also discussed in the framework of quantum cryptography. By contrast to other cryptographic tasks, such as key distribution, for a rather broad class of quantum MACs it has been shown that quantum resources do not offer any advantage over unconditionally secure one-time classical MACs.[12]

Standards

[edit]

Various standards exist that define MAC algorithms. These include:

  • FIPS PUB 113 Computer Data Authentication,[13] withdrawn in 2002,[14] defines an algorithm based on DES.
  • FIPS PUB 198-1 The Keyed-Hash Message Authentication Code (HMAC)[15]
  • NIST SP800-185 SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash[16]
  • ISO/IEC 9797-1 Mechanisms using a block cipher[17]
  • ISO/IEC 9797-2 Mechanisms using a dedicated hash-function[18]
  • ISO/IEC 9797-3 Mechanisms using a universal hash-function[19]
  • ISO/IEC 29192-6 Lightweight cryptography - Message authentication codes[20]

ISO/IEC 9797-1 and -2 define generic models and algorithms that can be used with any block cipher or hash function, and a variety of different parameters. These models and parameters allow more specific algorithms to be defined by nominating the parameters. For example, the FIPS PUB 113 algorithm is functionally equivalent to ISO/IEC 9797-1 MAC algorithm 1 with padding method 1 and a block cipher algorithm of DES.

An example of MAC use

[edit]

[21] In this example, the sender of a message runs it through a MAC algorithm to produce a MAC data tag. The message and the MAC tag are then sent to the receiver. The receiver in turn runs the message portion of the transmission through the same MAC algorithm using the same key, producing a second MAC data tag. The receiver then compares the first MAC tag received in the transmission to the second generated MAC tag. If they are identical, the receiver can safely assume that the message was not altered or tampered with during transmission (data integrity).

However, to allow the receiver to be able to detect replay attacks, the message itself must contain data that assures that this same message can only be sent once (e.g. time stamp, sequence number or use of a one-time MAC). Otherwise an attacker could – without even understanding its content – record this message and play it back at a later time, producing the same result as the original sender.

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Message authentication code

View on Grokipedia
from Grokipedia
A message authentication code (MAC) is a cryptographic checksum generated from a message and a secret symmetric key shared between the sender and receiver, used to verify the message's and authenticity by detecting both accidental and intentional modifications. The MAC processes an arbitrary-length message along with the key to produce a fixed-length tag, which is appended to the message and recomputed by the recipient using the same key and message; a match confirms that the message originated from the key holder and remains unaltered. Unlike digital signatures, which rely on asymmetric for , MACs use symmetric keys, making them efficient for high-speed applications but requiring secure between parties. MACs provide essential security properties, including resistance to existential forgery under chosen-message attacks, ensuring that an adversary without the key cannot produce a valid tag for a new message with non-negligible probability. Common constructions include hash-based MACs like the keyed-hash message authentication code (), which combines a (e.g., SHA-256) with the secret key in a specific manner to enhance security against length-extension attacks on plain hashes; other hash-based MACs include KMAC, based on the KECCAK family (). is specified in Federal Information Processing Standard (FIPS) 198-1 (with content proposed for incorporation into NIST SP 800-224 as of 2025) and widely used in protocols such as TLS and for authenticating data in transit. Block cipher-based MACs, such as the cipher-based MAC (CMAC), employ modes like cipher block chaining (CBC) with algorithms like AES to generate tags, offering strong security guarantees for integrity and authenticity. CMAC is specified in NIST Special Publication (SP) 800-38B and is particularly suitable for environments where block ciphers are already in use, such as in embedded systems. In practice, MACs are integral to securing communications, file checks, and , with implementations required to use approved algorithms and keys of sufficient length (e.g., at least 128 bits for modern security) to withstand brute-force and collision attacks. While early MAC concepts emerged alongside symmetric ciphers like DES in the 1970s, contemporary standards from NIST ensure their robustness against classical threats, with ongoing research addressing potential vulnerabilities in specific constructions, including quantum threats.

Fundamentals

Definition

A message authentication code (MAC) is a cryptographic primitive that provides assurance of the integrity and authenticity of a message by generating a short, fixed-length value known as a tag, computed from the and a key. This tag allows a recipient who possesses the same key to verify whether the has been altered or originated from an unauthorized party. Formally, a MAC is defined as a family of functions parameterized by a symmetric key, where each function processes an input of arbitrary length to produce an authenticator (the MAC tag) that is computationally infeasible to forge without knowledge of the key. A MAC scheme is typically specified as a tuple of three probabilistic polynomial-time algorithms: (Gen,Tag,Vrfy)(\mathsf{Gen}, \mathsf{Tag}, \mathsf{Vrfy}). The key generation algorithm Gen(1n)\mathsf{Gen}(1^n) takes a security parameter nn and outputs a secret key kk from a key space K\mathcal{K}. The tagging algorithm Tagk(m)\mathsf{Tag}_k(m) takes the key kk and a message mm from the message space M\mathcal{M} (usually {0,1}∗\{0,1\}^*) and outputs a tag tt from a tag space T\mathcal{T}. The verification algorithm Vrfyk(m,t)\mathsf{Vrfy}_k(m, t) takes the key kk, message mm, and tag tt, and outputs 1 if the tag is valid for the message under the key (accepting it as authentic), or 0 otherwise (rejecting it). For security, the scheme requires that Vrfyk(m,Tagk(m))=1\mathsf{Vrfy}_k(m, \mathsf{Tag}_k(m)) = 1 with overwhelming probability for honestly generated keys and messages. Unlike digital signatures, which rely on asymmetric key pairs to enable public verification and provide , MACs utilize symmetric keys shared exclusively between the communicating parties, making them suitable for scenarios where is secure but is unnecessary.

Terminology

In cryptographic literature, the output of a message authentication code (MAC) is commonly referred to as a "tag," a short fixed-length appended to the message to enable verification, though it is sometimes interchangeably called a "code" or "MAC value" in older texts. The term "tag" has become prevalent in modern standards and papers to emphasize its role as an authenticating appendage, distinct from the MAC scheme itself. Certain MAC constructions, especially those built on hash functions, are described as "keyed hashes," where a secret key is integrated into the hashing process to produce the tag, ensuring the output depends on both the message and the key. In MAC designs relying on , the term "universal hash" denotes a family of hash functions with provable properties under random key selection, foundational to unconditionally secure schemes. The nomenclature has evolved historically from "authentication code," as used in seminal works on in the late and early , to the more precise "message authentication code" adopted in international standards beginning with the first edition of ISO/IEC 9797 in , which formalized MAC algorithms for . This shift reflects a focus on message-specific in symmetric . The primary MAC expands to "message authentication code," denoting a symmetric-key primitive that generates a verifiable tag for a given . , standing for "hash-based message authentication code," is a widely adopted variant that applies a (such as SHA-256) in a key-dependent manner to produce the tag. In MAC definitions, the term "message" encompasses any arbitrary binary string or data block, including non-textual content like files or network packets, rather than being restricted to human-readable text. This broad scope allows MACs to protect diverse formats in practical applications.

Security Properties

Integrity and Authenticity

A message authentication code (MAC) ensures by generating a tag that depends on the entire message content and a secret key, such that any modification to the message will result in a mismatch during verification, thereby detecting alterations. This protection arises because the MAC algorithm is designed to produce a unique output for each distinct input-message pair under the same key, making unauthorized changes computationally infeasible to conceal without knowledge of the key. MACs also provide authenticity by confirming that the message originates from a party possessing the shared secret key, as only the legitimate sender can generate a valid tag that the receiver will accept upon verification. This prevents impersonation attacks, where an adversary attempts to forge a message-tag pair, since producing a correct tag without the key violates the underlying cryptographic assumptions of the MAC construction. The primary formal security property for MACs is existential unforgeability under chosen-message attack (EUF-CMA), which captures both and authenticity in an adversarial setting. In this model, an adversary is given oracle access to a MAC generation function for adaptively chosen s and succeeds by producing a valid (, tag) pair for a new not previously queried; a secure MAC ensures no efficient adversary achieves this with more than negligible probability. The adversary's resources, including running time, query count, and total message length, bound the insecurity probability, emphasizing resistance even against powerful attackers with partial information. In probabilistic MACs, randomness plays a crucial role through the use of a nonce or (IV), which is included in the input to ensure tag uniqueness and prevent replay attacks where an intercepted valid -tag pair is reused. By requiring unique nonces for each , these MACs render replays invalid, as verification fails if the nonce does not match the expected fresh value, while maintaining EUF-CMA security under the condition that nonces remain distinct.

Key Security Goals

Message authentication codes (MACs) are designed to ensure the integrity and authenticity of messages but do not provide , as the underlying message remains unencrypted and visible to any observer, with the MAC tag serving only as a verification mechanism rather than an tool. This limitation means that MACs must be combined with separate schemes, such as in modes, to protect message secrecy. A critical security goal for MACs is resistance to key recovery attacks, where an adversary observing multiple valid message-tag pairs cannot computationally feasibly extract the secret key used to generate the tags. This property is foundational to MAC models, ensuring that even under adaptive chosen-message attacks, the key remains indistinguishable from random, preventing the generation of arbitrary forgeries beyond the unforgeability bound. To address replay attacks, where an adversary resubmits a previously valid message-tag pair to deceive the verifier, MAC constructions often incorporate nonces or timestamps into the authenticated data, ensuring that each tag is unique to a specific context and cannot be reused effectively. Without such mechanisms, a deterministic MAC would accept replayed tags as valid, compromising the protocol's freshness guarantees. In the context of quantum threats, MACs based on symmetric primitives like hash functions maintain security against by doubling the effective key and tag lengths to preserve pre-quantum security levels, as quantum search reduces brute-force complexity quadratically but does not break the core assumptions. As of 2025, standards such as NIST's guidelines for recommend these adjustments for hash-based MACs like , without requiring entirely new constructions for most symmetric authentication needs. MAC designers face trade-offs in tag length, where shorter tags—while improving efficiency—reduce the security margin against brute-force forgery attempts, potentially allowing an adversary to guess a valid tag with non-negligible probability after sufficiently many trials. For instance, tags below 128 bits may expose systems to practical attacks in high-volume scenarios, necessitating longer outputs to align with desired security levels like 128-bit resistance.

Constructions

Hash-Based MACs

Hash-based message authentication codes (MACs) construct authentication tags by leveraging cryptographic hash functions as the primary primitive, typically involving a secret key to ensure security. A simple approach nests the key and message within the hash, such as MACk(m)=H(k∥m)\text{MAC}_k(m) = H(k \| m), where HH denotes the hash function, kk is the secret key, mm is the message, and ∥\| represents concatenation. However, this naive construction is vulnerable to length-extension attacks, where an adversary, given a valid tag for message mm, can compute a tag for an extended message m′=m∥pad∥extensionm' = m \| \text{pad} \| \text{extension} without knowledge of kk, exploiting the iterative structure of Merkle-Damgård hash functions like MD5 or SHA-1. To address these vulnerabilities, the construction was developed, providing a robust method for keying hash functions. is defined as HMACk(m)=H((k‾⊕opad)∥H((k‾⊕ipad)∥m)),\text{HMAC}_k(m) = H\left( (\overline{k} \oplus \text{opad}) \| H\left( (\overline{k} \oplus \text{ipad}) \| m \right) \right), where k‾\overline{k} is the key kk padded to the block size of HH, ipad=0x36\text{ipad} = 0x36 repeated across the block, and opad=0x5c\text{opad} = 0x5c repeated across the block. The inner hash computes H((k‾⊕ipad)∥m)H((\overline{k} \oplus \text{ipad}) \| m), which processes the message after key-dependent , while the outer hash applies the outer to produce the final tag. This double-nesting with XOR-based prevents length-extension attacks by ensuring that the intermediate value is not directly reusable for extensions, as the outer key modification disrupts the hash's internal state. The security of reduces to the of the underlying HH. Specifically, if HH is weakly collision-resistant, then HMAC is a secure MAC, with the proof establishing that any forgery against HMAC implies a collision in HH, under the assumption that the hash behaves as a pseudorandom function when keyed appropriately. This reduction holds for iterative hash functions, making HMAC provably secure as long as HH resists collisions, even if it is not a full ideal hash. Hash-based MACs like offer significant advantages in efficiency, particularly for messages of arbitrary length, as they avoid the block size limitations inherent in cipher-based alternatives and require only a single pass over the data after the inner hash. Their simplicity and compatibility with widely available hash functions further enhance their practicality for software implementations.

Block Cipher-Based MACs

Block cipher-based message authentication codes (MACs) adapt standard modes to produce authentication tags from a secret key and a , leveraging the underlying 's pseudorandom properties. The most straightforward construction is the cipher block chaining (CBC) MAC, designed for fixed-length messages that are exact multiples of the block size. In CBC-MAC, the m=m1∥m2∥⋯∥mtm = m_1 \parallel m_2 \parallel \cdots \parallel m_t, where each mim_i is a block, is processed sequentially: the first block is encrypted directly with the key kk, and each subsequent block is XORed with the previous before . The final block serves as the MAC tag: MACk(m)=Ct\text{MAC}_k(m) = C_t, where C1=Ek(m1)C_1 = E_k(m_1), Ci=Ek(mi⊕Ci−1)C_i = E_k(m_i \oplus C_{i-1}) for i=2,…,ti = 2, \dots, t, and EE is the . This mode initializes with a zero IV and requires no , ensuring efficiency for predefined lengths. However, CBC-MAC is insecure for variable-length messages due to length-extension attacks, where an adversary can forge tags by appending blocks without knowing the key. To address this, extensions like CMAC (also known as OMAC1) introduce subkey generation and conditional to handle arbitrary lengths securely. In CMAC, two subkeys K1K_1 and K2K_2 are derived from the master key kk by encrypting a zero block and applying left shifts with XORed constants based on carry bits, typically using a 128-bit like AES for derivation. The message is padded to the block length: if the last block is full, it is XORed with K1K_1; if partial, it is right-padded with a '1' bit and zeros, then XORed with K2K_2. The CBC chaining then proceeds as in basic , with the final block as the tag, truncated if needed. This provably achieves for messages of any length, with a bound on probability when the tag is shorter than the block size. For scenarios demanding higher throughput, such as hardware implementations with multiple processing units, parallelizable variants like PMAC offer an alternative to sequential chaining modes. PMAC partitions the message into blocks and applies the in parallel to each, using a key-derived tweak sequence (often based on a progression) to XOR with blocks before ; the results are then summed modulo 2 in the of the block size to produce the tag. This allows all but the final (padded) block to be computed concurrently, reducing latency in parallel environments while maintaining provable security. PMAC requires approximately one block-cipher invocation per message block, similar to , but its parallelism suits high-speed applications. The of these -based MACs reduces to the pseudorandom function (PRF) of the underlying , ensuring that distinguishing the MAC from a random function requires roughly 2b/22^{b/2} queries, where bb is the block size (typically 128 bits for modern ciphers like AES). Forgery attacks are thus infeasible under standard models, with the authentication tag length usually matching the block size at 128 bits to achieve full strength, though to 64 or 96 bits is sometimes used with adjusted bounds.

Specialized Variants

One-Time MACs

One-time message authentication codes (MACs) are designed to ensure message integrity and authenticity under the restriction that each key is used to authenticate at most one message, providing security guarantees that hold only for this single-use scenario. This approach contrasts with multi-use MACs by relying on information-theoretic principles rather than computational hardness assumptions, making it suitable for settings where unconditional security is desired. The foundational construction, introduced by Wegman and Carter, employs a strongly universal hash family HH to compute a tag for a mm. Specifically, given a key kk that selects a hk∈Hh_k \in H, and a random ss from the tag space TT, the tag is generated as t=hk(m)⊕s,t = h_k(m) \oplus s, where ⊕\oplus denotes bitwise XOR, and hk(m)h_k(m) maps the to an element in TT. Verification by the receiver, who shares kk and ss, recomputes hk(m)⊕sh_k(m) \oplus s and checks equality with the received tag. The strongly ensures that for any two distinct messages, the hash values are nearly uniformly random and independent, bounding the adversary's forgery probability. In theoretical applications, one-time MACs achieve , where the probability of an adversary forging a valid tag for a new message is at most ϵ+1∣T∣\epsilon + \frac{1}{|T|}, with ϵ\epsilon determined by the hash family's universality parameter and ∣T∣|T| the tag space size, without relying on unproven computational assumptions. This makes them ideal for analyzing in models with unlimited computational power, such as in quantum-resistant or protocol proofs requiring perfect . However, their single-use requirement leads to key exhaustion after one authentication per key pair, rendering them impractical for scenarios involving multiple messages without key generation overhead. Additionally, the tag length must match the hash output size, often necessitating large keys and pads that increase communication costs.

Deterministic vs. Probabilistic MACs

Message authentication codes (MACs) are classified as deterministic or probabilistic based on whether their tag generation process incorporates . In deterministic MACs, the tag generation takes a key kk and mm as and produces a fixed tag tt such that the same always yield the same output; this is the standard construction for most practical MACs, including those based on pseudorandom functions (PRFs), ensuring a unique valid tag per message under the unforgeability under chosen-message attack (UF-CMA) security definition. Such MACs are vulnerable to replay attacks, where an adversary can resend a previously authenticated (, tag) pair, as the verification will succeed without additional context like timestamps or counters. Probabilistic MACs, in contrast, include a source of randomness—such as a or nonce—during tag generation, resulting in potentially multiple valid tags for the same (key, message) pair; this requires security against unforgeability under chosen-message and verification attacks (UF-CMVA) to prevent forgeries via verification oracle queries. The randomness enhances resistance to replay attacks by ensuring each tag is unique and non-reusable, as the probability of collision is negligible. Key trade-offs between the two arise in , , and applicability. Deterministic MACs offer simplicity in and storage, producing compact tags without overhead for randomness management, making them suitable for scenarios where replay is handled externally. Probabilistic MACs, while providing built-in replay resistance, typically require larger tag sizes to accommodate the random component and may demand stronger computational assumptions (e.g., decisional Diffie-Hellman) for , though they excel in real-time protocols like two-round where uniqueness is critical. In practice, probabilistic approaches are less common due to these size and complexity costs but enable constructions from weaker assumptions compared to PRF-based deterministic MACs. A hybrid approach mitigates replay vulnerabilities in deterministic MACs by incorporating an external nonce or sequence number into the message before tagging, effectively rendering the scheme probabilistic per invocation without modifying the underlying MAC algorithm; for instance, in TLS 1.2, the computation includes an implicit 64-bit sequence number to detect replays or reorders. This method balances the efficiency of deterministic MACs with the benefits of uniqueness, commonly used in network protocols to ensure forward progress without full randomization.

Standards and Implementations

Key Standards

The National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 198-1 defines the Keyed-Hash Message Authentication Code () as a mechanism for message authentication using cryptographic hash functions, serving as an approved standard for ensuring and authenticity in U.S. federal systems. Published in July 2008 (superseding the original 2002 version), it remains current as of November 2025, though NIST proposed its withdrawal in June 2025 to relocate the content to a Special Publication (SP 800-224) without impacting validation processes. As a FIPS publication, under FIPS 198-1 is mandatory for federal agencies handling sensitive unclassified information where cryptographic authentication is required. The (ISO) and (IEC) jointly publish ISO/IEC 9797, a multi-part standard specifying mechanisms for generating message authentication codes (MACs) to verify . Part 1 (ISO/IEC 9797-1:2011) details six MAC algorithms that employ a secret key and an n-bit to produce an m-bit MAC, applicable to various architectures and processes. This part covers -based modes and was confirmed current in 2022, with an amendment in 2023. Part 2 (ISO/IEC 9797-2:2021) addresses MAC algorithms using a dedicated (or its components) with a secret key to generate an m-bit MAC, building on frameworks like ISO/IEC 10181-6 for services. Together, these parts provide international guidelines for both and hash-based MAC constructions, excluding details. The (IETF) has standardized key MAC algorithms through its (RFC) series, promoting interoperability in network protocols. RFC 2104 (February 1997) specifies , enabling message via keyed hashing with functions like or , and supports key lengths up to the hash block size while allowing truncation for efficiency. RFC 4493 (June 2006) defines AES-CMAC, an mode based on the (AES-128) using the Cipher-based MAC (CMAC) construction, which generates a 128-bit tag (optionally truncated to at least 64 bits) for data origin and integrity in and similar protocols. These RFCs underpin widespread adoption of and AES-CMAC in internet standards. MAC standards have evolved significantly with advances in , notably the deprecation of the by NIST in 2005 due to its vulnerability to brute-force attacks, which rendered single-DES insufficient for protecting federal information. This withdrawal prompted a shift toward AES-based MACs, as AES (standardized in FIPS 197 in 2001) offered superior security and performance, influencing updates in standards like ISO/IEC 9797 and IETF RFC 4493 to prioritize AES-CMAC over DES-derived modes.

Practical Algorithms

HMAC-SHA-256 is a widely adopted hash-based message authentication code constructed using the , producing a 256-bit output tag. The key can be of any length, but keys longer than the 64-byte block size of SHA-256 are first hashed to fit within that size, allowing effective key sizes up to 64 bytes. It is commonly used in protocols such as for integrity protection in VPNs, where it pairs with AES-CBC mode. HMAC-SHA-256 also serves as the authentication mechanism in TLS 1.3 cipher suites, ensuring message integrity during secure connections. In terms of , HMAC-SHA-256 achieves approximately 8 cycles per byte on modern Skylake processors for typical workloads. AES-CMAC, or CMAC based on the AES block cipher, operates on 128-bit blocks and supports key sizes of 128, 192, or 256 bits, matching AES variants. It generates a 128-bit tag, though truncation to at least 64 bits is permitted for some applications while maintaining security. Specified in NIST Special Publication 800-38B, published in May 2005, AES-CMAC provides authenticity for and is suitable for environments requiring block cipher integration. On hardware with AES-NI instructions, such as processors, AES-CMAC benefits from acceleration, achieving speeds around 3.3 cycles per byte in software implementations, with parallel variants reaching 1.65 cycles per byte. Poly1305 is a high-speed, one-time message authentication code often paired with the ChaCha stream cipher for key derivation, producing 128-bit tags from a 256-bit one-time key. Defined in RFC 8439 from June 2018, it uses a over a prime field for efficiency, making it particularly effective in software without specialized hardware. Poly1305 excels in scenarios demanding fast , such as in the AEAD construction, where it contributes to overall throughputs of about 1.33 cycles per byte on modern CPUs. Its design prioritizes low overhead for variable-length messages, outperforming traditional MACs like HMAC-SHA-1 in short-packet authentication on resource-constrained platforms.

Applications and Examples

Common Use Cases

Message authentication codes (MACs) are integral to securing network protocols, where they ensure the and of transmitted data. In TLS versions such as 1.2, the record layer employs MACs during the to protect message , incorporating a sequence number to prevent replay attacks. Similarly, the Security (IPsec) Authentication Header (AH) mode utilizes MACs to provide connectionless and data origin for IP datagrams, authenticating the entire packet excluding mutable fields. In software integrity applications, MACs facilitate secure API authentication in RESTful services by generating a keyed hash of the request payload and parameters, allowing servers to verify the sender and detect tampering without relying on public-key infrastructure. Hardware systems leverage MACs in secure boot processes to validate firmware images before execution, where a device computes a MAC over the firmware using a stored key and compares it to an embedded tag, halting boot if discrepancies indicate compromise. As of 2025, emerging applications include IoT device authentication, where lightweight MACs enable efficient mutual verification in resource-constrained networks, supporting broadcast schemes for group communications. In some research proposals for systems, such as those integrating IoT, MACs are used to authenticate message integrity in distributed ledgers, enhancing security in peer-to-peer validations.

Illustrative Example

To illustrate the use of a message authentication code (MAC), consider a scenario where Alice sends a bank transfer instruction to Bob over an insecure channel: the message m=m = "Pay 100 to Alice". share a secret symmetric key, and they employ HMAC- to authenticate the message, ensuring its integrity and origin. Although HMAC-MD5 was once common, MD5 is now considered insecure for cryptographic purposes due to vulnerabilities like collision attacks, and stronger alternatives like HMAC-SHA-256 are recommended today. The process begins with . The shared key kk is a random 128-bit (16-byte) value, such as k=0x0123456789abcdef0123456789abcdefk = 0x0123456789abcdef0123456789abcdef (generated securely using a cryptographically strong generator). To create the MAC tag, Alice computes the as follows: first, pad the key to the block size of 64 bytes with zeros if necessary; XOR the padded key with the inner constant (a block of 0x36 bytes) and append the mm; compute the hash of this inner input to get an intermediate hash value; then, XOR the key with the outer constant (a block of 0x5c bytes) and append the intermediate hash; finally, compute the hash of this outer input to produce the 128-bit (32-hex-digit) tag. This tag, say a value like 0x9294727a3638bb1c13f48ef8158bfc9d (from a standard test case illustrating the output format), is appended to the and transmitted. Upon receipt, Bob performs verification by recomputing the using the same key kk and the received mm, then comparing the resulting tag to the received one. If they exactly, Bob accepts the as authentic and unaltered. The construction relies on nested hashing with key-derived to bind the key inseparably to the . If an attacker modifies the during transmission—for instance, changing it to "Pay 200 to Alice"—Bob's recomputation will produce a different tag that does not the received one, causing verification to fail and alerting Bob to potential tampering. This property ensures that even a single-bit alteration in the results in a completely different tag with overwhelming probability.

References

  1. https://csrc.nist.gov/glossary/term/message_authentication_code_algorithm
  2. https://textbook.cs161.org/crypto/macs.html
  3. https://csrc.nist.gov/pubs/fips/198-1/final
  4. https://csrc.nist.gov/projects/message-authentication-codes
  5. https://www.federalregister.gov/documents/2025/06/23/2025-11497/proposed-withdrawal-of-federal-information-processing-standards-fips-198-1-the-keyed-hash-message
  6. https://csrc.nist.gov/pubs/sp/800/38/b/final
  7. https://csrc.nist.gov/pubs/sp/800/224/ipd
  8. https://people.seas.harvard.edu/~salil/cs127/fall13/lec16.pdf
  9. https://learn.microsoft.com/en-us/windows/uwp/security/macs-hashes-and-signatures
  10. https://crypto.ethz.ch/publications/files/AHMPR14a.pdf
  11. https://joyofcryptography.com/pdf/chap10.pdf
  12. https://link.springer.com/chapter/10.1007/3-540-46766-1_5
  13. https://www.sciencedirect.com/science/article/pii/0022000081900337
  14. https://tosc.iacr.org/index.php/ToSC/article/view/8317/7666
  15. https://cseweb.ucsd.edu/~mihir/papers/fv-mac.pdf
  16. https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf
  17. https://www.utdallas.edu/~muratk/courses/crypto06_files/mac.pdf
  18. https://www.baeldung.com/cs/replay-attacks
  19. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf
  20. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10
  21. https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/gcm-update.pdf
  22. https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-fast-mac-requirements-01
  23. https://www.ietf.org/rfc/rfc2104.txt
  24. https://cseweb.ucsd.edu/~mihir/papers/cbc.pdf
  25. https://eprint.iacr.org/2002/180
  26. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-38b.pdf
  27. https://www.cs.ucdavis.edu/~rogaway/papers/pmac.pdf
  28. https://www.fi.muni.cz/~xbouda1/teaching/2009/IV111/Wegman_Carter_1981_New_hash_functions.pdf
  29. https://eprint.iacr.org/2012/059.pdf
  30. https://www.rfc-editor.org/rfc/rfc5246.html
  31. https://blog.cryptographyengineering.com/2012/03/09/surviving-bad-rng/
  32. https://csrc.nist.gov/news/2025/proposed-withdrawal-of-fips-198-1-hmac
  33. https://www.iso.org/standard/50375.html
  34. https://www.iso.org/standard/75296.html
  35. https://datatracker.ietf.org/doc/html/rfc2104
  36. https://datatracker.ietf.org/doc/html/rfc4493
  37. https://www.nist.gov/news-events/news/2005/06/nist-withdraws-outdated-data-encryption-standard
  38. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.180-4.pdf
  39. https://www.rfc-editor.org/rfc/rfc2104.html
  40. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf
  41. https://www.rfc-editor.org/rfc/rfc9150.html
  42. https://eprint.iacr.org/2025/785.pdf
  43. https://www.rfc-editor.org/rfc/rfc4493.html
  44. https://eprint.iacr.org/2021/1283.pdf
  45. https://www.rfc-editor.org/rfc/rfc8439.html
  46. https://eprint.iacr.org/2024/1618.pdf
  47. https://www.iacr.org/archive/fse2005/35570033/35570033.pdf
  48. https://learn.microsoft.com/en-us/azure/azure-app-configuration/rest-api-authentication-hmac
  49. https://kivicore.com/en/embedded-security-blog/how-to-design-secure-socs-part3-secure-boot
  50. https://www.itu.int/epublications/fr/publication/itu-t-tr-ba-iot-2023-09-broadcast-authentication-scheme-for-internet-of-things-iot-system
  51. https://www.mdpi.com/2079-9292/9/1/74
  52. https://datatracker.ietf.org/doc/html/rfc2202
Add your contribution
Related Hubs
User Avatar
No comments yet.