Scrypt Key Verification

If Scrypt_Derive is the lock, this node is the lock tester. It takes a passphrase, derives the scrypt key the same way, and tells you - as a plain boolean - whether the result matches a key you already have. In ARG terms: the player types in a password, and this node decides whether the door opens.

What makes it interesting is why you'd verify this way instead of just deriving and comparing. Deriving twice and comparing two byte strings works fine on paper, but comparing byte strings leaks timing information, and sloppy comparison is exactly how side-channel attacks happen. Scrypt_Verify calls scrypt's own verify() method, which does a constant-time comparison under the hood. For a puzzle where the "secrets" are game content that's arguably overkill - but it's the right habit, and it means the node is ready for the day you use it on something that actually needs protecting.

How it works

This node shares Scrypt_Derive's entire input set - message (passphrase), salt, length, and the scrypt cost parameters n, r, p - and adds one more:

• expected_key - the derived key you're testing against, as bytes.

It derives a key from the message with the same parameters, verifies it against expected_key, and returns verified_status (BOOLEAN): true if it matches, false if it doesn't. Remember that n is a power exponent here: n=14 means 2**14, and you must use the exact same n/r/p/length/salt that produced the original key, or the check fails even with the right passphrase.

The gotcha that bites everyone

The parameters aren't stored in the output. If you derived a key with n=15 and then verify with n=14, verification returns false on a correct passphrase - silently. Save the salt and parameters alongside the expected key, or you'll spend an evening convinced the node is broken when it's actually just picky about matching settings. Also, expected_key and message must both be bytes; the pack's string converters are the usual bridge for human-typed input.

Where it fits in a workflow

Wire verified_status into a switch or a conditional that only reveals the next step (decrypt, decode, show a URL) when it's true. It's a clean "gate" node, and it's one of the nicer bits of the pack's modern-crypto corner because the boolean output makes it dead simple to reason about.

Installing it

Part of ComfyUI ARG Toolkit - install via ComfyUI Manager (search "ComfyUI ARG Toolkit") or:

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

Restart ComfyUI. The pack's Python deps (cryptography, secretpy, stegano, reedsolo) come along via Manager; there are no model files. If nodes are missing, check the console log and run pip install -r requirements.txt inside the pack folder.

Common issues

• False on a correct passphrase - parameter or salt mismatch between derive and verify, almost always.
• Bytes errors - plain strings won't work; convert them.
• It's a "modern crypto" node from a pack whose author admits tests cover common cases only, so verify with the same settings you derived with and you'll be fine.