HKDF Key Derivation

A secret passphrase is not a key. It's a string of human-typed bytes with bad entropy and predictable structure, and feeding it straight into an encryption algorithm is a classic way to get a weak result. HKDF_Derive exists to fix that: it's the HMAC-based Extract-and-Expand Key Derivation Function from RFC 5869, packaged as a node, and it turns any BYTESLIKE secret into a well-mixed, right-sized cryptographic key. If the pack's Fernet or symmetric nodes ever need a key derived from a shared secret, this is the node that produces it properly.

How it works

HKDF runs in two steps:

1. Extract - the input key material (your secret) is mixed with an optional salt through HMAC to produce a fixed-size pseudorandom intermediate key. The salt is what stops the same secret from always producing the same key across uses.
2. Expand - that intermediate key is stretched out to your target length, with the optional info field binding the result to a specific purpose (like "encryption key for user 42") so keys derived for different contexts don't collide.

The node wraps cryptography's HKDF class - kdf.derive(message) is the whole core - so the math is the battle-tested standard implementation, not a homebrew.

The inputs that matter

• message (BYTESLIKE) - the input key material, i.e. your secret. It "must be bytes," per the tooltip, so route text through a ByteslikeEncode-style node first.
• length - output size in bytes, from 16 to 256 (default 32, stepping by 16). 32 bytes = 256 bits, which is the modern default for AES or Fernet keys.
• algorithm - the hash behind the HMAC: SHA-2 family, SHA-3, BLAKE2, SHA1, MD5, SM3. SHA256 is the right default; the pack offers the full buffet because it can, not because you need it.
• salt (optional, BYTESLIKE) - the tooltip says it plainly: "Optional, but highly recommended." Same secret plus the same salt gives the same key, so a salt is how you keep a shared secret from becoming a predictable key.
• info (optional, BYTESLIKE) - context binding; defaults to an empty byte string if left out.

The output

• derived_key (BYTESLIKE) - the derived key, ready to feed into a KEYOBJ-less consumer like the pack's symmetric encrypt node or Fernet (as long as the length matches what Fernet wants).

Installing it

Part of the ComfyUI ARG Toolkit:

cd ComfyUI/custom_nodes
git clone https://github.com/AzelusLightvale/ComfyUI-ARG-Toolkit

Restart ComfyUI, or install via ComfyUI Manager ("ComfyUI ARG Toolkit") - it pulls cryptography, which provides the HKDF implementation.

Where people get burned

• Hashing a password. HKDF is a key derivation function, not a password hashing function - it's not designed to be slow, so it gives no brute-force resistance. For passwords, the pack's Argon2/PBKDF2/Scrypt nodes are the right tool. The web doc for this node says it outright: HKDF is "not intended for hashing passwords."
• Missing the salt. Skip it and two identical secrets produce identical keys everywhere. If you want domain separation, salt it.
• Length mismatches downstream. Derive 16 bytes and feed Fernet, which needs 32 - that's an error you'll chase for a while. Match length to the consumer's requirement.
• Secret → bytes. Forgetting the BYTESLIKE conversion is the pack's universal first-run mistake.

For the "we both know the passphrase, derive the same key" pattern, HKDF is the correct, boring, standard way to do it - and this node is that standard, minus the terminal.