Argon2id Key Verification

Argon2id_Verify is the "is this the right passphrase?" half of the pack's key-derivation pair. Derive makes a key from a secret; Verify tells you whether a candidate secret actually produces a given key - and it does it the correct way, which matters more than it sounds. The node runs the Argon2id derivation on your candidate message with the same salt and parameters, then compares the result to an expected key. Matching → output is true, mismatching → false. There's no storage of plaintext passphrases anywhere in the loop, which is exactly how password checking is supposed to work.

That's the whole honest design, and it's a nice fit for an ARG: you can publish the derived key (or a PHC-encoded hash) as the "lock," and solvers who find the right passphrase get the boolean flip from false to true. You never reveal the secret itself.

The inputs

Everything from Argon2id_Derive is here, plus one:

• message (BYTESLIKE) - the candidate secret you're testing.
• salt (BYTESLIKE) - must match the salt used when the expected key was derived. Get this wrong and nothing verifies, which is the most common false-negative you'll see.
• memory_cost, iterations, parallel_lanes, length - all must match the original derivation too. Argon2id is deterministic only when every parameter is identical. The defaults (65536 KiB, 1 iteration, 4 lanes, 32 bytes) are what the Derive node defaults to, so if you didn't touch anything, they match.
• expected_key (BYTESLIKE) - the reference result of the derivation. The tooltip names it directly.
• mode - the same format switch as Derive: on = raw bytes, off = PHC-encoded string. Set it to match the format your expected_key is in.
• ad / secret (optional BYTESLIKE) - only if the original derivation used them.

Output is a single verified_status of type BOOLEAN - the cleanest wire in the whole pack. Feed it into a boolean comparator or a workflow branch and you've got a password gate.

Where people get burned

Parameter mismatch is the silent killer. Verify with a different salt, a different length, or a different iteration count and you get false with zero explanation - the node has no way to tell you "these parameters don't match the key." Also, do not use this node to check a Fernet key or an AES key; Argon2id is its own scheme, and the BYTESLIKE ports won't stop you from wiring the wrong thing in. Finally, mode - if you derived in PHC format but verify with mode on (raw bytes), the comparison fails even for the correct passphrase.

Installing it

Same pack, same drill:

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

Restart and find it under ARG Toolkit → Cryptography → Modern → Key Derivation, or install via ComfyUI Manager (search "ComfyUI ARG Toolkit"). Backed by cryptography; no models, no downloads.

Troubleshooting

• Everything verifies as false → parameters don't match the original derivation. Salt, length, mode, iterations - check them all before blaming the node.
• Works in Derive, fails in Verify → you changed a parameter between the two, or the expected_key came from a different salt.
• Output won't connect downstream → it's a BOOLEAN, not a string; route it into a boolean-aware node or convert with the pack's utility nodes if you need text.

If Argon2id_Derive is the lock's making, this is the lock's checking - and getting a true out of it is a genuinely satisfying moment for whoever cracks your puzzle.