Argon2 vs Scrypt
In-Depth Technical Comparison & Architecture Guide
Argon2 and Scrypt are both memory-hard — the defining property that separates them from Bcrypt (see Bcrypt vs Scrypt) — but Argon2 refines the idea with a hybrid access pattern specifically designed to resist both GPU cracking and side-channel timing attacks simultaneously, something plain Scrypt's single access pattern can't do at once.
Quick Reference Matrix
| Feature | Argon2id | Scrypt |
|---|---|---|
| Year Published | 2015 | 2009 |
| Standard | RFC 9106 | RFC 7914 |
| Selection Process | Password Hashing Competition winner | Original design by Colin Percival |
| Memory Access Pattern | Hybrid: data-independent then data-dependent | Data-dependent only |
| Side-Channel (Timing) Resistance | Yes, via first-pass data-independence | No — single data-dependent pattern throughout |
| GPU/ASIC Resistance | High | High |
| Tuning Parameters | Memory cost, time cost, parallelism | N (cost), r (block size), p (parallelism) |
| Current Default Recommendation | Yes — OWASP/RFC 9106 recommended default | Legitimate, but superseded as the default recommendation |
Technology Overview
Scrypt, published by Colin Percival in 2009 and standardized as RFC 7914, was the first widely-adopted password hashing construction to deliberately require large amounts of memory, not just CPU time, to compute — directly countering the custom-hardware cracking risk that algorithms like Bcrypt (with a fixed, tiny memory footprint) are exposed to. Scrypt's memory access pattern is entirely data-dependent: which memory locations get read and written is determined by the password being hashed itself.
Argon2, published in 2015 by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich, won the Password Hashing Competition (PHC) — an open, multi-year public cryptographic competition specifically organized to select a successor to Bcrypt and Scrypt — and was later formalized as the IETF's recommended password hashing algorithm in RFC 9106. Argon2 comes in three variants (Argon2i, Argon2d, Argon2id), and this distinction is the crux of how it improves on Scrypt: Argon2d uses the same data-dependent access pattern as Scrypt (strong against GPU/ASIC cracking, but theoretically exposed to cache-timing side-channel attacks by an attacker with low-level access to the hashing machine itself), while Argon2i uses a data-independent pattern (immune to that side-channel risk, but historically weaker against pure memory-hardness attacks). Argon2id, the variant RFC 9106 recommends as the default, is a hybrid: data-independent for its first pass over memory, then data-dependent for subsequent passes — combining both properties rather than forcing a choice between them.
This is exactly the property plain Scrypt cannot offer: because Scrypt has only one access pattern (data-dependent, functionally similar to Argon2d alone), it has no equivalent hybrid option, and no built-in way to add the timing-attack resistance Argon2id's first pass provides.
Data-Dependent vs Data-Independent Memory Access
A cache-timing side-channel attack works by an attacker (typically one with some form of local access to the machine performing the hashing, such as a co-located process or a compromised container neighbor) measuring how long specific memory accesses take, and using that timing information to infer something about the secret input — in this case, the password being hashed.
Scrypt's single, data-dependent access pattern means the exact sequence of memory reads is determined by the password itself, which is precisely what a timing side-channel attack tries to exploit. Argon2d shares this same theoretical exposure. Argon2i avoids it entirely by using a memory access sequence that's fixed in advance, independent of the password — but that predictability is also what makes pure Argon2i comparatively weaker against brute-force cracking optimizations than the data-dependent variants.
Argon2id's hybrid design is the practical answer: its first pass over memory uses data-independent access (closing the side-channel window for that portion of the computation), and its remaining passes use data-dependent access (preserving strong GPU/ASIC resistance for the bulk of the work). This is why RFC 9106 and OWASP both recommend Argon2id specifically, rather than either pure variant, as the default choice for password storage.
Tuning Parameters: Three Dimensions vs Three Dimensions
Both algorithms expose three tunable parameters, but they map to different underlying tradeoffs. Scrypt's parameters are N (a CPU/memory cost factor, required to be a power of two), r (block size, affecting memory bandwidth), and p (parallelization).
Argon2's parameters are more directly named for what they control: memory cost (m, the size of the memory buffer in KiB), time cost (t, the number of passes over that memory), and parallelism (p, the number of independent lanes/threads). RFC 9106 provides concrete recommended baseline configurations (for example, a common baseline is roughly 19 MiB of memory, 2 iterations, and 1 degree of parallelism for the id variant), giving implementers a documented, industry-vetted starting point that Scrypt's own RFC provides less explicitly.
In practice, Argon2's parameter names map more directly and legibly onto server capacity planning (how much RAM per login, how many CPU passes) than Scrypt's more abstract N/r/p notation, which is one reason Argon2id has become the more commonly recommended default in current security guidance.
Standards Status and Current Industry Recommendation
Scrypt is standardized as RFC 7914 (an IETF Informational RFC). Argon2 is standardized as RFC 9106, and — significantly — was selected through the Password Hashing Competition, an open process specifically designed to publicly vet and stress-test candidate algorithms against expert cryptanalysis before recommending one, giving it a somewhat more rigorously adversarial-tested pedigree specific to the password-hashing use case.
Current guidance from OWASP, NIST-adjacent industry practice, and RFC 9106 itself converges on Argon2id as the recommended default for any new system with no specific legacy constraint. Scrypt remains a legitimate, still-secure choice, particularly in codebases and platforms where it's already established (including several cryptocurrency and key-derivation contexts that adopted it early, before Argon2 existed).
Argon2id Advantages & Disadvantages
Advantages / Pros
- Hybrid access pattern defends against both side-channel timing attacks and GPU/ASIC cracking simultaneously.
- Selected through the open, adversarially-tested Password Hashing Competition.
- Current default recommendation from RFC 9106 and OWASP, with well-documented baseline configurations.
Disadvantages / Cons
- Newer than Scrypt, with a somewhat shorter real-world deployment track record.
- Native library bindings can occasionally be trickier to compile in constrained CI/CD environments than pure-language alternatives.
Scrypt Advantages & Disadvantages
Advantages / Pros
- Longer real-world track record (2009) than Argon2.
- Strong, proven memory-hardness against GPU/ASIC cracking.
- Well-established in cryptocurrency and key-derivation contexts.
Disadvantages / Cons
- Single data-dependent access pattern offers no built-in timing side-channel resistance.
- No hybrid variant equivalent to Argon2id — the tradeoff Argon2 splits, Scrypt cannot.
- No longer the default recommendation for new password-storage systems.
Real-World Use Cases
Argon2id
Any new password database in 2026
The current industry-recommended default with no specific legacy constraint pointing elsewhere.
Multi-tenant or shared-hosting environments
Where side-channel timing attacks from a co-located neighbor process are a genuine, non-theoretical concern.
Scrypt
Existing systems already standardized on Scrypt
Codebases, key-derivation flows, or cryptocurrency wallet implementations already built around it, with no specific driver to migrate.
Environments predating Argon2's ecosystem maturity
Older platforms where Scrypt was the best available memory-hard option at the time of original implementation.
Developer Recommendation
For any new system, use Argon2id. It provides everything Scrypt provides (strong memory-hardness against GPU/ASIC cracking) plus side-channel timing-attack resistance Scrypt's single access pattern cannot offer, and it's the current recommendation from RFC 9106 and OWASP.
Continue using Scrypt only where it's already deeply embedded in an existing system (a cryptocurrency wallet's key derivation, a legacy codebase) and there's no specific security driver requiring migration — it remains a legitimate, still-secure algorithm, just not the current best default for greenfield work.
If you're migrating from Bcrypt specifically (rather than choosing between these two), go straight to Argon2id rather than Scrypt as an intermediate step — see Bcrypt vs Argon2 for that direct migration path.
Frequently Asked Questions
- What's the single biggest difference between Argon2 and Scrypt?
- Argon2id's hybrid memory-access pattern — data-independent for its first pass, data-dependent afterward — defends against both side-channel timing attacks and GPU/ASIC cracking at once. Scrypt's single, purely data-dependent pattern only defends against the second, not the first.
- Is Scrypt insecure compared to Argon2?
- No — Scrypt remains cryptographically sound and provides strong memory-hardness. It's simply been superseded as the default recommendation because Argon2id closes a theoretical side-channel gap that Scrypt's design doesn't address at all.
- What does the Password Hashing Competition have to do with Argon2?
- It was a multi-year, open, public competition specifically organized to select a successor to Bcrypt and Scrypt for password hashing. Argon2 won in 2015 after public cryptanalysis from the security research community, which is part of why it carries strong current confidence as a recommendation.
- Which Argon2 variant should I actually use?
- Argon2id, for virtually all password-hashing use cases — it's the variant RFC 9106 recommends as the default, since it combines the best properties of Argon2i (side-channel resistance) and Argon2d (GPU/ASIC resistance).
- Do Scrypt and Argon2 use the same tuning parameters?
- They're conceptually similar (both control memory cost, time/iteration cost, and parallelism) but named and structured differently — Scrypt uses N/r/p, while Argon2 uses more directly-named memory cost, time cost, and parallelism values with documented RFC 9106 baseline recommendations.
- Should I migrate an existing Scrypt-based system to Argon2?
- Only if you have a specific driver to do so — a security audit finding, a compliance requirement, or a genuine multi-tenant timing-attack concern. Scrypt remains secure; migrating existing, working, correctly-configured systems purely to chase the newest algorithm isn't automatically necessary.
Part of the Hashing & Integrity Developer Hub
This comparison is part of our Hashing & Integrity topic guide, covering related tools, standards, and decision guidance.
Related Comparisons
Other technology decisions in the same topic area as Hashing & Integrity:
SHA256 vs SHA512
Cryptographic hash functions are designed to ingest arbitrary binary inputs and return a fixed-size, deterministic byte sequence called a digest. These functions must be one-way (infeasible to reverse-engineer) and collision-resistant (highly unlikely that two distinct inputs produce the same hash). In modern cryptography, the SHA-2 (Secure Hash Algorithm 2) family is the default choice for data integrity, SSL/TLS certificates, and blockchain networks. Within this family, SHA-256 and SHA-512 are the two most prominent algorithms. Surprisingly, their differences extend beyond digest length to internal block sizes, math architectures, and hardware parsing performance. This guide compares SHA-256 and SHA-512 in detail.
Bcrypt vs Scrypt
Bcrypt and Scrypt both slow down password verification deliberately, but they do it in fundamentally different ways: Bcrypt spends CPU cycles alone, while Scrypt deliberately consumes large amounts of memory alongside CPU time. That single architectural difference — memory-hardness — is the whole reason Scrypt exists, and it's the lens this comparison uses throughout.
MD5 vs SHA1 vs SHA256
MD5 and SHA-1 are both cryptographically broken — not theoretically weak, but practically broken, with real, demonstrated attacks — while SHA-256 remains secure with no known practical attack. This comparison is less about a tradeoff between three roughly-equivalent options and more about understanding exactly why two of them were retired and what, if anything, they're still safe to use for.
HMAC vs Digital Signatures
Both HMAC and digital signatures let a recipient verify a message wasn't tampered with, but they answer a different second question: HMAC only proves the message came from someone who holds a shared secret, while a digital signature proves it came from the one specific party holding a private key — and only the second property, non-repudiation, actually holds up if the sender later denies sending it.
Launch Interactive Developer Tools
Put these concepts into practice. Test, format, serialize, or analyze your inputs locally with these secure, browser-only utilities: