Memory-hard scrypt

Ethereum Keystore scrypt — Hashcat Mode 15500

TL;DR — Modern Ethereum keystores default to scrypt KDF with the same parameters as the 2014 pre-sale wallet (N=262144, r=8, p=1) — about 256MB RAM per attempt. Mode 15500 in Hashcat. Recovery is meaningfully slower than the PBKDF2 variant; password strength is the binding constraint.

Why scrypt?

scrypt's memory-hardness throttles GPU parallelism. While GPUs can compute SHA-256 at billions per second, scrypt's RAM requirement limits throughput to thousands per second per card.

This was a deliberate choice in geth 1.6+ to slow brute force without affecting legitimate users (legitimate user has only one password to try per file).

Recovery realism

Significantly slower per-password than PBKDF2 keystores. Multi-GPU recovery is feasible for typical 8-10 character passwords; 12+ character random passwords are typically not recoverable on reasonable budgets.

Same fundamental advice: tell us what you remember about the password, run a free check, decide on paid attempt based on signal.

Frequently Asked Questions

How does this compare to mode 15700 (presale)?
Same scrypt parameters, slightly different verifier path. Recovery characteristics are similar.
Can I switch a scrypt keystore to PBKDF2?
Only by decrypting first (which requires the password) then re-encrypting with different parameters. Recovery first, then optionally re-encrypt.

Related references

Have a wallet to recover?

Start with a free analysis. Encryption format is detected, free check runs first. Pay only if recovery succeeds.

Run a free wallet analysis