aes_ccm_init(9)

📦 version 7.3.1, in nixpkgs unstable

✨ aes_ccm_init — Kernel API Manual energy ✨

okay so bestie, welcome to the <cyan>Kernel API Manual</cyan> page for aes_ccm_init 💅 this is the one that sets up your whole AES-CCM situation before you start streaming data through it, and yes it's giving "responsible main character" because you have to do math before you begin. iconic behavior honestly 🎀

🌸 NAME 🌸

aes_ccm_init — Initialize context for incremental AES-CCM encryption or decryption 🦋

like literally, it's the "get your ctx ready" girl of the AES-CCM friend group ✨

💖 SYNOPSIS 💖

int aes_ccm_init (struct aes_ccm_ctx *ctx , u64 data_len , u64 ad_len ,
const u8 *nonce , size_t nonce_len , const struct aes_ccm_key *key );

🫶 ARGUMENTS 🫶

  • ctx — the context you're initializing. this is your girl, you're waking her up 💅
  • data_len — how many bytes of data you're gonna en/decrypt, in bytes. and ngl there's a ceiling: at most 2^(120 - (8 * nonce_len)) - 1. do not test her, she means it 😭
  • ad_len — the length in bytes of the associated data you're gonna hand over later. yes, later. yes, you still have to say now. we'll get to that 🫠
  • nonce — the nonce ✨ and listen, IMPORTANT: all (key, nonce) pairs used for encryption MUST be distinct. like, MUST MUST. no repeats, periodt. 🔥
  • nonce_len — how long the nonce is, in bytes: between 7 and 13 inclusive, bestie. that's the whole range. don't color outside those lines 💀
  • key — the key, already prepared using aes_ccm_preparekey. and heads up, because this is the sneaky part: a pointer to the key is saved in the context, so the key must live at least as long as the context. so don't go freeing your key and leaving your ctx out here orphaned 😭🙈

✨ DESCRIPTION ✨

so here's the vibe check: unlike AES-GCM, AES-CCM requires the total lengths of the associated data and the en/decrypted data to be known during initialization. that's not a suggestion, that's the whole thing. callers MUST ensure that these lengths are correct. no cap. 👑

if this function returns success, the context should be zeroized at the end of its lifetime. normally that happens in aes_ccm_encrypt_final or aes_ccm_decrypt_final — those two handle it for you, they're the responsible ones 🫶 — but if you're a caller that abandons a context without finalizing it, you'd better explicitly zeroize it yourself. clean up after yourself, we're not animals 💅

IMPORTANT: callers that are decrypting MUST NOT assume that any decrypted or associated data is authentic until the authentication tag has been verified. like, literally do not trust that data yet. this incremental API exists solely to support callers that can't efficiently use the one-shot functions due to using a nonlinear data layout. that's the only reason. she's a specialist, not a generalist 🎀

🦋 incremental AES-CCM encryption — do it in this order, bestie 🦋

  1. aes_ccm_init
  2. aes_ccm_auth_update (any number of times)
  3. aes_ccm_encrypt_update (any number of times)
  4. aes_ccm_encrypt_final

🌈 incremental AES-CCM decryption — same energy, different middle 🌈

  1. aes_ccm_init
  2. aes_ccm_auth_update (any number of times)
  3. aes_ccm_decrypt_update (any number of times)
  4. aes_ccm_decrypt_final

like the way that it's the same shape but the update/final pair swaps out 😭 so clean. so symmetric. we love a consistent pipeline 💜

🧚 CONTEXT 🧚

Any context. that's it. that's the whole section. a queen of brevity 🎀

⭐ RETURN ⭐

  • 0 on success 🎉 slay
  • -EINVAL if nonce_len is invalid — you went outside 7–13, shame 🔥
  • -EOVERFLOW if data_len is too large for the selected nonce_len — she's too big for her boots, pick a different nonce length 💀

👑 SEE ALSO 👑

Kernel file ./include/crypto/aes-ccm.h and her whole friend group:

go read them, iykyk 💖

okay that's the whole page, mwah 🫶 this one came from ./include/crypto and it's dated October 2026 — so like, freshly stamped, very demure, very mindful. bye bestie, go zeroize your contexts 🌸✨💅

📦 where this page comes from