KBKDF Key Verification

Let's say you've hidden something behind a password, or you've built an ARG stage where players are supposed to "unlock" the next clue with a secret. The KBKDF_Verify node is the check side of that puzzle: you feed it the secret and an expected key, and it tells you, as a plain boolean, whether that secret really derives to the key you intended. No comparing the keys yourself, no storing the plaintext secret anywhere in your workflow.

It's the partner to KBKDF_Derive from the same pack. KBKDF stands for key-based key derivation function - the family specified in NIST SP 800-108 - and this node uses the counter-mode variant. The idea: you run a hash repeatedly over the secret plus a counter, and the counter value gets mixed into the output, so each derived block is distinct. Think of it as "give me a key from this password, but make sure the derivation is standardized and hard to confuse with any other use of the same password."

Here's what actually matters to a beginner:

• message - the secret to test. It must be bytes, not a plain text string. Run your text through one of the pack's string-to-bytes converters first; feeding it a raw string is the single most common way this node bites people.
• expected_key - the bytes you expect to come out of derivation. This is what you're verifying against.
• algorithm - the hash underneath (SHA256, BLAKE2b, SHA3, all the way down to MD5 and SM3 if you want to be weird about it).
• length - derived key length in bytes, default 32.
• operation_mode - KBKDFHMAC (HMAC-based, the sensible default) or KBKDFCMAC (block-cipher based, for when you're working with AES primitives).
• rlen / llen - how many bytes the counter and length fields occupy. The defaults of 4 are fine for anything you're doing in a puzzle; you'd only touch them to match an external spec.
• location - where the counter bytes sit (BeforeFixed, AfterFixed, or MiddleFixed), with break_location giving the byte offset for the middle case. Again: leave alone unless you're matching a published standard.
• label / context - domain-separation bytes. Two otherwise-identical derivations with different labels produce different keys, which is the whole point of a KDF.
• fixed - a shortcut field; if you supply it, label and context are ignored.

The one output is verified_status, a BOOLEAN you can wire straight into a conditional or a switch node to gate the next step of your workflow.

Installation is the same as the rest of the pack: in ComfyUI Manager search for "ComfyUI ARG Toolkit", install, restart. Or manually:

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

Then restart ComfyUI and the nodes appear under ARG Toolkit/Cryptography/Modern/Key Derivation. No model files to download; the heavy lifting is the cryptography Python library.

Where people get burned: verification silently returns False even with the right secret, because every parameter has to match the derive side exactly - same algorithm, same length, same rlen/llen, same label or context, same counter location. If the person who made the derive side left label empty and you put something in it, you'll never match. And if the node errors, it's almost certainly a bytes-vs-string mismatch on message or expected_key.