aes_ecb_encrypt(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– aes_ecb_encrypt(9) πŸ’–

okay so bestie, welcome to the Kernel API Manual page for aes_ecb_encrypt β€” yes the whole manual is literally called that, we're in the big leagues now πŸŽ€

✨ NAME ✨

aes_ecb_encrypt β€” encrypt data using AES-ECB πŸ”

✨ SYNOPSIS ✨

void aes_ecb_encrypt (u8 *dst , const u8 *src , size_t len ,
       aes_encrypt_arg key );

that's the whole vibe. four args, one function, let's go 🫢

✨ ARGUMENTS ✨

  • dst β€” the destination buffer, a.k.a. where the encrypted glow-up lands πŸ’…. it can be in-place or out-of-place, both are fine. for other overlaps though? nope, the behavior is unspecified β€” so don't be cute with it 😭
  • src β€” the source data, the original, the before picture 🌸
  • len β€” number of bytes to encrypt. must be a multiple of AES_BLOCK_SIZE β€” no cap, this is non-negotiable 🚨
  • key β€” the key, and it has to be already prepared using aes_preparekey or aes_prepareenckey πŸ”‘βœ¨ like, don't hand it a raw key, that's not the move

✨ DESCRIPTION ✨

okay real talk for a sec: ECB mode is insecure by itself πŸ’€ this is not the moment to build your whole security model on it.

so why does it exist? literally only for compatibility with legacy protocols and for internal use by other modes 🧚 β€” that's the whole reason, periodt.

it does support incremental encryption, which is lowkey iconic, BUT (and this is the catch) the length of each chunk must be a multiple of AES_BLOCK_SIZE πŸ“β­ same rule, every single time.

✨ CONTEXT ✨

Any context. 🌈 truly the most chill line on this page. she's flexible.

✨ SEE ALSO ✨

  • kernel file ./include/crypto/aes-ecb.h πŸ“
  • aes_ecb_decrypt(9) β€” the reverse queen, iykyk πŸ‘‘

and that's the page bestie! πŸ¦‹ this whole thing lives under ./include/crypto, came out in October 2026, and yeah, it's aes_ecb_encrypt(9) the whole way through πŸ’œ mwah, go encrypt responsibly πŸŽ€βœ¨

πŸ“¦ where this page comes from