Scrypt Key Derivation

Most of the "modern" nodes in the ARG Toolkit ask for a key as raw bytes, and if you're making an ARG you probably don't want to hand your solver a 32-byte key blob. You want them to have a word or a phrase. This node is the bridge: it runs your passphrase through scrypt, a deliberately slow, memory-hungry key derivation function, and spits out a fixed-length key you can feed straight into SymmetricEncryptDecrypt.

Scrypt exists because passphrases are low-entropy and fast hashes let attackers try millions per second. Scrypt makes that expensive - it eats both CPU and RAM, which is what stops GPU brute-force. If you've heard of Argon2, it's the same idea and both are a generation above PBKDF2 for password use. The name comes from the Linux scrypt command, but the real security wall is the parameters.

How it works

Scrypt derives a key from message (your passphrase) plus a salt, then applies the memory-hard mixing loop. All the knobs here are the scrypt cost parameters:

• n - the CPU/memory cost. Important quirk: this node takes n as a power exponent, not the raw value. Default 14 means 2**14 = 16384, so each increment doubles the work. The tooltip spells this out, and it's easy to miss.
• r - block size, affects memory access patterns. Leave it at 8.
• p - parallel factor. Bumping it helps on multicore, but also helps attackers with parallel hardware, so default 1 is fine for most use.
• length - output key length in bytes, default 32 (a 256-bit key, what AES-256 wants). Step of 16.
• salt - the salt, as bytes. This is where the pack's SystemRandom node comes in: generate 16+ random bytes and wire them in here.

The message input must be bytes, so for a human-typed passphrase you'll feed it through one of the pack's string-to-bytes converters first.

The inputs that actually matter

For your first workflow you only touch three things: message (the passphrase), salt (from SystemRandom), and length (32). Leave n, r, p alone until you have a reason not to - scrypt at the defaults already takes a visible moment on every queue run, which is the point.

Output is a single derived_key (BYTESLIKE). Wire it into the key input of SymmetricEncryptDecrypt and you're encrypting with a key derived from something a human can actually remember.

Installing it

This ships as part of ComfyUI ARG Toolkit - search that name in ComfyUI Manager, or clone it by hand:

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

Restart ComfyUI. Manager pulls in the Python deps (cryptography, secretpy, stegano, reedsolo). No model files, no GPU requirement beyond ComfyUI itself. If the nodes don't appear, check the terminal you launched ComfyUI from for a traceback, then run pip install -r requirements.txt inside the pack folder.

Common issues

• Same passphrase, different key every run? Your salt changed. Salt is random by design - store it alongside the ciphertext, because you'll need it (and the exact same length/n/r/p) to derive the same key again.
• "Must be bytes" errors mean you fed the node a plain string. Route the text through the pack's string-to-bytes node first.
• The author is upfront that this is an amateur project whose tests cover common use cases only, so don't reach for the exotic parameter combos to save time - the defaults exist for a reason.