STRUCT CRYPTO_ALG(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct crypto_alg(9) πŸ’…

okay so bestie, welcome to the Kernel API Manual β€” today we're meeting struct crypto_alg, like, the blueprint of a cryptographic cipher algorithm. this is the main character struct. the blueprint of the blueprint. iykyk ✨


🌸 NAME 🌸

struct crypto_alg β€” definition of a cryptograpic cipher algorithm πŸŽ€

(yes, that's how the page spells it, and we're keeping it, don't come for me)


πŸ¦‹ SYNOPSIS πŸ¦‹

struct crypto_alg {
    struct list_head cra_list;
    struct list_head cra_users;
    u32 cra_flags;
    unsigned int cra_blocksize;
    unsigned int cra_ctxsize;
    unsigned int cra_alignmask;
    unsigned int cra_reqsize;
    int cra_priority;
    refcount_t cra_refcnt;
    char cra_name[CRYPTO_MAX_ALG_NAME];
    char cra_driver_name[CRYPTO_MAX_ALG_NAME];
    const struct crypto_type *cra_type;
    union {
      struct cipher_alg cipher;
    } cra_u;
    int (*cra_init)(struct crypto_tfm *tfm);
    void (*cra_exit)(struct crypto_tfm *tfm);
    void (*cra_destroy)(struct crypto_alg *alg);
    struct module *cra_module;
 };

like, look at her. every field a lil icon 🌟


πŸ‘‘ Members πŸ‘‘

okay so here's the field-by-field tea, no skipping, we stan a complete list πŸ’–

  • cra_list β€” internally used πŸ‘€ (that's it, that's the whole vibe, it's not for you)
  • cra_users β€” internally used, same deal, hands off bestie πŸ™ˆ
  • cra_flags β€” flags that describe this transformation, fr. peep the include/linux/crypto.h CRYPTO_ALG_* flags for the ones that go in here β€” those are what fine-tune the description of the transformation algorithm ✨
  • cra_blocksize β€” minimum block size of this transformation, aka the size in bytes of the smallest possible unit that can actually be transformed with this algorithm. users must respect this value, no cap. in the case of HASH transformation, it's possible for a smaller block than cra_blocksize to be passed to the crypto API for transformation β€” but for any other transformation type, an error gets returned on any attempt to transform chunks smaller than cra_blocksize πŸ’€
  • cra_ctxsize β€” size of the operational context of the transformation. this value tells the kernel crypto API how much memory needs to be allocated for the transformation context 🧠
  • cra_alignmask β€” for cipher, skcipher, lskcipher, and aead algorithms, this is 1 less than the alignment (in bytes) that the algorithm implementation requires for input and output buffers. when the crypto API is invoked with buffers that aren't aligned to this alignment, the crypto API automatically busts out appropriately aligned temporary buffers to comply with what the algorithm needs (for scatterlists this only happens if the algorithm uses the skcipher_walk helper functions). this misalignment handling carries a performance penalty, so it's preferred that algorithms do not set a nonzero alignmask. also, crypto API users may wish to allocate buffers aligned to the alignmask of the algorithm being used, so the API doesn't have to realign them. note: the alignmask is not supported for hash algorithms and is always 0 for them 🫢
  • cra_reqsize β€” size of the request context for this algorithm ⭐
  • cra_priority β€” priority of this transformation implementation. if multiple transformations with the same cra_name are available to the Crypto API, the kernel uses the one with the highest cra_priority. highest wins, it's giving competition arc πŸ”₯
  • cra_refcnt β€” internally used πŸ’…
  • cra_name β€” generic name (usable by multiple implementations) of the transformation algorithm. this is the name of the transformation itself. the kernel uses this field when looking up the providers of a particular transformation πŸ”
  • cra_driver_name β€” unique name of the transformation provider. this is the name of the provider of the transformation. it can be any arbitrary value, but usually it contains the name of the chip or provider and the name of the transformation algorithm 🏷️
  • cra_type β€” type of the cryptographic transformation. this is a pointer to struct crypto_type, which implements callbacks common to all transformation types. multiple options exist, like crypto_skcipher_type, crypto_ahash_type, crypto_rng_type. this field might be empty β€” in that case there are no common callbacks, which is the case for: cipher πŸ¦‹
  • cra_u β€” callbacks implementing the transformation. this is a union of multiple structures. depending on the type of transformation selected by cra_type and cra_flags above, the associated structure must be filled with callbacks. this field might be empty β€” that's the case for ahash, shash 🌈
  • cra_u.cipher β€” union member containing a single-block symmetric cipher definition. see struct cipher_alg πŸ”
  • cra_init β€” deprecated, do not use 🚫
  • cra_exit β€” deprecated, do not use 🚫 (yes both of them, leave them alone)
  • cra_destroy β€” internally used πŸ™ˆ
  • cra_module β€” owner of this transformation implementation. set it to THIS_MODULE πŸ‘‘

✨ Description ✨

the struct crypto_alg describes a generic Crypto API algorithm and is common for all of the transformations πŸ’«

any variable not documented here shall not be used by a cipher implementation, because it's internal to the Crypto API. like, don't touch what you didn't read about, bestie β€” that's the whole rule πŸ™

πŸŽ€ SEE ALSO πŸŽ€

  • Kernel file ./include/linux/crypto.h
  • Block Cipher Context Data Structures(9)
  • Block Cipher Algorithm Definitions(9)
  • struct cipher_alg(9)

and that's the whole page, periodt πŸ’œ go read those see-alsos, they're literally linked in spirit β€” and if you ever need to find this again, it lives in ./include/linux, dated October 2026, slaying in the Kernel API Manual forever 🫢🌸✨

πŸ“¦ where this page comes from