Derive keys using scrypt with configurable N, r, p parameters. Visualize memory-hardness and compare with PBKDF2.
scrypt turns a password and a salt into a fixed-length key, and the parameters N, r, and p set the price of that derivation: they fix how much memory the computation must touch, not just how long it runs. This tool computes the key in your browser, prints it as hex, draws the working-memory figure (128 x N x r bytes) so you can see the cost, and runs the same inputs through PBKDF2 for comparison. The surprise: the parameters are part of the key. Change N, r, p, or dkLen after the fact and the old key can never be regenerated.
A concrete input and expected output from the current implementation.
Input
password: pleaseletmein, salt: SodiumChloride, N: 16384, r: 8, p: 1, key length: 64 bytes
Expected output
7023bdcb3afd7348461c06cd81fd38ebfda8fbba904f8e3ea9b543f6545da1f2d5432955613f0fcf62d49705242a9af9e61e85dc0d651e40dfcf017b45575887 (128 hex characters; the tool also reports 16 MiB working memory for these parameters)
This input is one of the published test vectors in RFC 7914, so any conforming scrypt implementation must return exactly these 64 bytes; matching this value confirms the tool agrees with your own library. The working memory is 128 x 16384 x 8 = 16,777,216 bytes, which is 16 MiB.
scrypt first expands the password and salt through PBKDF2-HMAC-SHA256 into blocks, then runs each through ROMix: fill an array of N blocks (each 128 x r bytes), then read it back in an order dictated by the previous block's content. Later reads depend on earlier writes, so an attacker cannot trade memory for speed - hold the whole array or redo the work. The array is 128 x N x r bytes.
The tool prints the derived key as hex, shows the working-memory figure (128 x N x r bytes) for the parameters you set, and runs the same password and salt through PBKDF2 at your chosen iteration count for comparison, so the memory-hard versus CPU-only difference is visible side by side. Both derivations are deterministic: identical inputs produce identical keys in any conforming implementation, and nothing you type leaves the browser.
Yes, byte for byte, for identical inputs. RFC 7914 defines scrypt exactly, and conforming implementations - Python's hashlib.scrypt, Node's crypto.scrypt, OpenSSL - agree with each other and with this tool. If a library's output differs, compare the salt first: mismatched salt encoding (string versus raw bytes) or key length is the usual cause.
It depends on what you are protecting and what hardware must run it. RFC 7914 suggests N=2^14, r=8, p=1 (about 16 MiB) for interactive logins and N=2^20, r=8, p=1 (about 1 GiB) for file encryption. A common rule of thumb is to raise parameters until derivation takes about a second on your slowest supported device. Whatever you choose, fix it: parameters are permanently bound to every key derived with them.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.