ConcatKDF (Hash) Key Verification

ConcatKDFHash_Verify is the confirmation step for the ConcatKDF (Hash) key derivation node: you give it the same derivation inputs plus the key you expected to get, and it tells you with a clean boolean whether the derivation actually produces that key. In a multi-party ARG or a "prove you know the secret" mechanic, that's the node you point at a player-submitted guess - instead of deriving the key yourself and squinting at two hex dumps, you let this node compare them and hand you a True/False.

Under the hood it's the same NIST SP 800-56A / X9.63 ConcatKDF machinery as the Derive variant, just wearing a different output hat. It runs the derivation exactly as the Derive node would - same message, length, algorithm, and optional other_info - then compares against the provided expected_key and returns verified_status (a boolean) instead of the derived bytes. It's literally the same class family in the pack's source, with the verify variant swapping the output type and adding one input. That makes it dead easy to reason about: set up the inputs once, and you have both a key generator and a key checker.

How it works

Mechanically, it wraps cryptography's ConcatKDFHash.verify(), which re-derives the key and checks it against expected_key. Two failure modes matter. If the derivation produces something different from expected_key, you get verified_status = False - the ordinary "nope, wrong key or wrong parameters" answer. If, on the other hand, the verify object gets finalized twice (which the underlying library doesn't allow), the pack surfaces a RuntimeError explaining that verification was called more than once on a finalized KDF - in practice that's a signal to rebuild the node rather than a scenario you'd engineer deliberately.

The inputs that matter

• message - the shared secret / source material, in bytes.
• length - derived key length in bytes (default 32, min 16, max 256, step 16).
• algorithm - the hash used for derivation; must match the Derive side exactly.
• other_info (optional) - context bytes; must match what was used to derive.
• expected_key - the key you're checking against, as bytes.

Output: verified_status, a boolean you can wire into a conditional, a boolean-to-text node like BooleanOutputter, or an if/else-style routing node.

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. Powered by the pack's cryptography dependency (plus secretpy, stegano, invisible-watermark, reedsolo, and transitive torch/opencv-python). No models, no API keys.

Gotchas

The whole game here is parameter matching: any difference in length, algorithm, or other_info between how the key was derived and how you verify it will produce a hard False, even when the secret is correct. When you get a false negative, check the derivation settings before you suspect the key. And remember the false-negative direction: a False can mean "wrong key" or "wrong derivation settings," so don't use it as a pure key oracle unless you've pinned the parameters.