CMAC_INIT(3)

📦 version 4.4.0, in alpine 3.24, arch rolling

💖 CMAC_INIT(3) 💖

Bestie, welcome to CMAC_INIT(3) from the Library Functions Manual — it's giving low-level libcrypto crypto realness, and we're about to make CMAC make sense. 💅

🌸 NAME 🌸

CMAC_CTX_new, CMAC_Init, CMAC_Update, CMAC_Final, CMAC_CTX_copy, CMAC_CTX_get0_cipher_ctx, CMAC_CTX_cleanup, CMAC_CTX_free — Cipher-based message authentication code. No cap, that's the whole squad. 🫶

✨ SYNOPSIS ✨

library “libcrypto” #include <openssl/cmac.h>

CMAC_CTX *
CMAC_CTX_new(void);

int
CMAC_Init(CMAC_CTX *ctx, const void *key, size_t key_len,
    const EVP_CIPHER *cipher, ENGINE *engine);

int
CMAC_Update(CMAC_CTX *ctx, const void *in_data, size_t in_len);

int
CMAC_Final(CMAC_CTX *ctx, unsigned char *out_mac, size_t *out_len);

int
CMAC_CTX_copy(CMAC_CTX *out_ctx, CMAC_CTX *in_ctx);

EVP_CIPHER_CTX *
CMAC_CTX_get0_cipher_ctx(CMAC_CTX *ctx);

void
CMAC_CTX_cleanup(CMAC_CTX *ctx);

void
CMAC_CTX_free(CMAC_CTX *ctx);

🦋 DESCRIPTION 🦋

Okay so CMAC is a message authentication code algorithm that can employ an arbitrary block cipher using a symmetric key. Iconic behavior, honestly. 💖

This manual page is about the low-level functions that implement CMAC. But bestie, listen: instead of using these functions directly, application programs normally call EVP_PKEY_new_CMAC_key(3) and then pass the resulting EVP_PKEY object to EVP_DigestSignInit(3). That's the main-character route. 👑

The CMAC API is object-oriented. Calculating a message authentication code requires a CMAC_CTX object. Usually, the functions CMAC_CTX_new(), CMAC_Init(), CMAC_Update(), CMAC_Final(), and CMAC_CTX_free() need to be called in this order. Periodt. 🎀

  • CMAC_CTX_new() — allocates a new CMAC_CTX object, initializes the embedded EVP_CIPHER_CTX object, and marks the object itself as uninitialized. Fresh out the box, but not ready to go yet. ✨
  • CMAC_Init() — selects the given block cipher for use by ctx. Functions to obtain suitable EVP_CIPHER objects are listed in the CIPHER LISTING section of the EVP_EncryptInit(3) manual page. Unless key is NULL, CMAC_Init() also initializes ctx for use with the given symmetric key that is key_len bytes long. In particular, it calculates and internally stores the two subkeys and initializes ctx for subsequently feeding in data with CMAC_Update(). The engine argument is ignored; passing NULL is recommended. Lowkey just pass NULL, bestie. 🙈
  • CMAC_Init() again — if ctx is already initialized, CMAC_Init() can be called again with key and cipher both set to NULL and key_len set to 0. In that case, any data already processed is discarded and ctx is re-initialized to start reading data anew. It's a reset era. 🔄
  • CMAC_Update() — processes in_len bytes of input data pointed to by in_data. Depending on the number of input bytes already cached in ctx, on in_len, and on the block size, this may encrypt zero or more blocks. Unless in_len is zero, this function leaves at least one byte and at most one block of input cached but unprocessed inside the ctx object. CMAC_Update() can be called multiple times to concatenate several chunks of input data of varying sizes. Chunk it, bestie. 🧚
  • CMAC_Final() — stores the length of the message authentication code in bytes, which equals the cipher block size, into *out_len. Unless out_mac is NULL, it encrypts the last block, padding it if required, and copies the resulting message authentication code to out_mac. The caller is responsible for providing a buffer of sufficient size. Do not skip the buffer math, fr fr. 😭
  • CMAC_CTX_copy() — performs a deep copy of the already initialized in_ctx into out_ctx. Deep copy, not shallow vibes. 💅
  • CMAC_CTX_cleanup() — zeros out both subkeys and all temporary data in ctx and in the embedded EVP_CIPHER_CTX object, frees all allocated memory associated with it, except for ctx itself, and marks it as uninitialized, such that it can be reused for subsequent CMAC_Init(). Cleanup era, but the object itself survives. 🧼
  • CMAC_CTX_free() — calls CMAC_CTX_cleanup(), then frees ctx itself. If ctx is NULL, no action occurs. Very "nothing to see here" of it. 🫶

🔥 RETURN VALUES 🔥

CMAC_CTX_new() returns the new context object or NULL in case of failure. It succeeds unless memory is exhausted. Memory said "not today" and NULL said "bet." 💀

CMAC_Init(), CMAC_Update(), CMAC_Final(), and CMAC_CTX_copy() return 1 on success or 0 on failure. CMAC_Init() fails if initializing the embedded EVP_CIPHER_CTX object fails. The others fail if in_ctx is uninitialized. CMAC_Update() and CMAC_Final() also fail if encrypting a block fails, and CMAC_CTX_copy() if copying the embedded EVP_CIPHER_CTX object fails, which can for example happen when memory is exhausted. So yeah, check those returns, bestie. 👀

CMAC_CTX_get0_cipher_ctx() returns an internal pointer to the EVP_CIPHER_CTX object that is embedded in ctx. It's an inside look, not a copy. 🎀

🌈 ERRORS 🌈

The CMAC code itself does not use the <openssl/err.h> framework, so in general, the reasons for failure cannot be found out with ERR_get_error(3). That's the tea. 🍵

However, since the EVP_EncryptInit(3) functions are used internally, entries may still get pushed onto the error stack in some cases of failure. So sometimes the error stack is still serving looks, even if CMAC didn't put them there. ✨

👑 SEE ALSO 👑

⭐ STANDARDS ⭐

Morris Dworkin, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, National Institute of Standards and Technology, NIST Special Publication 800-38B, https://doi.org/10.6028/NIST.SP.800-38B, Gaithersburg, Maryland, May 2005, updated October 6, 2016. Academic icon behavior. 🎓

💜 HISTORY 💜

These functions first appeared in OpenSSL 1.0.1 and have been available since OpenBSD 5.3. Old enough to have lore, still relevant enough to slay. 💅

And that's the footer tea, bestie: this page is from Debian, dated June 8, 2025, and it's the CMAC_INIT(3) page. Mwah. 💋🎀

📦 where this page comes from