ConcatKDF (Hash) Key Derivation

ConcatKDF is the "finish the handshake" step of modern cryptography. When two parties do an Elliptic Curve Diffie-Hellman exchange (like the pack's XDH/ECDH nodes produce), they don't get a usable symmetric key - they get a raw shared secret that's not in the right shape or length to feed an encryption algorithm. ConcatKDF is the standardized way to stretch and shape that secret into a proper key, defined by NIST SP 800-56A and the X9.63 standards. The "Hash" variant builds the derived key by repeatedly hashing the secret with a counter and context, concatenating the digests until it reaches your target length.

So: this node takes a shared secret in (message), a target length, and a hash algorithm, and returns derived_key - a BYTESLIKE value you can feed straight into ChaCha20Poly1305 or an AES node. It's the "derive the session key" node, and for anyone building multi-stage or multi-party ARG mechanics, it's the difference between improvising key math and doing it per-spec.

How it works

It wraps cryptography's ConcatKDFHash. The message input is the raw secret material to derive from (must be bytes - wire it from a BYTESLIKE source). The length input is the desired derived-key size in bytes, default 32 with a 16–256 range and 16-byte steps. The algorithm dropdown carries the full hash family roster - SHA2 variants, BLAKE2b/s, SHA3, SHA1, MD5, and SM3 - and the tooltip notes the obvious caveat: the hash's strength should match your security level. The optional other_info input is application-specific context (peer identities, protocol labels, etc.) that gets mixed into the derivation; leave it empty and it passes a blank byte string. The output is derived_key, a BYTESLIKE blob.

One implementation note worth knowing: the pack's own BLAKE2 hash node currently trips over a digest-size bug, but the BLAKE2b/BLAKE2s options here go through a different helper that uses the correct sizes - so you can safely pick BLAKE2 in this dropdown even while the standalone BLAKE2 node misbehaves.

The inputs that matter

• message - the shared secret / source material. Must be bytes.
• length - derived key length in bytes (default 32, min 16, max 256, step 16).
• algorithm - hash for the KDF; SHA256 is the sensible default, SHA512 if you're conservative.
• other_info (optional) - context bytes mixed into the derivation.

Output: derived_key (BYTESLIKE).

Installing it

Part of the ComfyUI ARG Toolkit pack. Install via ComfyUI Manager (search "ComfyUI ARG Toolkit") or:

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

Restart ComfyUI. Runs on the pack's cryptography dependency (with the rest of the stack: secretpy, stegano, invisible-watermark, reedsolo, transitive torch/opencv-python). No models, no API keys.

Gotchas

Remember the derivation parameters are part of the key: the same message with a different length, algorithm, or other_info produces a different key, and the decrypting side must use identical parameters. Also, length is constrained to a 16-byte step, so you can't request, say, 24 bytes - pick 16 or 32. And if your message wire won't connect, you've fed it a plain string instead of BYTESLIKE - run it through ByteslikeEncode first.