STRUCT AHASH_ALG(9)

📦 version 7.3.1, in nixpkgs unstable

🦋 NAME 🦋

okay so bestie, this is the manual page for struct ahash_alg — it's the asynchronous message digest definition, and honestly it's giving "blueprint for how your crypto driver actually does hashing" 💅

✨ SYNOPSIS ✨

the whole struct, verbatim, no cap:

struct ahash_alg {
    int (*init)(struct ahash_request *req);
    int (*update)(struct ahash_request *req);
    int (*final)(struct ahash_request *req);
    int (*finup)(struct ahash_request *req);
    int (*digest)(struct ahash_request *req);
    int (*export)(struct ahash_request *req, void *out);
    int (*import)(struct ahash_request *req, const void *in);
    int (*export_core)(struct ahash_request *req, void *out);
    int (*import_core)(struct ahash_request *req, const void *in);
    int (*setkey)(struct crypto_ahash *tfm, const u8 *key, unsigned int
keylen);
    int (*init_tfm)(struct crypto_ahash *tfm);
    void (*exit_tfm)(struct crypto_ahash *tfm);
    struct hash_alg_common halg;
 };

💖 Members 💖

okay this is the main character section, every callback explained, pls read it all fr fr 🫶

  • init — [mandatory] ⭐ Initialize the transformation context. It's only there to set up the state of the HASH transformation at the very beginning — think "getting ready" energy. It shall fill in the internal structures used during the entire duration of the whole transformation. No data processing happens at this point, none. And heads up: driver code implementation must not use req->result here 🙈
  • update — [mandatory] ⭐ Push a chunk of data into the driver for transformation. This one actually pushes blocks of data from upper layers into the driver, which then passes those to the hardware as seen fit. It must not finalize the HASH transformation by calculating the final message digest — because it's just adding more data into the transformation, that's it. It shall not modify the transformation context either, because this function may be called in parallel with the same transformation object (so like, keep your hands to yourself 😭). Data processing can happen synchronously [SHASH] or asynchronously [AHASH] at this point. Driver must not use req->result. For block-only algorithms, update must return the number of bytes to store in the API partial block buffer 👑
  • final — [mandatory] ⭐ Retrieve result from the driver. It finalizes the transformation and retrieves the resulting hash from the driver, then pushes it back up to upper layers. No data processing happens at this point unless hardware requires it to finish the transformation — and if it does, then the data buffered by the device driver is processed 💀
  • finup — [optional] Combination of update and final. It's effectively a combination of update and final calls issued in sequence. Since some hardware literally cannot do update and final separately, this callback was added so that such hardware can be used at least by IPsec. Data processing can happen synchronously [SHASH] or asynchronously [AHASH] at this point 🌈
  • digest — Combination of init and update and final. This one effectively behaves as the entire chain of operations — init, update and final issued in sequence. Just like finup, it was added for hardware which cannot do even the finup, but can only do the whole transformation in one single run 😤 Data processing can happen synchronously [SHASH] or asynchronously [AHASH] at this point.
  • export — Export partial state of the transformation. It dumps the entire state of the ongoing transformation into a provided block of data so it can be import'ed back later on. Super useful when you wanna save a partial result of the transformation after processing a certain amount of data, and reload that partial result multiple times later on for multiple re-use, iykyk ✨ No data processing happens at this point. Driver must not use req->result.
  • import — Import partial state of the transformation. Loads the entire state of the ongoing transformation from a provided block of data so the transformation can continue from this point onward 🎀 No data processing happens at this point. Driver must not use req->result.
  • export_core — Export partial state without partial block. Only defined for algorithms that are not block-only.
  • import_core — Import partial state without partial block. Only defined for algorithms that are not block-only.
  • setkey — Set optional key used by the hashing algorithm. Intended to push the optional key used by the hashing algorithm from upper layers into the driver. This function can store the key in the transformation context, or it can outright program it into the hardware 🔥 In the former case you gotta be careful to program the key into the hardware at the appropriate time, and careful that .setkey can be called multiple times during the existence of the transformation object. Not all hashing algorithms implement this function, since it's only needed for keyed message digests. SHAx/MDx/CRCx do NOT implement this function. HMAC(MDx)/HMAC(SHAx)/CMAC(AES) do implement this function. This one must be called before any other of init, update, final, finup, digest is called. No data processing happens at this point 💅
  • init_tfm — Initialize the cryptographic transformation object. Called only once at the instantiation time, right after the transformation context was allocated. If the cryptographic hardware has some special requirements that need to be handled by software, this function shall check for the precise requirement of the transformation and put any software fallbacks in place 🧚
  • exit_tfm — Deinitialize the cryptographic transformation object. It's the counterpart to init_tfm, used to remove various changes set in init_tfm 🦋
  • halg — see struct hash_alg_common

👑 SEE ALSO 👑

the whole friend group, go say hi 💜

and that's the whole page bestie, go forth and hash responsibly 🌸

this lil masterpiece lives in ./include/crypto, stamped October 2026 — mwah, slay, periodt 💅🎀

📦 where this page comes from