🔐 Scrypt Generator

🎯 Mode

🔑 Password

⚙️ Scrypt Parameters

N (Cost Factor) - Must be power of 2

r (Block Size)

p (Parallelization)

Hash Length (bytes)

{{ length }} bytes

Use Custom Salt

🔄 Random salt will be generated automatically

Estimated Memory Usage: {{ getMemoryUsage() }}MB

🔍 Scrypt Hash to Verify

🔐 Generated Hashes

Hex Hash

{{ result.hash }}

Base64 Hash

{{ result.base64Hash }}

Formatted Hash (with parameters)

{{ result.formattedHash }}

Algorithm: Scrypt

N: {{ result.parameters.N?.toLocaleString() }}

r: {{ result.parameters.r }}

p: {{ result.parameters.p }}

Length: {{ result.parameters.length }} bytes

Salt: {{ result.salt }} ({{ result.saltLength }} chars)

{{ verifyResult.verified ?'✅' :'❌' }} {{ verifyResult.verified ?'Password Valid!' :'Password Invalid!' }}

N: {{ verifyResult.info.N?.toLocaleString() }}

r: {{ verifyResult.info.r }}

p: {{ verifyResult.info.p }}

Length: {{ verifyResult.info.length }} bytes

Salt: {{ verifyResult.info.salt }} ({{ verifyResult.info.saltLength }} chars)

Error: {{ verifyResult.error }}

🔬 Security Analysis

Security Level: {{ getSecurityInfo().level }}

Security Score: {{ getSecurityInfo().score }}/{{ getSecurityInfo().maxScore }}

Memory Usage: {{ getSecurityInfo().memoryUsageMB }}MB

Total Operations: {{ getSecurityInfo().totalOperations?.toLocaleString() }}

Est. Computation Time: {{ formatTime(getSecurityInfo().estimatedTimeMs) }}

Security Notes:

{{ note }}

🧪 Examples

💡 Security Tips

Use N=32768+ for production applications (higher N = more security)
N parameter must be a power of 2 (2048, 4096, 8192, etc.)
Higher memory usage makes hardware attacks more expensive
Test performance on your production hardware before deployment
Consider using Argon2 for new applications (more modern)
Store the complete formatted hash including all parameters

⚠️

ℹ️ About Scrypt Generator

Scrypt is a password-based key derivation function for turning a password and salt into a slow, memory-hard password hash. It was designed by Colin Percival to make large-scale cracking more expensive by requiring both CPU work and RAM, documented in the original scrypt paper, and standardized for password-based key derivation in RFC 7914.

Use this scrypt hash generator when you need test hashes for account-storage code, a way to verify a stored scrypt password hash, or a quick comparison of how the N, r, and p parameters change memory cost. For production authentication systems, follow current password-storage guidance such as the OWASP Password Storage Cheat Sheet and NIST SP 800-63B: store a unique random salt per password, use a vetted library, and tune parameters on the deployment hardware.

Common scrypt use cases:

Password hash generation: create salted hashes for integration tests, fixtures, and storage-format checks.
Password verification: compare a candidate password with a formatted scrypt hash without exposing the original password.
Parameter tuning: estimate the memory cost of N, r, and p before choosing settings for an application.
Key derivation research: compare scrypt with Argon2, bcrypt, and PBKDF2 for password-hardening tradeoffs.

Parameters and examples:

N (cost factor): CPU and memory cost. It must be a power of two, such as 16384, 32768, or 65536.
r (block size): memory block-size parameter. A common starting value is 8.
p (parallelization): independent mixing count. Higher values add work but do not increase the core memory cost as directly as N and r.
Memory estimate: scrypt uses approximately 128 * N * r bytes, so N=32768, r=8 is about 32 MB.
Formatted output: this tool emits strings like $scrypt$N=32768,r=8,p=1$hexSalt$base64Hash for verification in this page.

Password-hashing strength ratings:

Argon2id: excellent modern default when available; standardized in RFC 9106.
Scrypt: strong memory-hard choice when parameters are tuned high enough and a reputable implementation is used.
Bcrypt: strong legacy password hash, but limited by its older design and password-length behavior.
PBKDF2: acceptable for compatibility, especially where standards require it, but less resistant to GPU/ASIC cracking than memory-hard KDFs.
Fast hashes: SHA-256, SHA-512, MD5, and NTLM are not password-storage algorithms by themselves.

Limitations and safety notes:

Do not reuse salts. Generate a fresh random salt for every password.
Do not choose parameters only from a blog post; benchmark login latency and memory pressure on your actual server class.
Do not assume every library accepts the same serialized hash string. Many ecosystems use PHC-style or library-specific formats.
Do not use scrypt hashes for message integrity or file checksums. Use HMAC, SHA-256, or a file-hash tool for those jobs.

API Usage Example:

POST /api/tools/crypto/scrypt
Content-Type: application/json

{
    "password": "mySecretPassword123",
    "N": 32768,
    "r": 8,
    "p": 1,
    "length": 32,
    "salt": null
}