HKDF Key Verification

HKDF_Verify is the full-pipeline sibling of HKDFExpand_Verify: it checks whether a full HKDF derivation - extract and expand - reproduces a given expected_key. Where the expand-only version assumes the input is already high-entropy, this one includes the salt-mixing extract step, so it's the node you use when the shared secret is something human-ish and you want to confirm both sides derived the same strong key.

How it works

It constructs the same HKDF object as HKDF_Derive (algorithm, length, salt, info) and calls .verify(message, expected_key). The library performs the full extract-and-expand, compares against the expected key, and raises InvalidKey on mismatch - caught here and returned as False. So this node is "derive-and-compare," with the derive step being the real RFC 5869 two-phase HKDF, not a truncated version.

The inputs that matter

• message (BYTESLIKE) - the input key material, your shared secret. Must be bytes.
• length - the target output length in bytes (16–256, default 32). Same on both sides, or nothing matches.
• algorithm - the hash for the HMAC; the full dropdown (SHA-2, SHA-3, BLAKE2, SHA1, MD5, SM3). SHA256 for anything real.
• expected_key (BYTESLIKE) - the key you're verifying against, sent to you by the other party.
• salt (optional, BYTESLIKE) - "Optional, but highly recommended," per the tooltip. Here's where it gets sneaky: the salt is part of the derivation, so if the other party used a salt and you didn't (or used a different one), you derive different keys and get False. The salt must match byte-for-byte.
• info (optional, BYTESLIKE) - context binding; also must match, including being empty on both sides.

The output

• verified_status (BOOLEAN) - True if the derivation reproduces expected_key, False otherwise.

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") - cryptography supplies the HKDF implementation.

Where people get burned

• Salt mismatch. This is the classic trap. Two parties sharing a passphrase but not sharing a salt derive different keys, and the verify node says False. Salt is not optional in practice when both sides need agreement - agree on it first.
• Crossing the verify variants. Verifying a full-HKDF key with HKDFExpand_Verify (or vice versa) compares different schemes. Match the verify node to the derive node that produced the key.
• One mismatched field. Length, algorithm, info, salt - any single difference is a guaranteed False. KDF verification has no tolerance for partial agreement.

This node is niche. Its moment is the shared-secret handshake: both parties derive a key from a passphrase they agreed on, and this node is the automated confirmation that both sides landed on the same bytes. For the far more common "I just need a key, here's my secret" case, you want HKDF_Derive - that node hands you the key directly and never needs an expected_key at all.