Hubbry Logo
One-key MACOne-key MACMain
Open search
One-key MAC
Community hub
One-key MAC
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
One-key MAC
One-key MAC
One-key MAC
View on Wikipedia
from Wikipedia

One-key MAC (OMAC) is a family of message authentication codes constructed from a block cipher much like the CBC-MAC algorithm. It may be used to provide assurance of the authenticity and, hence, the integrity of data. Two versions are defined:

  • The original OMAC of February 2003, which is rarely used.[1] The preferred name is now "OMAC2".[2]
  • The OMAC1 refinement,[2] which became an NIST recommendation in May 2005 under the name CMAC.[3]

OMAC is free for all uses: it is not covered by any patents.[4]

History

[edit]

The core of the CMAC algorithm is a variation of CBC-MAC that Black and Rogaway proposed and analyzed under the name "XCBC"[5] and submitted to NIST.[6] The XCBC algorithm efficiently addresses the security deficiencies of CBC-MAC, but requires three keys.

Iwata and Kurosawa proposed an improvement of XCBC that requires less key material (just one key) and named the resulting algorithm One-Key CBC-MAC (OMAC) in their papers.[1] They later submitted the OMAC1 (= CMAC),[2] a refinement of OMAC, and additional security analysis.[7]

Algorithm

[edit]

To generate an ℓ-bit CMAC tag (t) of a message (m) using a b-bit block cipher (E) and a secret key (k), one first generates two b-bit sub-keys (k1 and k2) using the following algorithm (this is equivalent to multiplication by x and x2 in a finite field GF(2b)). Let ≪ denote the standard left-shift operator and ⊕ denote bit-wise exclusive or:

  1. Calculate a temporary value k0 = Ek(0).
  2. If msb(k0) = 0, then k1 = k0 ≪ 1, else k1 = (k0 ≪ 1) ⊕ C; where C is a certain constant that depends only on b. (Specifically, C is the non-leading coefficients of the lexicographically first irreducible degree-b binary polynomial with the minimal number of ones: 0x1B for 64-bit, 0x87 for 128-bit, and 0x425 for 256-bit blocks.)
  3. If msb(k1) = 0, then k2 = k1 ≪ 1, else k2 = (k1 ≪ 1) ⊕ C.
  4. Return keys (k1, k2) for the MAC generation process.

As a small example, suppose b = 4, C = 00112, and k0 = Ek(0) = 01012. Then k1 = 10102 and k2 = 0100 ⊕ 0011 = 01112.

The CMAC tag generation process is as follows:

  1. Divide message into b-bit blocks m = m1 ∥ ... ∥ mn−1 ∥ mn, where m1, ..., mn−1 are complete blocks. (The empty message is treated as one incomplete block.)
  2. If mn is a complete block then mn′ = k1 ⊕ mn else mn′ = k2 ⊕ (mn ∥ 10...02).
  3. Let c0 = 00...02.
  4. For i = 1, ..., n − 1, calculate ci = Ek(ci−1 ⊕ mi).
  5. cn = Ek(cn−1 ⊕ mn′)
  6. Output t = msbℓ(cn).

The verification process is as follows:

  1. Use the above algorithm to generate the tag.
  2. Check that the generated tag is equal to the received tag.

Variants

[edit]

CMAC-C1[8] is a variant of CMAC that provides additional commitment and context-discovery security guarantees.

Implementations

[edit]

References

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

One-key MAC

View on Grokipedia
from Grokipedia
One-key MAC (OMAC), also known as CMAC in its standardized variant, is a family of message authentication codes (MACs) derived from block ciphers, providing and authenticity for messages of arbitrary lengths using a single secret key. It builds on the cipher block chaining (CBC) mode to address limitations of the basic , which is insecure for variable-length messages unless fixed lengths are enforced. Developed by Tetsu Iwata and Kaoru Kurosawa in 2002, OMAC introduces an efficient single-key mechanism by deriving two subkeys from the primary cipher key through multiplication in the finite field GF(2^n), where one subkey handles padding for messages not aligned to block boundaries and the other for aligned cases. This construction ensures computational efficiency and security against forgery attacks, with a proven advantage bound of approximately (5m² + 1)q² / 2^n for an adversary making q queries on messages up to m blocks, where n is the block length in bits. Unlike earlier variants such as XCBC that required two or three keys, OMAC streamlines key management while maintaining provable security under the pseudorandom cipher assumption. In May 2005, the National Institute of Standards and Technology (NIST) adopted OMAC1— a specific parameter choice within the OMAC family—as the CMAC mode in Special Publication 800-38B, recommending its use with approved block ciphers like AES (for 128-bit blocks) or (for 64-bit blocks). CMAC supports variable MAC output lengths (at least 64 bits recommended) and imposes limits on message collection sizes to mitigate collision risks, such as up to 2^48 blocks for AES to bound forgery probability below 2^{-57}. Widely implemented in cryptographic libraries and protocols, including RFC 4493 for AES-CMAC, it serves as a robust alternative to hash-based MACs like in environments requiring block cipher integration.

Overview

Definition and Purpose

OMAC, or One-Key CBC MAC, is a family of message codes (MACs) constructed from a that produces a fixed-length authentication tag for verifying the and authenticity of messages. It operates on arbitrary-length messages over the domain {0,1}^* and is designed to use a single secret key of the same length as the 's , without requiring additional keys for processing variable lengths. The basic operational model involves taking a secret key and an input message as inputs, processing the message through the block cipher in a manner that accommodates its length, and outputting a tag typically of the block cipher's output size, which is then appended to the message for transmission or storage. The primary purpose of OMAC is to provide data origin authentication and protection against forgery attacks, ensuring that a message has not been altered in transit and originates from a legitimate source. By generating a tag that is computationally infeasible to forge without knowledge of the secret key, OMAC enables secure verification at the receiver's end, making it suitable for applications requiring message integrity in cryptographic protocols. This addresses limitations in earlier MAC constructions that struggled with efficiency or security for messages of varying lengths. Key characteristics of OMAC include its efficiency with block ciphers such as AES, requiring only one key scheduling operation and a number of block cipher invocations proportional to the message length (specifically, \max{1, \lceil |M|/n \rceil}, where n is the block size). It is provably secure under adaptive chosen-message attacks up to the birthday bound of approximately 2^{n/2} queries, where n is the block size, providing robust protection against existential forgery. OMAC builds upon the CBC-MAC as a foundational primitive to extend security to variable-length messages while minimizing key material requirements compared to alternatives like XCBC or TMAC. This single-key design enhances its practicality for resource-constrained environments, and it has been standardized as CMAC in RFC 4493 for use with AES.

Relation to Other MACs

OMAC, or One-Key CBC MAC, builds directly upon the CBC-MAC construction, which traditionally authenticates only fixed-length messages that are multiples of the block size using a single key, but requires additional keys or modifications for variable-length messages to maintain security. In contrast, OMAC employs a single key and derives two subkeys through a fixed transformation of the block cipher output on a zero block, enabling secure handling of arbitrary-length messages via padding and selective subkey XORing on the final block, thus extending CBC-MAC's efficiency while avoiding length-extension vulnerabilities inherent in the basic scheme. OMAC distinguishes itself from multi-key CBC-MAC variants such as XCBC and the three-key CBC-MAC by minimizing key material requirements; XCBC, for instance, uses three distinct keys (one for full blocks and two randomized keys for the final block) to achieve for arbitrary lengths, increasing storage and scheduling overhead compared to OMAC's single-key approach. Similarly, the three-key construction proposed by Petrank and Rackoff relies on separate keys for blocks and to prevent certain attacks, but OMAC achieves equivalent provable bounds—up to roughly 2n/22^{n/2} queries under the bound for an n-bit —while reducing the total key size from 3n bits to n bits. In comparison to unrelated MAC constructions, OMAC relies on block ciphers rather than hash functions, differing fundamentally from , which combines a cryptographic hash like SHA-256 with a secret key via inner and outer to provide , offering broader applicability but potentially higher computational cost in environments optimized for block ciphers. Another block-cipher-based alternative, PMAC, also uses a single key but employs a parallelizable over finite fields for message processing, avoiding explicit subkey derivation and enabling better performance in parallel hardware, though at the expense of sequential efficiency similar to in serial settings. OMAC's design offers advantages including its patent-free status, as explicitly stated by its proposers, making it freely implementable without licensing concerns, unlike some early variants that faced restrictions. It remains block-cipher efficient, requiring a single invocation per message block akin to , and is particularly suitable for hardware-accelerated block ciphers like AES, where subkey generation adds negligible overhead.

History

Early Developments in CBC-MAC Variants

The (CBC-MAC) emerged in the early 1980s as a fixed-length constructed from a operating in CBC mode, where the final block serves as the tag after each block with the previous via XOR before . This approach was formalized in standards like ANSI X9.9 (1986) for banking applications and later in NIST FIPS 113 (1985), which specified its use with the (DES) for authenticating fixed-length data blocks. A key limitation of the basic is its insecurity for variable-length , as it suffers from length-extension attacks: given a valid tag for a prefix of qnqn (where nn is the block ), an attacker can compute a valid tag for an appended block simply by continuing the chaining process, without knowledge of the secret key. To address this, implementations required either to a predetermined fixed or prepending the , which added overhead and restricted flexibility for arbitrary inputs. During the 1990s, multi-key variants of were developed to securely handle variable-length messages while minimizing complexity compared to using fully independent keys for each possible length. The ISO/IEC 9797-1 standard (first published in 1999) introduced several such constructions, including Algorithm 3 (often called or Encrypted CBC-MAC), which applies to the message and then encrypts the resulting tag with a second key to distinguish different lengths and prevent extensions. Other variants in the standard, like Algorithm 2, used two keys for the final transformation to enhance against multi-user settings. These approaches incurred higher key storage and derivation costs but enabled broader adoption in protocols needing variable input support. Refinements like ECBC (Encrypted CBC-MAC with independent final key) and FCBC (a fixed-parameter variant) built on these ideas in the late 1990s and early 2000s, optimizing the multi-key setup for efficiency while proving security bounds close to the basic CBC-MAC's birthday limit. ECBC, for instance, uses two keys—one for chaining and one for encrypting the output—to achieve provable pseudorandomness for messages up to roughly 2n/22^{n/2} blocks long. However, these still required multiple keys, prompting further innovations. In 2000, and Rogaway proposed XCBC, a three-key CBC- variant specifically designed for arbitrary- , where subkeys are derived from a master key and applied based on the the block size (e.g., one subkey for full blocks and distinct ones for partial final blocks via fixed constants). This construction prevents length-extension forgeries by ensuring unique processing of the last block, with a proof establishing it as a strong pseudorandom function under standard assumptions, at the cost of only three key derivations. XCBC's efficiency and provable made it a high-impact precursor to later single-key schemes.

Proposal and Refinement of OMAC

The OMAC (One-Key CBC MAC) was proposed by Tetsu Iwata and Kurosawa in 2002 and presented at the Fast Software Encryption (FSE) conference in 2003, introducing a single-key variant of designed to securely authenticate arbitrary-length messages. This construction derives two subkeys from a single master key to handle message padding, addressing inefficiencies in prior multi-key approaches like XCBC while preserving for variable inputs. The proposal demonstrated OMAC's resistance to existential forgery under adaptive chosen-message attacks, with a security bound of approximately σ2/2n+1\sigma^2 / 2^{n+1}, where σ\sigma is the total number of blocks processed and nn is the block size. In a 2003 addendum, Iwata and Kurosawa refined the original OMAC parameters to create OMAC1, selecting specific subkey derivation constants to optimize security without increasing or computational cost. This refinement strengthened the provable security against existential forgery in the adaptive chosen-message model, tightening bounds to σq/2n\sigma q / 2^n (where qq is the number of queries) and confirming OMAC1's equivalence to the most efficient one-key scheme possible. The update reduced reliance on idealized assumptions in prior proofs, making OMAC1 more robust for practical deployment while maintaining the single-key paradigm. NIST formalized OMAC1 as CMAC (Cipher-based MAC) in 2005 through Special 800-38B, standardizing it as a mode for message authentication with AES recommended as the underlying primitive. This adoption ensured interoperability and compliance in cryptographic protocols, positioning CMAC as a direct evolution of OMAC for and industry use. Iwata and Kurosawa affirmed OMAC's patent-free status in 2003, declaring no existing or pending patents and no intent to pursue any, which removed barriers to its broad implementation.

Algorithm

Subkey Generation

The subkey generation in One-key MAC (OMAC), also known as CMAC in its standardized form, is a preprocessing step that derives two subkeys, k1k_1 and k2k_2, from a single master key KK using the underlying EE with block length bb bits. This process enables the algorithm to authenticate messages of arbitrary lengths by handling the final block differently depending on whether it is complete or partial, without requiring a second key. The generation begins by computing an intermediate value L=EK(0b)L = E_K(0^b), where 0b0^b denotes a block of bb zero bits encrypted under the master key KK. This LL serves as the basis for the subkeys, leveraging the block cipher's output to create offsets that mimic the padding effects in traditional variants. To derive k1k_1, LL is left-shifted by one bit position within the GF(2b)\mathrm{GF}(2^b), equivalent to a by 2. If the most significant bit (MSB) of LL is 1 (indicating a carry from the shift), the result is XORed with a block-size-dependent constant RbR_b; otherwise, no XOR is applied: k1=(L≪1)⊕{Rbif MSB(L)=1,0botherwise.k_1 = (L \ll 1) \oplus \begin{cases} R_b & \text{if } \mathrm{MSB}(L) = 1, \\ 0^b & \text{otherwise}. \end{cases} The constant RbR_b is chosen as the representation of the used in GF(2b)\mathrm{GF}(2^b), specifically R64=0x1BR_{64} = 0x1B for b=64b=64 (e.g., ) and R128=0x87R_{128} = 0x87 for b=128b=128 (e.g., AES). The second subkey k2k_2 is then obtained by applying the same left-shift operation to k1k_1, again XORing with RbR_b if a carry occurs: k2=(k1≪1)⊕{Rbif MSB(k1)=1,0botherwise.k_2 = (k_1 \ll 1) \oplus \begin{cases} R_b & \text{if } \mathrm{MSB}(k_1) = 1, \\ 0^b & \text{otherwise}. \end{cases} This sequential derivation ensures that k1k_1 and k2k_2 provide the necessary adjustments for full-block and partial-block processing in the subsequent message authentication steps, maintaining efficiency with a single master key.

Message Processing and Tag Computation

In the One-key MAC (OMAC) algorithm, the input message MM of arbitrary length is first partitioned into tt blocks M1,M2,…,MtM_1, M_2, \dots, M_t, each of bb bits, where bb is the block size of the underlying EKE_K (e.g., b=128b = 128 for AES). If the length of MM is not a multiple of bb, the final block MtM_t is incomplete and requires special handling during . The computation begins with an initialization vector C0=0bC_0 = 0^b, and proceeds in a cipher block chaining (CBC) mode for the initial blocks. For i=1i = 1 to t−1t-1, each block is processed as Ci=EK(Mi⊕Ci−1)C_i = E_K(M_i \oplus C_{i-1}), where ⊕\oplus denotes bitwise XOR. This chaining ensures that the authentication tag depends on the entire message, propagating any alteration in earlier blocks to subsequent computations. For the final block MtM_t, the processing incorporates the subkeys k1k_1 and k2k_2 to handle both full and partial cases securely. If ∣Mt∣=b|M_t| = b (full block), the modified block is Mt′=Mt⊕k1M_t' = M_t \oplus k_1; otherwise, for a partial block, MtM_t is padded to bb bits using the standard padding scheme Mt′=(Mt∥1∥0b−∣Mt∣−1)⊕k2M_t' = (M_t \| 1 \| 0^{b - |M_t| - 1}) \oplus k_2, where ∥\| denotes . The final chaining step is then Ct=EK(Mt′⊕Ct−1)C_t = E_K(M_t' \oplus C_{t-1}). The authentication tag TT is derived by truncating the output of the final to the desired length ℓ≤b\ell \leq b (commonly ℓ=128\ell = 128 for full security with AES), taking the most significant ℓ\ell bits of CtC_t, i.e., T=MSBℓ(Ct)T = \text{MSB}_\ell(C_t). On the verification side, the recipient independently recomputes T′T' using the shared key KK and the received message, accepting the message as authentic T=T′T = T'; otherwise, it rejects the input. This process ensures deterministic tag generation without requiring additional .

Security

Provable Security Bounds

OMAC, also known as CMAC in its standardized form, has been proven secure as a pseudorandom function (PRF) in the , assuming the underlying is a secure PRF. This security holds for messages of arbitrary lengths, distinguishing OMAC from the basic , which requires fixed-length inputs for similar guarantees. The existential advantage under an adaptive chosen- attack is bounded by \Adv_{\mathsf{mac}}^{\OMAC}(t, q, \sigma) \leq \frac{4\sigma^2 + 1}{2^n} + \Adv_{\mathsf{prp}}_E(t', q'), where qq is the number of queries, σ\sigma is the total number of blocks across all queries, nn is the block size in bits, tt is the adversary's running time, t′=t+O(σ)t' = t + O(\sigma), q′=σ+1q' = \sigma + 1, and \Adv_{\mathsf{prp}}_E is the distinguishing advantage against the block cipher EE as a . This bound improves upon earlier analyses for related schemes like XCBC by providing tighter dependency on the total length σ\sigma rather than the maximum individual length, making it more efficient for scenarios with many short queries. For CMAC using AES-128, NIST confirms this level of , inheriting the block cipher's 128-bit margin when the total blocks remain below approximately 2482^{48}. The proof relies on hybrid arguments and game-hopping techniques, constructing intermediate games that bound the probability of collisions in the internal state while reducing security to the PRF/PRP assumption on the . Specifically, Iwata and Kurosawa's analysis for OMAC1 establishes indistinguishability from a truly random function through a sequence of hybrids that account for subkey generation and message padding, yielding the tight O(σ2/2n)\mathcal{O}(\sigma^2 / 2^n) term. A formal verification using EasyCrypt for CMAC and its variants confirms similar bounds, with the PRF advantage at most 2.5(σ+1)2+1.5q2+2q2l22n\frac{2.5(\sigma + 1)^2 + 1.5q^2 + 2q^2 l^2}{2^n}, where ll is the maximum query length in blocks, further validating the original results under computational soundness assumptions. These bounds assume a secure underlying , such as AES-128, which provides n=128n = 128 bits of security against distinguishing attacks, ensuring the overall MAC remains secure up to roughly 2642^{64} block operations before the birthday bound is approached. The analysis holds in the multi-user setting as well, with the advantage scaling linearly with the number of users under standard reductions.

Known Limitations and Attacks

One-key MAC (OMAC), standardized as CMAC, avoids the length-extension vulnerability inherent to basic by employing subkeys derived from a single master key and applying distinct constants (such as L⋅u1L \cdot u_1 and L⋅u2L \cdot u_2) to the last block based on its status, ensuring that appending data does not preserve the tag validity without knowledge of the key. However, like all MACs, CMAC requires the verifier to process the entire message to compute and check the tag, preventing partial verification and exposing it to offline attacks if messages are truncated or replayed without protocol protections. CMAC implementations are susceptible to side-channel attacks, including timing and power analysis, particularly during subkey generation via block cipher encryption of a constant input or in the iterative block encryptions for message processing, where variable execution paths or data-dependent operations can leak key information. Mitigations involve constant-time implementations that eliminate branch conditions and use uniform memory access patterns, as recommended for secure software realizations of block-cipher-based MACs. No practical cryptanalytic breaks exist for AES-CMAC, with the construction maintaining full up to the birthday bound of approximately 2642^{64} queries for 128-bit blocks under standard models. Theoretical distinguishing attacks require more than 2k/22^{k/2} queries, where kk is the key length, exceeding the provable bounds and posing no immediate threat. CMAC's relies on the underlying , rendering it non-quantum-resistant; enables key recovery in 2k/22^{k/2} time, halving the effective (e.g., 64 bits for AES-128), necessitating replacement with post-quantum block ciphers for long-term use. Additionally, key reuse across CMAC and encryption modes risks related-key attacks, so separate keys are recommended to preserve independence. In multi-user settings, CMAC's degrades as the number of users μ\mu increases, with the forgery advantage bound scaling as O(q2/2n+μq/2n)O(q^2 / 2^n + \mu q / 2^n), where qq is the total queries and nn the block size; concrete analyses show the bound remains tight but requires sooner for large μ\mu to avoid exceeding 2n/22^{n/2} total operations.

Variants

OMAC1 and CMAC Standardization

OMAC1 represents a refined variant of the original OMAC proposal, introduced in by Iwata and Kurosawa to enhance through specific subkey generation involving left shifts by one bit and XOR operations with a constant derived from the block size. This version addresses potential weaknesses in earlier parameter choices, ensuring provable bounds for arbitrary-length messages when using a as the underlying , and it functions equivalently to the later standardized CMAC in terms of computation. The CMAC was formalized by NIST in Special Publication 800-38B in 2005 as a block cipher-based , specifying the CMAC for use with approved block ciphers, such as AES with 128-bit blocks and keys of 128, 192, or 256 bits, or the (TDEA) with 64-bit blocks. The specification precisely defines the constant RbR_b for subkey derivation—equal to b(2b−1−1)/(2b−1)b(2^{b-1} - 1)/ (2^b - 1) where b=128b = 128 for AES, yielding Rb=0x87R_b = 0x87—and allows truncated tag lengths of 32, 64, or 128 bits to balance security and efficiency, with 128 bits recommended for full-strength applications. Compared to the original OMAC, CMAC incorporates minor adjustments for improved specification clarity and tighter security proofs, such as standardized handling of the last block padding and subkey selection based on the message length modulo the block size. The variant OMAC2, which uses different constants for subkey generation, was not pursued in standardization due to its comparatively weaker security bounds against certain distinguishers. In 2006, the published RFC 4493, establishing AES-CMAC as an for message authentication, complete with detailed , key derivation rules, and test vectors to ensure across implementations. AES-CMAC has seen widespread adoption as a secure primitive in protocols including for authenticating ESP and AH payloads (as specified in RFC 4494).

Recent Extensions like CMAC-C1

In recent years, researchers have proposed extensions to the CMAC algorithm to address emerging requirements, particularly in the of committing for codes (MACs). One notable advancement is CMAC-C1, introduced in 2024 as a variant that enhances CMAC with key-committing and context-discovery properties. These properties prevent adversaries from recovering the secret key from valid MAC tags and obscure the structure of authenticated messages, respectively, making CMAC-C1 suitable for applications where such protections are critical, such as in secure multi-party computations or protocols vulnerable to key extraction attacks. The technical modifications in CMAC-C1 focus on the final block processing step of the standard CMAC procedure. Specifically, it replaces the direct invocation on the last chained value with the Davies-Meyer , defined as DM[E](K,X)=EK(X)⊕X\text{DM}[E](K, X) = E_K(X) \oplus X, where EKE_K is the underlying and ⊕\oplus denotes bitwise XOR. This change introduces additional masking without significantly increasing computational overhead, preserving the efficiency of CMAC for variable-length messages. Security proofs for CMAC-C1 establish it as a pseudorandom function (PRF) under the ideal-cipher model, with key-committing advantage bounded by p2/2np^2 / 2^n and context-discovery advantage by 2p/2n2p / 2^n for up to p≤2n−1p \leq 2^{n-1} queries, where nn is the block size. These bounds demonstrate stronger notions than standard CMAC while relying on the same underlying assumptions. Beyond CMAC-C1, minor variants of OMAC and CMAC have been adapted for specific block ciphers to meet regional standards. For instance, CMAC is implemented with the SM4 , China's national standard for symmetric (GB/T 32907-2016), in various cryptographic libraries and protocols to support domestic security requirements. Earlier proposals like GCBC1 and GCBC2, presented in , aimed to improve processing speed for short messages by incorporating generalized chaining with variation operations, achieving performance gains of up to 1.5 times over OMAC for two-block messages while maintaining provable security. However, these have seen limited adoption compared to standardized CMAC implementations. Looking ahead, ongoing research explores adaptations of CMAC-like constructions for post-quantum settings, potentially integrating sponge-based primitives (e.g., as in Ascon) or lattice-hard block ciphers to resist quantum attacks like on symmetric keys. Such extensions would require re-proving security bounds under quantum-idealized models, addressing gaps in current coverage of recent threats like quantum key recovery.

Applications and Implementations

Software Libraries and Tools

The cryptographic library has supported CMAC since version 1.0.1, released in 2012, providing functions such as CMAC_Init, CMAC_Update, and CMAC_Final for computing AES-CMAC values. These APIs enable developers to generate message authentication tags using block ciphers like AES, with the implementation designed for constant-time operations to mitigate side-channel attacks such as timing vulnerabilities. In Python, the library offers CMAC functionality through its hazmat.primitives.mac.cmac module, allowing secure computation of cipher-based MACs with algorithms like AES. This high-level interface supports key derivation and tag verification, often validated against test vectors from RFC 4493 to ensure compliance with the AES-CMAC specification. Additionally, PyCryptodome provides CMAC support via its Crypto.Hash.CMAC module for similar use cases. For developers, the provides a C extension-based implementation of AES-CMAC as defined in RFC 4493, leveraging for efficient computation in resource-constrained environments. Released in , it offers a lightweight wrapper for generating and verifying MAC tags without requiring full dependency management. The Bouncy Castle library for has included CMAC support since at least version 1.37 (), via the org.bouncycastle.crypto.macs.CMac class, enabling integration with JCE providers for block cipher-based authentication. This allows for flexible use in applications needing provably secure MACs, with the supporting various block sizes and ciphers. Similarly, BouncyCastle.NET for C# provides equivalent CMAC capabilities through its APIs, facilitating .NET-based implementations of OMAC/CMAC for message integrity in enterprise software. In , the cmac crate provides a pure-Rust of CMAC (OMAC1), supporting AES and other s for constant-time, secure MAC computations, with ongoing audits as of 2025.

Standards Adoption and Practical Use

The CMAC mode, as specified in NIST Special Publication 800-38B, has been adopted as a recommended mode for , particularly when paired with the (AES), providing assurance of data authenticity and integrity in federal systems and beyond. This standard outlines CMAC's use with 128-bit s like AES-128, AES-192, and AES-256, emphasizing its suitability for protection. Complementing this, the ISO/IEC 29192 series addresses lightweight needs, with Part 6 specifying message codes (MACs) suitable for resource-constrained environments, where CMAC-like modes based on s are adapted for efficiency in IoT applications. Additionally, cryptographic modules implementing CMAC are validated under , ensuring compliance for protecting sensitive information in validated hardware and software; numerous modules, such as those in and Windows cryptographic providers, have achieved this certification while supporting AES-CMAC operations as of November 2025. In network protocols, CMAC integrates into via RFC 4494, which defines the AES-CMAC-96 algorithm for use in the Encapsulating Security Payload (ESP) and Authentication Header (AH), enabling protection with a 96-bit truncated tag for efficient packet . For security under IEEE 802.11i (WPA2/WPA3), the Counter with (CCM) mode in CCMP employs for within the AES-based encryption framework, securing data frames against tampering. (BLE) utilizes AES-CMAC for data signing and procedures, generating MACs to verify during and secure connections, as detailed in the Bluetooth Core Specification. In networks, TS 33.501 mandates AES-CMAC (as 128-NIA2) for protection of user plane and signaling, ensuring robust in high-speed, low-latency environments. Hardware implementations leverage AES accelerators to optimize CMAC performance. Intel's AES-NI instructions enable rapid execution of the underlying AES operations in CMAC, achieving up to 10x speedup over software-only implementations on compatible x86 processors. Similarly, ARMv8-A Crypto Extensions provide for AES-CMAC on mobile and embedded devices, reducing computational overhead. In IoT contexts, dedicated intellectual property (IP) cores for AES-CMAC are available in FPGAs from vendors like and , facilitating low-power, customizable deployments for secure sensor networks. Practical deployment emphasizes secure with 128- or 256-bit AES keys, as recommended in NIST SP 800-38B, to balance security and performance while mitigating risks from key compromise. CMAC offers advantages over in hardware-accelerated environments, delivering higher throughput—often 2-5x faster for AES-optimized systems—due to direct use of primitives without overhead. Amid 2020s advancements, CMAC sees expanded adoption in for integrity in non-standalone architectures and ongoing transitions toward , where AES-CMAC remains viable alongside post-quantum key encapsulation mechanisms. Real-world examples include secure boot processes in firmware, where AES-CMAC verifies integrity against tampering; VPN implementations via ESP for enterprise remote access; and payment systems, with key management using AES-CMAC for deriving session keys and authenticating transactions in chip-card protocols.

References

  1. https://eprint.iacr.org/2002/180
  2. https://csrc.nist.gov/pubs/sp/800/38/b/final
  3. https://csrc.nist.gov/projects/block-cipher-techniques/bcm/current-modes
  4. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-38b.pdf
  5. https://www.rfc-editor.org/rfc/rfc4493.html
  6. https://eprint.iacr.org/2002/180.pdf
  7. https://datatracker.ietf.org/doc/html/rfc4493
  8. https://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf
  9. https://www.cs.ucdavis.edu/~rogaway/papers/pmac.pdf
  10. https://www.nuee.nagoya-u.ac.jp/labs/tiwata/omac/ip/omac-ip.pdf
  11. https://cseweb.ucsd.edu/~mihir/papers/cbc.pdf
  12. https://www.nuee.nagoya-u.ac.jp/labs/tiwata/omac/docs/omac.pdf
  13. https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/proposed-modes/omac/omac-ad.pdf
  14. https://eprint.iacr.org/2003/082
  15. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38b.pdf
  16. https://doi.org/10.6028/NIST.SP.800-38B
  17. https://hal.science/hal-01959554/document
  18. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38b.pdf
  19. https://link.springer.com/chapter/10.1007/11601494_17
  20. https://crypto.stackexchange.com/questions/32325/side-channel-security-of-hmac-in-software
  21. https://eprint.iacr.org/2022/1234.pdf
  22. https://eprint.iacr.org/2023/218.pdf
  23. https://dl.acm.org/doi/10.1007/978-3-031-75757-0_4
  24. https://www.rfc-editor.org/rfc/rfc4494.html
  25. https://www.isical.ac.in/~mridul/Papers/Papers/FSE-09-GCBC.pdf
  26. https://cryptography.io/en/latest/hazmat/primitives/mac/cmac/
  27. https://pycryptodome.readthedocs.io/en/latest/src/hash/cmac.html
  28. https://github.com/louismullie/cmac-rb
  29. https://rubygems.org/gems/cmac-rb
  30. https://www.nuget.org/packages/BouncyCastle.Cryptography/
  31. https://www.iso.org/standard/71116.html
  32. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search
  33. https://datatracker.ietf.org/doc/html/rfc4494
  34. https://www.rfc-editor.org/rfc/rfc3610.html
  35. https://www.ibm.com/docs/en/zos/3.1.0?topic=keys-diversifying
Add your contribution
Related Hubs
User Avatar
No comments yet.