Fact-checked by Grok 2 weeks ago

CBC-MAC

CBC-MAC, or Cipher Block Chaining , is a mode of operation for s that generates a fixed-length (MAC) to verify the integrity and authenticity of a message by processing it in chained blocks. It applies the block cipher iteratively to each message block, XORing the input with the previous block (starting from an all-zero ), and outputs a truncated portion of the final block as the tag. The algorithm authenticates an m-block message x = x_1 \dots x_m using a F with key k, computing y_0 = 0^[n](/page/N+), y_i = F_k(y_{i-1} \oplus x_i) for i = 1 to m, and deriving the s-bit tag from y_m (where n is the size and s \leq n). This ensures that any alteration to the propagates through the , making the tag sensitive to changes. CBC-MAC was originally designed for fixed-length messages and has been widely adopted in financial systems, such as banking protocols using the (DES). Standardized internationally in ISO/IEC 9797-1 since , with the second edition in 2011 and an amendment in 2023, CBC-MAC serves as the basis for the first mechanism in the standard, known explicitly as the CBC mode for MAC generation. It was formerly specified in the now-withdrawn ANSI X9.9 (1986) for DES-based implementations , though modern uses often pair it with stronger ciphers like . Its simplicity and efficiency—requiring only m block cipher invocations—contributed to its popularity before more advanced variants emerged. Security analyses, notably from , prove that if the underlying is a (PRP), then CBC-MAC functions as a strongly pseudorandom (PRF) and secure MAC against existential under chosen-message attacks, with an advantage bound of approximately q^2 m^2 / 2^{n-1} for q queries (birthday-bound security). However, CBC-MAC is insecure for variable-length messages without proper padding, as attackers can exploit length-extension collisions to forge tags—e.g., two messages of lengths differing by a can yield the same tag if crafted adversarially. To address this, NIST recommends variants like CMAC (in SP 800-38B), which modifies CBC-MAC with subkeys for arbitrary lengths while maintaining efficiency. CBC-MAC also forms the authentication component in combined modes like CCM (Counter with CBC-MAC) for .

Overview

Definition and Purpose

A message authentication code (MAC) is a symmetric-key cryptographic primitive that takes a variable-length message and a secret key as inputs to produce a fixed-length output tag, which is typically much shorter than the message itself and used to verify both the integrity and authenticity of the transmitted data. Unlike unkeyed cryptographic hash functions, which provide only collision resistance for data integrity without authentication, a MAC requires the shared secret key for both tag generation and verification, ensuring that only parties possessing the key can generate valid tags or confirm the message's origin. The CBC-MAC, or Cipher Block Chaining Message Authentication Code, is a specific type of constructed from a symmetric , operating as a deterministic that processes the message under a secret key to yield a fixed-length authentication tag equal in size to the block cipher's output. Its primary purpose is to provide efficient message authentication in symmetric cryptography settings, leveraging existing block ciphers to assure data integrity against tampering and authenticity against forgery by unauthorized parties, without relying on separate hash functions. This makes CBC-MAC particularly suitable for resource-constrained environments. Developed in the as an efficient mechanism utilizing prevalent ciphers like , CBC-MAC was formalized in international standards to enable secure data protection in early cryptographic applications, including financial and systems. By integrating seamlessly with primitives, it offered a practical alternative to more computationally intensive methods, promoting widespread adoption for verifying message legitimacy in symmetric-key protocols.

Relation to Block Ciphers and CBC Mode

CBC-MAC is constructed using a symmetric-key , which operates on fixed-size input blocks, typically 64 or 128 bits, to provide pseudorandom permutations under a secret key. For instance, the (AES) serves as a common underlying for CBC-MAC implementations, employing 128-bit blocks regardless of the key length chosen (128, 192, or 256 bits). The must be secure against chosen-plaintext attacks to ensure the overall integrity of the mechanism, as weaknesses in the primitive could compromise the MAC's security. The core of CBC-MAC draws from the Cipher Block Chaining (CBC) mode of operation, a standard technique for processing sequential data blocks with a . In CBC mode, encryption begins with an (IV) that is XORed with the first block before ; subsequent blocks are each XORed with the immediately preceding block prior to , creating a dependency chain that diffuses changes across the output. This chaining prevents identical blocks from producing identical blocks, enhancing security over simpler modes like Electronic Codebook (ECB). Decryption reverses the process by applying the inverse and XORing with the prior or IV. In adapting CBC mode for CBC-MAC, the same secret is used for all encryptions throughout the message processing, without requiring multiple keys or . Unlike CBC , CBC-MAC initializes the with a fixed all-zero instead of a variable , and it assumes messages of exact multiples of the size with no applied. The construction discards all intermediate values, retaining only the final chained as the authentication tag, which serves to verify message rather than enable plaintext recovery. This shift in purpose—from confidentiality in CBC to in CBC-MAC—eliminates the need for an IV's unpredictability while leveraging the for diffusion properties essential to resisting forgery.

Algorithm Construction

Initialization Vector and Key Setup

The CBC-MAC algorithm requires a secret K that matches the key length supported by the underlying , such as 128 bits for AES-128. This must be randomly generated with and maintained in strict to ensure the security of the process. Unlike the CBC encryption mode, which employs a random () to achieve , CBC-MAC uses a fixed IV consisting of an all-zero string of length equal to the block size n (denoted $0^n) to produce a deterministic output for a given message and . This choice ensures that the same message always yields the same , which is essential for message . In the setup phase, the secret key K is loaded into the , and the initial chaining value H_0 is set to the $0^n. For example, when using a 64-bit like , the IV is $0^{64}.

Message Processing Steps

The input message M, assumed to be of fixed length that is a positive multiple of the 's block size n, is partitioned into m sequential blocks M_1, M_2, \dots, M_m, each consisting of n bits. The processing initializes a chaining value C_0 as the all-zero block of n bits, serving as the zero . For each block index i from 1 to m, the algorithm iteratively computes the next chaining value according to the formula C_i = E_K(M_i \oplus C_{i-1}), where E_K denotes the 's function under the secret K, and \oplus represents the bitwise exclusive-or operation. This operation applies the to the XOR of the current message block and the previous chaining value. Through this block-by-block chaining, each intermediate C_i incorporates information from all prior blocks M_1 through M_i, establishing a cumulative dependency that propagates across the entire and diffuses any alterations in early blocks to subsequent computations.

Final Tag Computation

In the CBC-MAC construction, after processing all message blocks through the chaining mechanism, the final chaining value C_m directly serves as the authentication tag T. Specifically, for an m-block divided into blocks m_1, m_2, \dots, m_m, the computation begins with an of zero, and each subsequent chaining value is derived as C_i = E_K(C_{i-1} \oplus m_i) for i = 1 to m, where E_K is the underlying under key K and C_0 = 0^n. Upon completion, T = C_m, providing a fixed-output value that encapsulates the entire authentication. The length of the tag T matches the block size of the underlying cipher, ensuring it inherits the full output length for security purposes in the basic scheme. For instance, when using as the , the tag is 128 bits long. In practical implementations, the tag may be truncated to a shorter length s \leq n bits to balance and efficiency, though the full block output is used in the core computation before any truncation. To verify the tag, the recipient independently recomputes the CBC-MAC value T' from the received message and shared key K, then checks whether T' = T; equality confirms message integrity and authenticity. Unlike certain other message authentication codes that apply a final hash function or additional encryption step to the chaining output, CBC-MAC employs no further processing beyond outputting C_m as the tag, maintaining its simplicity as a direct derivative of the block cipher chaining.

Security for Fixed-Length Messages

Provable Security Bounds

The CBC-MAC for fixed-length messages is proven to be a assuming the underlying behaves as a . This security model captures the indistinguishability of CBC-MAC outputs from a truly random , even against adaptive adversaries querying the MAC on distinct messages of the same length. The distinguishing advantage of an adversary making q queries is at most approximately \frac{q^2 m^2}{2^{n-1}}, where n denotes the block size in bits and m is the fixed number of blocks in the messages. This bound arises from the birthday paradox applied to intermediate chaining values, combined with the security of the underlying PRP, ensuring that collisions in the internal state—which could reveal structure—are unlikely until roughly $2^{n/2} / m queries. Earlier analyses provided guarantees of this form, but the refined bound from Black, Halevi, Krawczyk, Krovetz, and Rogaway (2002) tightens the constants to approximately q^2 m^2 / 2^n for practical fixed-length scenarios, emphasizing scalability for moderate query volumes. As a consequence of its PRF security, CBC-MAC resists existential under chosen-message attacks when restricted to messages of identical, known length. The advantage remains bounded by the PRF distinguishing advantage, typically negligible provided messages are distinct and the length is fixed in advance, as this prevents adversaries from exploiting length-based extensions to construct valid . This property holds under the same PRP assumption on the , with the core theorem tracing to foundational work by Rogaway (2001) and refined in subsequent analyses.

Distinguishing Attacks

Distinguishing attacks on CBC-MAC for fixed-length messages exploit the structure of to differentiate it from a truly random , revealing the limits of its . A key example is a birthday-bound attack that leverages the property of the underlying . The adversary constructs q \approx 2^{n/2} fixed-length messages, where n is the block size, that differ only in their first block while keeping the remaining blocks identical. In CBC-MAC, the chaining value after processing the first block is F_k(m_1 \oplus 0), and since F_k is a , these chaining values are distinct for distinct first blocks. The identical subsequent blocks then produce distinct inputs to the final F_k, resulting in distinct tags with probability 1—no collisions occur. In contrast, under a random , the probability of at least one tag collision among q outputs is approximately $1 - e^{-q(q-1)/2^{n+1}} \approx 0.63 for q \approx 1.18 \times 2^{n/2}. The adversary declares the CBC-MAC if no collision is observed and random otherwise, succeeding with constant advantage. This attack requires O(2^{n/2}) queries and time, demonstrating that CBC-MAC's security as a fixed-input-length pseudorandom (FIL-PRF) is bounded by the birthday paradox, with distinguishing advantage \Theta(q^2 m^2 / 2^n). The bound is tight, as matching upper bounds are proven under the assumption that the block cipher is a secure PRF or PRP. While CBC-MAC achieves provable PRF security for fixed-length messages up to this birthday limit, it fails as a variable-input-length PRF (VIL-PRF) without modifications, as simple relations between for messages of different lengths allow distinguishing with constant probability using just two queries. For instance, querying the all-zero single- message yields t = F_k(0); the two- message consisting of the all-zero followed by t then yields the same t, a relation unlikely under a random . This vulnerability also enables existential forgeries under chosen-message attacks when lengths vary. To mitigate these limitations, CBC-MAC should be restricted to fixed-length messages in applications requiring FIL-PRF security, or extended with length-prepending or other modifications (such as XCBC or TMAC) to achieve VIL-MAC or VIL-PRF properties while preserving security bounds close to the fixed-length case.

Handling Variable-Length Messages

Length Prepending Method

The length prepending method addresses the insecurity of basic CBC-MAC for variable-length messages by incorporating an explicit encoding of the message length as the initial block in the input to the algorithm. This ensures that messages of different lengths are processed with distinct starting inputs, thereby preventing forgery attacks that exploit prefix relationships between messages. The approach transforms the input such that no authenticated message can serve as a prefix for another, restoring provable security under standard assumptions for a pseudorandom function family. In the processing steps, the algorithm begins with an C_0 set to the zero . The first is then formed by encoding the original L (typically in bits) as a fixed-width representation within a full , using big-endian byte and with leading zeros if necessary to fill the size. For instance, with a 64-bit size and a of 100 bits, the 100 is encoded as the 64-bit value $0x0000000000000064 (big-endian). The subsequent blocks consist of the original , which is padded to a multiple of the size using ISO 9797-1 method 2 (appending a single '1' bit followed by zeros). The chaining then proceeds as in fixed-length CBC-MAC: each is XORed with the previous and encrypted under the shared to produce the next , culminating in the final as the authentication tag. This method restores PRF-like security for distinct-length messages, with the adversary's advantage bounded by approximately \frac{m^2 q^2}{2^n}, where m is the maximum number of in any query, q is the number of queries, and n is the size in bits; this bound follows from adapting proofs of CBC-MAC unpredictability to the prepended form, assuming the underlying is a strong . By including the length upfront, it specifically thwarts length-extension attacks, where an adversary might otherwise append data to a known message-tag pair without altering the tag, as any extension would mismatch the prepended and invalidate . The fixed-width, big-endian encoding avoids in length interpretation across systems, ensuring consistent processing regardless of the message's bit up to the 's capacity.

Encrypt-Last-Block Method

The encrypt-last-block method provides an extension to for handling variable-length messages by following the standard processing for all blocks and then encrypting the final chained output using a second . The message is divided into blocks, with the first block XORed with an (typically zero), and each subsequent block XORed with the previous before under the key K_1. The final chained value is then encrypted using a second key K_2. In standards such as ISO/IEC 9797-1 (MAC Algorithm 3), a specific variant employs this approach with , where the CBC chaining uses single DES with the first subkey for intermediate blocks, but the final block input (XORed with the previous ciphertext) undergoes a full encryption using both subkeys. This method offers weaker security compared to length-prepending techniques, as it remains vulnerable to attacks when two messages of different lengths produce the same intermediate CBC state before the last block, allowing length collisions to enable existential forgeries with probability approaching 1 after $2^{n/2} queries, where n is the block size. Despite these limitations, the encrypt-last-block approach is more efficient for streaming applications, requiring only one additional block cipher invocation beyond the message length in blocks and enabling online processing without upfront knowledge of the full message length. It forms the basis for the (Encrypt-and-MAC) construction, which uses two independent keys to compute the chain under K_1 and then encrypts the resulting under K_2, supporting variable-length messages padded to full blocks. Contemporary analyses critique the method as less suitable for general-purpose use due to its reliance on careful key derivation and padding to avoid length-extension vulnerabilities, favoring more robust variants like CMAC for broader adoption.

Attacks on Incorrect Implementations

Shared Key with Encryption

One common misuse of CBC-MAC occurs when the same cryptographic is shared between CBC mode encryption for and CBC-MAC for , particularly in an encrypt-then-MAC where the MAC is computed over the . This key reuse enables an attacker who observes a valid ciphertext and its accompanying MAC tag to perform forgeries by crafting modified ciphertexts that verify under the MAC but decrypt to attacker-chosen plaintexts. The arises because the shared allows the attacker to exploit the structural similarities in the dependencies of both modes, effectively linking the encryption process to the computation in a predictable manner. In the specific attack, suppose a message M = M_1 || M_2 || \dots || M_n is encrypted under key K using CBC mode with initialization vector IV^{(0)} to produce ciphertext blocks C_0^{(0)} || C_1^{(0)} || \dots || C_{n-1}^{(0)}, where C_0^{(0)} = IV^{(0)} and C_i^{(0)} = E_K(M_{i+1} \oplus C_{i-1}^{(0)}) for i \geq 1, with E_K denoting the block cipher encryption under K. The corresponding plaintext blocks are P_1^{(0)} || P_2^{(0)} || \dots || P_n^{(0)}, recovered via decryption as P_{i+1}^{(0)} = D_K(C_i^{(0)} \oplus C_{i-1}^{(0)}), where D_K is the decryption function. The valid MAC tag T^{(0)} is then computed as the final chaining value of CBC-MAC over the ciphertext blocks C_0^{(0)} || C_1^{(0)} || \dots || C_{n-1}^{(0)} under the same key K, starting from an all-zero IV: S_0 = 0, S_i = E_K(C_i^{(0)} \oplus S_{i-1}), and T^{(0)} = S_{n-1}. An attacker can now forge a new ciphertext by setting IV' = 0 and constructing blocks C_0' = C_0^{(0)}, C_1' = C_1^{(0)}, ..., up to a manipulation point, such as altering a later block like C_{n-2}' = C_{n-2}^{(0)} \oplus P_n^{(0)} \oplus P_n' and keeping C_{n-1}' = C_{n-1}^{(0)}, where P_n' is the attacker's chosen plaintext block. Due to the shared key, the CBC-MAC computation over this forged ciphertext C' yields the same tag T^{(0)}, as the chaining values align predictably with the original encryption dependencies up to the manipulation. Upon decryption of C', the initial blocks recover the original structure, but the altered block produces the desired P_n', enabling an existential forgery where the attacker controls part of the decrypted message while the MAC verifies successfully. This attack succeeds with probability 1 after observing just one valid (ciphertext, tag) pair. To illustrate with as the underlying (a 64-bit historically used in both modes), consider a simplified two-block M = M_1 || M_2 encrypted under a shared 56-bit key K with IV^{(0)} = 0. The ciphertext is C_1 = DES_K(M_1), C_2 = DES_K(M_2 \oplus C_1), and the MAC tag T = DES_K(C_2 \oplus DES_K(C_1)). An attacker observes C_1 || C_2 || T and forges a new two-block ciphertext C_1' = C_1, C_2' = C_2 \oplus \Delta, where \Delta is chosen such that decryption yields a modified M_2' = M_2 \oplus \Delta. The MAC over C_1' || C_2' computes S_1' = DES_K(C_1), T' = DES_K(C_2' \oplus S_1') = DES_K((C_2 \oplus \Delta) \oplus DES_K(C_1)). By selecting \Delta to compensate for the chaining (leveraging the known structure), T' = T, allowing verification while altering the decrypted output. This demonstrates how 's small block size exacerbates predictability in the attack, though the issue is structural and applies to any secure under key reuse. The primary mitigation is to use distinct keys for CBC encryption and CBC-MAC: generate a separate authentication key K_{MAC} independent of the encryption key K_{enc}, or derive K_{MAC} from K_{enc} using an approved (e.g., ) to ensure cryptographic separation. NIST guidelines explicitly recommend that a single key be used for only one cryptographic function, such as or integrity protection via , to prevent such cross-mode vulnerabilities and limit the impact of key compromise. Authenticated modes like GCM or CCM, which integrate both functions under a single key in a provably secure manner, may be considered as alternatives to separate CBC-based constructions.

Variable Initialization Vector

In CBC-MAC, the standard construction mandates a fixed (IV) of all zeros to ensure for fixed-length messages. However, a common misuse arises when implementers treat CBC-MAC analogously to CBC-mode , incorporating a variable or message-dependent IV in an attempt to enhance or reuse components from protocols. This , observed in some early implementations that assumed IV practices from could be directly applied, compromises the scheme's core properties. The vulnerability stems from the CBC-MAC's first processing step, where the is XORed with the initial before . If the is variable and controllable by an attacker—often because it must be transmitted alongside the and for —the attacker can exploit this to achieve tag malleability. Specifically, upon obtaining a valid tag T for a M under , the attacker can forge a new tag T' = T \oplus [\delta](/page/Delta) for a modified M' (with its first altered by \delta) by simply setting a new IV' = \oplus [\delta](/page/Delta). This directly alters the effective first input to the without invalidating the tag, as the subsequent computations remain consistent. As a result, unforgeability is completely broken: a single valid (M, T, IV) triple suffices for the attacker to generate arbitrarily many forgeries for related messages, undermining the MAC's ability to detect tampering. To mitigate this, implementations must strictly enforce the fixed zero as per the original design. For scenarios requiring a or variable input to prevent replay attacks, nonce-based MACs such as GMAC—defined in NIST SP 800-38D and used in modes like GCM—should be adopted instead.

Predictable Initialization Vector

In CBC-MAC, the standard construction requires a fixed all-zero to ensure provable security as a pseudorandom for messages of fixed length. Deviations from this, such as employing a constant non-zero , can introduce vulnerabilities in certain implementations, particularly if the is transmitted alongside the message and tag for verification. For example, the nCipher nCore API prior to version 2.18 transmitted the when a non-zero value was used, enabling remote attackers to modify messages while bypassing integrity checks by exploiting the exposed . A related issue arises when implementations use a counter or other predictable value, such as a , as the IV to provide uniqueness across messages. This predictability allows an attacker to anticipate the IV for a target message and perform offline computations. Specifically, upon observing a valid (IV1, M1, ) where M1 consists of full s, the attacker can predict IV2, compute the adjusted message M2 such that each of M2 is XORed with the corresponding of (IV1 XOR IV2 padded appropriately), and submit the forged (IV2, M2, ); the will succeed because the initial value IV2 XOR first of M2 equals IV1 XOR first of M1, yielding identical subsequent and the same . Such attacks facilitate preimage recovery for valid message-tag pairs through simple XOR operations once the IV is known or predicted, effectively reducing the scheme's resistance to offline computation and chosen-IV forgery. The security degrades from the provable bound of roughly $2^{b/2} (where b is the block size) against distinguishing attacks in the standard fixed-zero IV construction to trivial forgery probability 1, severely compromising message authenticity. To mitigate these risks, CBC-MAC implementations must strictly use the all-zero as specified in standards like FIPS 113. For applications needing nonces or counters to handle variable inputs or replay protection, modes such as GCM are recommended, as they integrate nonce-based and without relying on modifiable IVs in the MAC computation.

Standards and Applications

Defining Standards

The Cipher Block Chaining (CBC-MAC) has been formally specified in several cryptographic standards, beginning with early definitions for the () and evolving to support modern block ciphers like the () while addressing security limitations for variable-length messages. One of the earliest standards is FIPS PUB 113, published by the National Institute of Standards and Technology (NIST) in 1985, which defines a Data Algorithm (DAA) based on operating in to produce a of 36 to 64 bits (in multiples of 8) for authenticating data blocks. This standard specifies the use of as the underlying with a 64-bit size and 56-bit effective , allowing variable-length messages grouped into 64-bit blocks, with the final partial padded with zeros if necessary, and mandates iterative starting from an of zero. FIPS 113 emphasizes the algorithm's role in detecting unauthorized modifications in computer data, but it was withdrawn on September 1, 2008, following the deprecation of . The (ISO) and (IEC) formalized CBC-MAC more broadly in ISO/IEC 9797-1:2011, which outlines six MAC algorithms using an n-bit and a secret key to generate an m-bit MAC, with the first mechanism directly corresponding to standard CBC-MAC. This standard supports block ciphers of various sizes (e.g., 64-bit or 128-bit blocks) and specifies three methods—basic (zero-padding), CBC (per ISO 10118-1 with '1' bit followed by zeros), and length prepending—along with optional truncation of the MAC output to reduce length while maintaining security, along with rules for key sizes matching the cipher (e.g., 128 bits for ). ISO/IEC 9797-1 also includes variants like MAC Algorithm 2 (a modified CBC-MAC with additional processing) to enhance security against certain attacks, and it requires the to be zero for deterministic operation. For AES-based implementations, NIST Special Publication 800-38B (updated in 2016) defines the CMAC mode, a refinement of CBC-MAC that securely accommodates variable-length messages through subkey generation for padding the final block, using AES-128, AES-192, or AES-256 with corresponding key sizes of 128, 192, or 256 bits. As of April 2025, NIST has decided to revise SP 800-38B to update guidance on tag lengths and other aspects. This standard specifies that the MAC tag can be truncated to any length from 32 to 128 bits, with full 128-bit tags recommended for optimal security, and mandates a zero initialization vector while providing test vectors for verification. Complementing this, RFC 4493 (2006) from the Internet Engineering Task Force (IETF) standardizes AES-CMAC for Internet protocols, aligning with NIST SP 800-38B by detailing the same subkey derivation process (using AES in CBC mode with specific constants) and emphasizing its use for authenticating binary data up to 2^61 - 1 blocks. The transition to CMAC in these standards addresses vulnerabilities in plain CBC-MAC for variable lengths by ensuring distinct tags for distinct messages, without relying on length prepending. In the context of resource-constrained devices, ISO/IEC 29192-6:2019 specifies lightweight MAC algorithms based on block ciphers, including CBC-MAC variants tailored for low-power environments, supporting ciphers with 64-bit or 80-bit blocks and key sizes as small as 80 or 128 bits. This standard outlines padding rules similar to ISO/IEC 9797-1 but optimized for minimal computational overhead, allows tag truncation to 32 bits or more, and requires secure to achieve at least 80-bit security levels, making it suitable for applications.

Common Implementations

CBC-MAC and its secure variants, such as CMAC, are implemented in prominent cryptographic software libraries to facilitate message authentication in various applications. In , a widely used open-source toolkit, CMAC is supported via the EVP_MAC-CMAC interface, which leverages underlying CBC-mode ciphers like AES-128-CBC for computation. Raw CBC-MAC can also be derived using functions such as EVP_aes_128_cbc with a fixed zero , though this requires careful handling to avoid security pitfalls. Similarly, the Bouncy Castle library for provides the CBCBlockCipherMac class, which constructs a standard from any in mode, defaulting to zero when unspecified. In hardware implementations, CBC-MAC is integrated into FPGA IP cores, particularly for AES-based modes like CCM, which employs CBC-MAC for message integrity. Vendors such as Helion Technologies offer configurable AES-CCM cores supporting ASIC and FPGA platforms, enabling efficient deployment in high-throughput environments. For resource-constrained devices like smart cards, CBC-MAC is utilized in payment standards to generate application cryptograms, ensuring secure transaction authentication during card-reader interactions. Protocol-level deployments of CBC-MAC variants appear in legacy and specialized contexts. In , the AES-XCBC-MAC-96 algorithm, a modified CBC-MAC, provides for Encapsulating Security Payload () and Authentication Header () protocols, as standardized in 3566. AES-CMAC-96 extends this for broader use in , offering enhanced security for variable-length messages per 4494. While modern protocols increasingly favor alternatives like Poly1305 for speed—such as in —CBC-MAC persists in embedded systems for its simplicity and low overhead in fixed-block scenarios. A key challenge in CBC-MAC implementations is performance overhead relative to hash-based alternatives like , stemming from sequential invocations that limit parallelism and increase latency in software. Benchmarks indicate -SHA256 achieves superior efficiency over AES-CBC-MAC, as shown in evaluations for where -SHA256 outperforms AES-CBC-MAC. To mitigate vulnerabilities in variable-length messages, best practices recommend adopting CMAC, a NIST-approved refinement of CBC-MAC that incorporates subkey tweaks for provable security.

References

  1. [1]
    Fast and Secure CBC-Type MAC Algorithms | CSRC
    Jul 21, 2009 · The CBC-MAC, or cipher block chaining message authentication code, is a well-known method to generate message authentication codes.
  2. [2]
    [PDF] The security of the cipher block chaining message authentication ...
    Sep 8, 2000 · The CBC MAC is an international standard [13]. The most popular and widely used special case uses F=DES (the data encryption standard; here k=56 ...<|control11|><|separator|>
  3. [3]
    ISO/IEC 9797-1:2011 - Message Authentication Codes (MACs)
    CHF 177.00 In stockISO/IEC 9797-1:2011 specifies six MAC algorithms that use a secret key and an n-bit block cipher to calculate an m-bit MAC.Missing: CBC- | Show results with:CBC-
  4. [4]
  5. [5]
    [PDF] Fast and Secure CBC Type MAC Algorithms
    Abstract. CBC-MAC or cipher block chaining message authentication code is a well known method to generate message authentication code.
  6. [6]
    Message Authentication Codes | CSRC
    The message authentication code (MAC) is generated from an associated message as a method for assuring the integrity of the message and the authenticity of the ...
  7. [7]
    RFC 3566 - The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
    AES-XCBC-MAC-96 is used as an authentication mechanism within the context of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) ...
  8. [8]
    ISO/IEC 9797:1989 - IEC Webstore
    Publication type, International Standard ; Publication date, 1989-11-23 ; Edition, 1.0 ; ICS. 35.030 ; Withdrawal date, 1994-04-07.<|control11|><|separator|>
  9. [9]
    [PDF] Recommendation for Block Cipher Modes of Operation
    Oct 6, 2016 · The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its ...
  10. [10]
    [PDF] NIST SP 800-38A, Recommendation for Block Cipher Modes of ...
    The CBC mode is illustrated in Figure 2. 6.3 The Cipher Feedback Mode. The Cipher Feedback (CFB) mode is a confidentiality mode that features the feedback of.
  11. [11]
  12. [12]
    [PDF] The Security of the Cipher Block Chaining Message Authentication ...
    Sep 12, 2001 · Desmedt ed., Springer-Verlag, 1994. The Security of the Cipher Block Chaining. Message Authentication Code. Mihir Bellare*. Joe Kilian†.
  13. [13]
    [PDF] Improved Security Analyses for CBC MACs - UCSD CSE
    The new bounds translate into improved guarantees on the probability of forging these MACs. Keywords: CBC MAC, message authentication, provable security. ∗Dept.
  14. [14]
    [PDF] On the Security of Cipher Block Chaining Message Authentication ...
    In this paper we show that Bernstein's proof can be used to prove security of CBC MAC against adversaries querying non-empty messages that are not prefixes of ...
  15. [15]
    [PDF] Defeating ISO9797-1 MAC Algo 3 by Combining Side-Channel and ...
    This article introduces a new attack on MAC algorithm implementing. ISO/IEC-9797-1 specification. Whereas it concerns only products imple- menting the MAC ...Missing: distinguishing | Show results with:distinguishing<|control11|><|separator|>
  16. [16]
    [PDF] CBC MACs for Arbitrary-Length Messages: The Three-Key ...
    Dec 3, 2003 · The three-key CBC MAC variants (ECBC, FCBC, XCBC) use three keys to handle arbitrary-length messages, unlike the basic CBC MAC, and avoid ...
  17. [17]
    [PDF] Revisiting Structure Graphs: Applications to CBC-MAC and EMAC
    Abstract. In Crypto'05, Bellare et al. proved an O(`q2/2n) bound for the PRF (pseudorandom function) security of the CBC-MAC based on.
  18. [18]
    Is reusing keys for CBC and CBC-MAC secure when using encrypt ...
    Feb 9, 2016 · If you can't and no one else has, then don't assume it's OK (even if you can't think of an attack). ... CBC encryption + CBC MAC reusing key in ...CBC encryption + CBC MAC reusing key in MAC-then-EncryptDoes length prepending fix the key reuse problems with CBC and ...More results from crypto.stackexchange.com
  19. [19]
    [PDF] Recommendation for Key Management: Part 1 - General
    May 5, 2020 · Key-transport keys are usually used to establish symmetric keys (e.g., key-wrapping keys, data-encryption keys, or MAC keys) and, optionally ...
  20. [20]
    [PDF] CBC-MAC 1 Overview 2 Construction of Basic CBC-MAC
    Mar 19, 2015 · We now output t1 as a valid tag for message m0 = CCC4E6. Clearly, while calculating. CBC-MAC value of m0, we get intermediate tag value, t3 for ...
  21. [21]
  22. [22]
  23. [23]
    None
    Below is a merged summary of all the provided segments regarding CBC-MAC, Initialization Vector (IV), and the Security of Random/Variable IV in CBC-MAC. To retain all information in a dense and organized manner, I will use a table in CSV format for key details, followed by a narrative summary that consolidates additional context and notes. This approach ensures comprehensive coverage while maintaining clarity and conciseness.
  24. [24]
    FIPS 113, Computer Data Authentication | CSRC
    **Summary of CBC-MAC Algorithm in FIPS 113**
  25. [25]
    SP 800-38B, Recommendation for Block Cipher Modes of Operation
    Oct 6, 2016 · This block cipher-based MAC algorithm, called CMAC, may be used to provide assurance of the authenticity and, hence, the integrity of binary data.
  26. [26]
    [PDF] FIPS PUB 113 - NIST Technical Series Publications
    May 30, 1985 · The standard specifies a cryptographic authentication algorithm for use in ADP systems and networks. The authentication algorithm makes use of ...
  27. [27]
    [PDF] INTERNATIONAL STANDARD ISO/IEC 9797-1
    Mar 1, 2011 · The first mechanism specified in this part of ISO/IEC 9797 is commonly known as CBC-MAC (CBC is an abbreviation of Cipher Block Chaining). The ...
  28. [28]
    RFC 4493 - The AES-CMAC Algorithm - IETF Datatracker
    This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named ...
  29. [29]
    ISO/IEC 29192-6:2019 - Message authentication codes (MACs)
    2–5 day deliveryThis document specifies MAC algorithms suitable for applications requiring lightweight cryptographic mechanisms.
  30. [30]
    [PDF] INTERNATIONAL STANDARD ISO/IEC 29192-6
    This clause specifies a lightweight MAC algorithm that uses a lightweight hash-function to compute a MAC. ... lightweight hash-functions specified in ISO/IEC ...
  31. [31]
    EVP_MAC-CMAC - OpenSSL Documentation
    DESCRIPTION. Support for computing CMAC MACs through the EVP_MAC API. This implementation uses EVP_CIPHER functions to get access to the underlying cipher.
  32. [32]
    Compute the CBC-MAC with AES-256 and openssl in C
    Jul 6, 2017 · The extra block is because OpenSSL adds padding to the plain text, so that it is a multiple of the block size (16 bytes for AES). In this case ...How to choose an AES encryption mode (CBC ECB CTR OCB CFB)?CBC-MAC decryption, how MAC works in encryption - Stack OverflowMore results from stackoverflow.com
  33. [33]
    CBCBlockCipherMac (Bouncy Castle Library 1.81 API Specification)
    create a standard MAC based on a block cipher with the size of the MAC been given in bits. This class uses CBC mode as the basis for the MAC generation. Note: ...
  34. [34]
    AES-CCM core - Xilinx, Altera, Microsemi, Lattice and ASIC
    AES-CCM is an authenticated encryption algorithm providing both authentication and privacy, using Counter Mode and CBC-MAC. Helion offers solutions for ASIC, ...
  35. [35]
    [PDF] Inducing Authentication Failures to Bypass Credit Card PINs - USENIX
    AC = MACS(X||AIP||ATC||IAD), where MAC is a block-cipher-based CBC-MAC using the key S. Note that the signed message in the ...
  36. [36]
    RFC 4494: The AES-CMAC-96 Algorithm and Its Use with IPsec
    This memo specifies the use of CMAC mode on the authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) ...
  37. [37]
    [PDF] Message Authentication Codes On Ultra-Low SWaP Devices
    May 11, 2022 · An alternative way to construct MACs is to use AES cipher block chaining(CBC), which we mentioned in chapter 2.3. Figure 2.20 describes the ...<|control11|><|separator|>
  38. [38]
    Comparison of the performance of Digital Signature and MAC ...
    Jun 26, 2023 · HMAC-SHA256 was the most efficient, followed by HMAC-SHA512, ECDSA, CBC-MAC-AES128, and CBC-MAC-AES256. HMAC-SHA256 was most efficient with ...