Scrypt exists because of a one-person backup company. Colin Percival, a Canadian FreeBSD security officer, designed it in 2009 for Tarsnap, his own "online backups for the truly paranoid" service — he needed to derive strong encryption keys from user passwords and didn't trust existing KDFs to resist an attacker renting cheap GPU time, so he built one that was deliberately expensive in RAM as well as CPU cycles.
What a memory-hard function is
A memory-hard algorithm is deliberately designed so that computing a single hash requires holding a large amount of intermediate data in memory. Trying to save memory at the cost of recomputing values instead sharply increases computation time — meaning an attacker has to sacrifice either memory or speed, exactly the property Percival wanted for Tarsnap's key derivation.
Why this makes attacks on specialized hardware harder
ASIC chips and GPUs are very efficient at massively parallel execution of simple arithmetic operations, but adding memory to each parallel computation thread costs far more and scales worse. Scrypt makes a brute-force attack on such hardware economically less attractive compared to classic hash functions — a design goal that succeeded well enough to get scrypt formalized as RFC 7914 in 2016.
Why you'd need this
- Choosing a password hashing algorithm resistant to GPU farm attacks.
- Understanding the concept of memory-hard functions in a cryptography context.
- Comparing the tradeoffs of scrypt versus bcrypt and Argon2 for a specific system.
How much memory is actually needed
The memory required for a single scrypt computation is approximately 128 × N × r bytes. With typical parameters (N=16384, r=8) that's about 16 megabytes per hash — negligible for a single login, but if a server needs to handle thousands of concurrent authentications, the total memory footprint quickly becomes a real constraint when choosing parameters, not just an abstract security requirement.