HKDF (Expand Only) Key Verification

HKDFExpand_Verify is the "did we get the same key?" node. It takes the same inputs as HKDFExpand_Derive - the input key material, target length, algorithm, and optional info - plus an expected_key, and returns a single BOOLEAN: did this derivation produce that key or not? It's the verification mirror of the expand-only derive node, and its job is to let one party confirm that another party's derived key matches their own, without having to ship the key around.

How it works

Under the hood it builds the same HKDFExpand instance as the derive node and calls .verify(message, expected_key) instead of .derive(message). cryptography's verify does the derivation internally and compares against expected_key, raising InvalidKey on mismatch - which this node catches and turns into False. So the "verification" isn't magic: it's derive-and-compare, wrapped so a failed check comes back as a clean boolean rather than a thrown exception.

The inputs that matter

• length - the target output length in bytes (16–256, default 32). Must match what the other party used, or the derivation differs and you get False even though you both did everything "right."
• message (BYTESLIKE) - the pseudorandom key material being expanded.
• algorithm - the hash; must match the derive side.
• expected_key (BYTESLIKE) - the key you're checking against. This is what the other party derived and sent you.
• info (optional, BYTESLIKE) - the context label; must match the derive side exactly, including being empty on both ends.

The output

• verified_status (BOOLEAN) - True when the derivation reproduces expected_key, False otherwise. Wire it into a BooleanOutputter or any boolean consumer.

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 provides HKDFExpand.

Where people get burned

• Any field off by a hair. Length, algorithm, or info differing from the derive side means False - even a byte of info difference or a 31 vs 32 length. There's no "close enough" in KDF verification. This is the node's entire failure mode, and it's worth checking all three inputs before suspecting a bug.
• Verifying a full-HKDF key with the expand-only node. If the other side ran extract+expand (HKDF_Derive with a salt) and you're checking with expand-only, you're comparing different schemes. Use the matching verify node (HKDF_Verify) for the full version.
• A False isn't proof of tampering. It only means the derivation didn't match - wrong inputs are the far more likely explanation than a compromised secret.

Realistically, most workflows don't need this node at all - the derive version hands you the key, and if you trust the pipeline you just use it. But in the "two parties each derive from a shared secret and want to confirm agreement" setup - which is exactly the kind of exchange an ARG final puzzle stages - this is the automated handshake that closes the loop.