Nodes/ComfyUI ARG Toolkit/PBKDF2HMAC Key Verification
ComfyUI Node

PBKDF2HMAC Key Verification

Did this password derive to the right key? Ask the node.

By AzelusLightvale·Created 12 months ago·Updated about 15 hours ago· 1
PBKDF2HMAC Key Verification
  • message
  • salt
  • expected_key
  • verified_status
length32
algorithm
iterations1200000

PBKDF2HMAC_Verify is the check side of the pack's PBKDF2 key derivation: you hand it a candidate secret plus an expected key, and it returns a plain boolean - did this secret actually derive to that key? If you're building an ARG stage where the next clue unlocks after someone enters a password, or you want to confirm a decryption key before you bother running the decrypt, this is the node that gates the workflow.

It works exactly like PBKDF2HMAC_Derive, because under the hood it is that node with one extra input. It runs the derivation on your candidate secret and compares the result against expected_key - not by eyeballing bytes, but with the cryptography library's constant-time verify, so you don't leak timing information about how close a wrong guess was. Output verified_status is a BOOLEAN you can wire into a switch or conditional to route the graph.

The inputs mirror the derive side, and this is where people slip up:

  • message - the secret to test (BYTESLIKE; convert text to bytes first).
  • salt - must be byte-for-byte identical to the salt used at derive time. This is the most common cause of a mysteriously false verification.
  • algorithm - same hash as the original derivation.
  • iterations - same count as the original derivation. The default 1.2M applies here too, so verification is just as slow as derivation. Expect a beat.
  • length - same derived-key length.
  • expected_key - the key you're verifying against, BYTESLIKE.

Every one of those parameters is part of the derivation, and changing any of them changes the output. Verification "fails" on the wrong salt or wrong iteration count even with the correct password, and it fails silently - you get False, not an error, which makes it easy to chase ghosts. If a workflow you downloaded verifies False, first check that salt and iterations are wired through identically on both nodes before suspecting the password.

It lives in the pack's key-derivation family alongside KBKDF, HKDF, scrypt and Argon2id, all thin wrappers over Python's cryptography library - real implementations, not toy crypto. The family pattern is worth learning once: every _Derive node has a matching _Verify sibling that adds expected_key and swaps the output to a boolean.

Install: ComfyUI Manager → search "ComfyUI ARG Toolkit" → install → restart, or:

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

Restart ComfyUI; the node is under ARG Toolkit/Cryptography/Modern/Key Derivation. No model downloads - the only dependency that matters here is cryptography, which Manager installs with the pack.

One last habit worth building: keep the derivation parameters in a note or exposed as workflow inputs so the verify side can't drift from the derive side. When they drift, the node still "works" - it just lies to you.

CategoryARG Toolkit/Cryptography/Modern/Key Derivation

Inputs (6)

NameTypeDefaultDescription
lengthINT3216–256The desired length of the derived key in bytes.
messageBYTESLIKEThe message to derive key from. Must be bytes.
saltBYTESLIKEThe nonce used to generate the key. Use SystemRandom (Random Nonce Generator) to generate this.
algorithmCOMBOThe algorithm to use for hash generation.
iterationsINT12000001–2147483647The number of iterations to perform of the hash function. This can be used to control the length of time the operation takes. Higher numbers help mitigate brute force attacks against derived keys.
expected_keyBYTESLIKEThe expected result of key derivation.

Outputs (1)

NameTypeDescription
verified_statusBOOLEAN