Scrypt is the password hash you reach for when PBKDF2 isn't enough, and the most common reason PBKDF2 isn't enough is that an attacker with a stack of GPUs can compute 100,000 PBKDF2-HMAC-SHA256 hashes per second for almost no electricity. Scrypt is designed to make that attack expensive by forcing the hash to touch a lot of memory, which GPUs and ASICs have less of than they have arithmetic units. A single Scrypt hash at the recommended parameters takes about 100x as much memory as a single PBKDF2 hash. That is the entire point of the algorithm. It is also the entire reason the cost knob is a four-number tuple instead of a single iteration count.
The Scrypt Generator on Elysia Tools turns a password and a salt into a Scrypt hash with the exact (N, r, p, dkLen) you specify, encoded in the same PHC string format your authentication library already parses. Knowing which of the four numbers does what is the difference between a hash that resists an offline attack and one that folds in seconds once the database leaks.
The Four Numbers Inside Every Scrypt Hash
Scrypt hashes, like PBKDF2 hashes, are not opaque blobs. They are ASCII strings. The PHC format Scrypt uses is:
$scrypt$ln(N)=14,r=8,p=1$saltB64$hashB64
Four numbers live in that string, in order. The first is the cost factor N, the CPU/memory knob, expressed as log base 2: ln(N)=14 means N=16384. The second is r, the block size, which controls how much memory each hash touches. The third is p, the parallelization factor, which controls how many independent hash flows run at once. The fourth is the length of the derived key dkLen, which is 32 bytes for almost every production deployment. None of the four are optional. None of them can be silently substituted. The validator reads them in order and the generator writes them in order.
What tends to break in production is not the password. It is the (N, r, p) triple, because the three numbers interact. Doubling N quadruples the memory cost. Doubling r also quadruples the memory cost. Doubling p only doubles the CPU cost, not the memory cost. If you tune one without re-checking the others, you can ship a hash that the generator is happy to write and the validator refuses to read. The Scrypt Generator enforces the rules from RFC 7914 directly: N must be a power of 2, must be at least 1024, and must not exceed 1048576; r must be a positive integer; p must be a positive integer; dkLen must be a positive integer not larger than the available output length. If any of those fail, the generator returns a clear error before hashing.
Why N Is the Only Knob You Want to Turn
N controls the memory cost, and memory cost is the entire reason Scrypt exists. PBKDF2 is CPU-hard: a single hash touches a few kilobytes of memory and spends most of its time on arithmetic. A GPU has thousands of arithmetic units and the hash runs in parallel. Scrypt is memory-hard: a single hash at N=16384 touches about 16 megabytes of memory and the algorithm is structured so that the early parts of the hash have to be held in memory while the late parts are computed. A GPU with 16 GB of VRAM can run maybe a thousand parallel Scrypt hashes at that setting. A GPU with 16 GB of VRAM can run hundreds of thousands of parallel PBKDF2 hashes at the same electricity cost. That ratio is the cost gap Scrypt is designed to widen.
The OWASP 2023 recommendation for new deployments is N=131072, r=8, p=1, with the understanding that login latency at that setting is about 100ms on commodity server hardware. The library defaults baked into most languages are an order of magnitude lower than that, because the defaults were set in 2009 when 100ms was considered unacceptable. They are no longer considered unacceptable, and the defaults are no longer safe. If your auth library emits $scrypt$ln(N)=14,r=8,p=1$... with N=16384, every user in your database is hashed at a setting an attacker with a 2024 GPU can chew through at thousands of attempts per second. Doubling N to 15 (N=32768) doubles the cost. Doubling N to 17 (N=131072) doubles it twice more. The right pattern is to pick N for the latency you can tolerate, leave r at 8, leave p at 1, and store dkLen at 32. The 4-tuple (N, r, p, dkLen) then becomes a property of the stored hash, not a property of your server config, and every validator that reads the hash honors the parameters the hash was actually written with.
If you are migrating a user table from PBKDF2 or bcrypt, the Scrypt Generator is the right tool to compute the new hashes on first login, after the user successfully types their old password. Re-hash on first successful authentication, store the new hash alongside the old one, mark the old hash for deletion after a grace period. This pattern is called transparent rehashing and it is the only way to migrate a password database without forcing every user through a password-reset email.
When r and p Matter More Than N
r and p are the two knobs that almost nobody tunes, and the two knobs that almost every production misconfiguration gets wrong. r is the block size, in 1024-byte units, that the SMix function uses internally. The memory cost of a single Scrypt hash is roughly 128*r*N bytes, so r=1 with N=131072 costs about 16 MB, and r=8 with N=131072 costs about 128 MB. The 128 MB variant is genuinely hard to compute on a GPU, but it is also genuinely hard to compute on a server under load. Most deployments keep r at 8 (the RFC 7914 default) and accept the 128 MB cost as the price of memory-hardness. Going below r=8 to save memory is almost always wrong: it weakens the algorithm's memory-hardness property faster than it saves RAM.
p is the parallelization factor, the number of independent hash flows the algorithm runs concurrently. The cost of a single hash in CPU time is roughly p*N*r operations, so doubling p doubles the wall-clock cost without doubling the memory cost. The 4-tuple that shows up in production is (N=16384, r=8, p=1) for low-cost environments and (N=131072, r=8, p=1) for high-security environments. p greater than 1 is rare and almost always wrong: it makes a single hash faster, which is what the attacker wants, not what the defender wants. The one legitimate use of p>1 is a multi-core server that wants to amortize the wall-clock cost of login across threads, and even then only when N is so high that a single-core hash exceeds the latency budget.
The 4-tuple is the contract. The Scrypt Generator emits the same string your auth library parses, and the Scrypt Validator on Elysia Tools reads the same string your auth library writes. The PHC format is the lingua franca, and once you have the (N, r, p, dkLen) numbers right at hashing time, every validator that speaks PHC will agree with every other one, including the one in your auth library and the one in your security audit script.
Where Scrypt Fits in the 2026 Password Hash Stack
Scrypt is the right choice for new deployments where memory-hardness matters and you can absorb the 100ms login latency. It is the wrong choice when you need FIPS 140-2 certification (it is not in FIPS; only PBKDF2 is) or when you are constrained to a single-threaded verification path (the algorithm is intrinsically parallelizable, which some legacy auth shims do not handle). For FIPS-bound deployments, PBKDF2 is still the right tool, at 600,000 iterations for SHA256. For conservative new deployments where you want one knob and 30 years of production track record, bcrypt is the right tool, with cost=12. Scrypt is the pick when memory-hardness is on the threat model and you can write a 4-tuple.
For generating a fresh Scrypt hash at the right (N, r, p, dkLen), the Scrypt Generator on Elysia Tools is the fastest path: no install, no library, no config file. For verifying a stored Scrypt hash against a candidate password, the matching Scrypt Validator reads the PHC string and tells you yes or no. For the broader picture of what a strong password hash actually looks like in 2026, the full Cryptography collection walks through bcrypt, scrypt, and PBKDF2 side by side.
