About

The scrypt key derivation function, designed by Colin Percival in 2009, is deliberately memory-hard. Unlike bcrypt or PBKDF2, scrypt forces attackers to allocate large blocks of RAM proportional to the cost parameter N, making GPU and ASIC-based brute-force attacks economically impractical. A misconfigured N (below 2¹⁴) or a weak salt leaves your stored credentials vulnerable to offline dictionary attacks. This tool parses the hash string, extracts parameters N, r, p, and salt, then re-derives the key from your plaintext input entirely in the browser. No data leaves your machine.

Supported formats include Colin Percival's original $s0$ encoding, the Modular Crypt Format $scrypt$ variant, and raw parameter specifications with hex or base64 salt and hash. The tool approximates memory usage as 128 × N × r bytes. For N = 2¹⁴ and r = 8, that is 16 MB of working memory per hash computation. High values of N (above 2²⁰) may cause browser tab crashes on low-memory devices.

Formulas

The scrypt function derives a key from a password and salt through a chain of three sub-algorithms. The top-level call is:

DK = scrypt(P, S, N, r, p, dkLen)

Where P = password bytes, S = salt bytes, N = CPU/memory cost (must be a power of 2), r = block size, p = parallelization factor, dkLen = desired key length in bytes.

Step 1: Generate an initial block array B via PBKDF2:

B = PBKDF2-HMAC-SHA256(P, S, 1, p × 128 × r)

Step 2: For each parallelism lane i from 0 to p − 1, apply the memory-hard ROMix to a 128r-byte block:

B_i = ROMix(B_i, N)

ROMix builds an array V of N snapshots, each 128r bytes, then performs N random lookups into V using BlockMix. This forces 128 × N × r bytes of memory allocation.

Step 3: Derive the final key from the mixed blocks:

DK = PBKDF2-HMAC-SHA256(P, B, 1, dkLen)

Verification succeeds when the derived DK equals the stored hash bytes in constant-time comparison.

Reference Data

Parameter	Symbol	Typical Range	Default (Percival 2009)	OWASP 2023 Minimum	Effect
CPU/Memory Cost	N	2¹⁴ - 2²⁰	2¹⁴ (16384)	2¹⁷ (131072)	Memory usage & iterations; must be power of 2
Block Size	r	1 - 16	8	8	Increases sequential memory access per block
Parallelism	p	1 - 16	1	1	Independent mixing lanes (multiplies CPU time)
Salt Length	-	16 - 32 bytes	32 bytes	16 bytes min	Prevents rainbow table attacks
Derived Key Length	dkLen	32 - 64 bytes	32 bytes	32 bytes	Output hash length
Memory per hash (N=2¹⁴, r=8)	-	-	16 MB	-	RAM allocated during computation
Memory per hash (N=2¹⁷, r=8)	-	-	128 MB	-	RAM allocated during computation
Memory per hash (N=2²⁰, r=8)	-	-	1 GB	-	May crash browser tabs
Hash Format: $s0$	-	`$s0$PARAMS$SALT_BASE64$HASH_BASE64` - Percival’s original encoding. PARAMS is hex-encoded log2(N), r, p.
Hash Format: $scrypt$ (MCF)	-	`$scrypt$ln=LOGN,r=R,p=P$SALT_BASE64$HASH_BASE64` - Modular Crypt Format variant.
Hash Format: Raw	-	Manual entry: N, r, p, salt (hex/base64), hash (hex/base64). No standard string.
Underlying PRF	-	PBKDF2-HMAC-SHA-256 with c = 1 iteration
Core Mixing	-	Salsa20/8 applied inside BlockMix / ROMix

Frequently Asked Questions

Scrypt is intentionally slow. The cost parameter N controls how many 128·r-byte blocks are stored in RAM and then randomly accessed. At N = 2^14 and r = 8, the algorithm allocates 16 MB and performs 16384 sequential Salsa20/8 mixes plus 16384 random lookups. This is by design - it makes brute-force attacks on stolen hashes prohibitively expensive. Higher N values increase time linearly.

Three formats are supported. (1) Percival's $s0$ format: $s0$e0801$SALT_BASE64$HASH_BASE64 where the hex string e0801 encodes log2(N)=14, r=8, p=1. (2) MCF $scrypt$ format: $scrypt$ln=14,r=8,p=1$SALT$HASH with explicit named parameters. (3) Raw mode: you manually enter N, r, p, plus the salt and hash as hex or base64 strings. The tool auto-detects format (1) and (2) from the $ delimiters.

The params field is a hex string. For the standard 6-character encoding: the first two hex characters give log2(N), the next two give r, the last two give p. For example, "e0801" is parsed as: byte 0 = 0x0e = 14, so N = 2^14 = 16384; byte 1 = 0x08 = 8, so r = 8; byte 2 = 0x01 = 1, so p = 1. Some implementations use a 5-character or padded variant; this tool handles both.

Yes. At N = 2^20 with r = 8, the algorithm needs roughly 1 GB of contiguous memory. Most browsers limit a single tab or Web Worker to 1-4 GB. The tool warns you when estimated memory exceeds 256 MB and will refuse to run computations requiring more than 1 GB to prevent tab crashes. If you need to verify such hashes, use a native CLI tool like "openssl" or the reference "scrypt" utility.

No. The entire scrypt computation runs inside a Web Worker in your browser. No network requests are made. You can verify this by disconnecting from the internet before clicking Verify. The password bytes exist only in JavaScript memory and are discarded after the derived key is compared.

Salsa20/8 is a reduced-round (8 of 20) version of the Salsa20 stream cipher core. It is used as the mixing function inside BlockMix. Each 64-byte block is XORed with the previous block's output, then passed through Salsa20/8 to produce pseudo-random data. The /8 variant is chosen because full Salsa20 would be unnecessarily slow for a KDF - 8 rounds provide sufficient diffusion for the memory-hardness goal without wasting cycles.

After deriving the key, the tool compares it byte-by-byte against the stored hash, always examining every byte regardless of mismatches. A naive comparison that exits early on the first differing byte leaks timing information - an attacker measuring response times could infer how many leading bytes match. Constant-time comparison iterates all bytes and ORs differences into an accumulator, returning match/no-match only after the full loop.