crypto_alloc_cipher(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… crypto_alloc_cipher(9)

okay so bestie, welcome to the Kernel API Manual entry for crypto_alloc_cipher β€” this is the moment where you get yourself a single block cipher handle, and honestly? iconic behavior. let's get into it πŸ’–


✨ NAME ✨

crypto_alloc_cipher β€” allocate single block cipher handle πŸŽ€


🌸 SYNOPSIS 🌸

struct crypto_cipher * crypto_alloc_cipher (const char *alg_name , u32
type , u32 mask );

like, that's the whole vibe. one function, three args, returns you a struct crypto_cipher *. no cap. ✨


πŸ¦‹ ARGUMENTS πŸ¦‹

  • alg_name β€” this one's the cra_name / name or the cra_driver_name / driver name of the single block cipher. so you either give it the cute generic name or the specific driver name, your call, main character energy either way 🫢
  • type β€” specifies the type of the cipher. yep, that's the parameter. that's what it does πŸ’…
  • mask β€” specifies the mask for the cipher. also exactly what it says on the tin 🌸

πŸ’œ DESCRIPTION πŸ’œ

so what we're doing here is allocating a cipher handle for a single block cipher. the returned struct crypto_cipher is the cipher handle β€” and bestie, you literally need it for any subsequent API invocation for that single block cipher. like, it's not optional. it's the key to the whole group chat πŸ”₯


⭐ RETURN ⭐

  • on success? you get the allocated cipher handle. slay πŸ’–
  • on error? IS_ERR is true, and PTR_ERR returns the error code. so always, always check β€” don't just start using it and expect the universe to be nice to you 😭
fr fr, run your IS_ERR check. the kernel does not do vibes-based error handling.

🌈 SEE ALSO 🌈

like a whole little friend group of cipher functions, iykyk 🧚


and that's the page!! πŸ’œ this one lives in ./include/crypto/internal, dated October 2026, and it's filed under crypto_alloc_cipher(9) β€” go forth and allocate responsibly, bestie πŸ‘‘πŸŽ€

πŸ“¦ where this page comes from