In 2013, a group of cryptographers led by Jean-Philippe Aumasson decided that password hashing needed a new generation of designs. The state of the art at that time was scrypt, published in 2009, plus the older bcrypt and PBKDF2. Each had limitations. scrypt's data-dependent memory access leaked information through cache timing. bcrypt was not memory-hard at all. PBKDF2 was approved by FIPS but provided only iteration-based slowdown that custom hardware could trivially accelerate.
The cryptographic community had benefited from two recent open competitions: AES (1997-2001) and SHA-3 (2007-2012). Both produced widely adopted standards through transparent public review. Aumasson and colleagues launched the Password Hashing Competition (PHC) on the same model. From 2013 to 2015, the competition collected, analyzed, and reduced submissions through three rounds. In July 2015, Argon2 was named the winner. The aftermath of that decision, including the path to RFC 9106 and OWASP's 2026 recommendations, shapes how every modern password hash works today.
This article walks through how the competition ran, why Argon2 won, what the runner-up designs offered, and what changed in the field as a result.
How the Competition Was Structured
The PHC was organized as a public competition with a panel of experienced cryptographers as judges. Submissions had to include a full specification, reference implementation, security analysis, and performance measurements. Anyone could submit; anyone could analyze submissions and publish attacks.
Round 1 (2014) received 24 submissions. Each design was evaluated for cryptographic security, resistance to GPU and ASIC attacks, side-channel resistance, simplicity, and performance.
Round 2 (early 2015) cut the field to 9 finalists. The finalists were: Argon2, Battcrypt, Catena, Lyra2, Makwa, Parallel, POMELO, Pufferfish, and Yescrypt.
Final round (mid-2015) produced the winner: Argon2, designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich at the University of Luxembourg. Four other finalists were given "special recognition": Catena, Lyra2, Makwa, and Yescrypt.
The judges' panel included Jean-Philippe Aumasson (BLAKE designer), Tony Arcieri (Cryptography researcher), Jeremi Gosney (password cracking expert), and others. The diversity of expertise (designers, attackers, deployers) made the evaluation thorough.
What the Competition Looked For
The judges' published criteria included:
Resistance to time-memory tradeoff attacks. An attacker should not be able to use less memory by spending more time, beyond a small constant factor. This was where scrypt's known weakness lived.
Resistance to side-channel attacks. Cache-timing attacks were a real concern; the function should not leak password information through memory access patterns. This was scrypt's other weakness (data-dependent access).
GPU and ASIC resistance. The function should be expensive on parallel hardware. Memory-hardness was the primary route to this.
Performance on commodity CPUs. Defenders should be able to run the function quickly on the hardware they actually deploy.
Implementation safety. The function should be hard to implement incorrectly. Side-channel-safe implementations should be straightforward.
Simplicity. Fewer moving parts means fewer bugs and easier security analysis.
Argon2 hit all of these well. It offered three variants (Argon2d, Argon2i, Argon2id) covering different use cases, used the well-studied BLAKE2b compression function, had a clear security analysis, and ran efficiently on commodity hardware.
Why Argon2 Specifically Won
The judges' final report cited several reasons.
Argon2's three-variant design (data-dependent for maximum GPU resistance, data-independent for side-channel safety, hybrid for both) gave deployers flexibility without splitting the standard.
The use of BLAKE2b as the underlying compression function was an excellent choice. BLAKE2b is fast on commodity CPUs without requiring hardware acceleration. It is well-studied and has clean security properties.
The internal data flow uses a single round of mixing per memory access, making the construction simple to analyze. Compare this to scrypt's heavier per-block computation.
The parameter set is intuitive: m for memory, t for time, p for parallelism. No power-of-two constraint like scrypt's N, no awkward block size like scrypt's r.
The security analysis included formal proofs of memory-hardness against single-pass attacks and concrete bounds on time-memory tradeoffs. Cryptographers like clean theorems.
Performance was competitive with the other finalists. Argon2id at 64 MB and 3 passes runs in about 250 ms on a modern CPU.
The Runners-Up
The four "special recognition" finalists each had merits.
Catena, designed by Christian Forler, Stefan Lucks, and Jakob Wenzel, used a more conservative tree-based memory access pattern. It was strong on side-channel resistance but slower than Argon2id at equivalent security. It is used in some niche password managers and academic research.
Lyra2, designed by a Brazilian team led by Marcos Simplicio Jr, used a sponge-based memory mixing approach. It was fast and had strong analysis but its design was more complex than Argon2's. It saw some deployment in Brazilian banking systems.
Makwa, by Thomas Pornin, took a different approach: it used a delegatable computation based on RSA, allowing servers to outsource part of the cost to clients. This was clever but did not match the deployment model of standard password hashing. It is mostly a research curiosity.
Yescrypt, designed by Alexander Peslyak (Solar Designer), is a strengthened variant of scrypt. It addresses scrypt's known weaknesses and adds features like ROM (Read-Only Memory) augmentation for additional defense. Yescrypt is used as the default password hashing in some Linux distributions (notably ALT Linux). It remains a strong choice for systems administrators familiar with scrypt-style designs.
What Changed After 2015
In the immediate aftermath of the competition, Argon2 saw rapid adoption.
The libsodium library added Argon2id as a standard primitive in 2015.
Major language ecosystems followed: Python's argon2-cffi, Rust's argon2 crate, Go's golang.org/x/crypto/argon2, Java's BouncyCastle Argon2 provider, Node.js argon2 npm package.
The PHP language standardized PASSWORD_ARGON2I and PASSWORD_ARGON2ID constants in PHP 7.2 (2017) and PHP 7.3 (2018) respectively.
Web frameworks (Django, Rails, Laravel, Spring Security) all gained Argon2id support.
In 2021, IETF RFC 9106 formally documented Argon2 as the IETF standard for password hashing. This was a major milestone: it gave Argon2 the same standardization status as scrypt's RFC 7914.
OWASP's Password Storage Cheat Sheet was updated to recommend Argon2id as the primary choice for new applications, with bcrypt and PBKDF2 as fallbacks for compatibility constraints. We cover this current state in Argon2id vs bcrypt vs scrypt: 2026 Recommendations.
NIST has signaled (through SP 800-63B drafts and other documents) intent to include Argon2 in approved password-based KDF lists, though formal FIPS approval has not yet happened as of 2026. PBKDF2 remains the only FIPS-approved password-based KDF.
Lessons from the Competition
The PHC reinforced several lessons that apply beyond password hashing.
Open competitions produce better designs. The scrutiny from public attack and analysis is irreplaceable. NIST followed this model for the post-quantum cryptography competition (2017-2024) that produced ML-KEM and ML-DSA.
Memory-hardness is a real defense, not a buzzword. The PHC analysis quantified how much it costs attackers per password guess, validating the intuition that memory is expensive on chips.
Side channels matter. Three of the nine finalists (Argon2, Catena, Lyra2) explicitly addressed side-channel resistance, often through data-independent or hybrid access patterns. This influenced subsequent cryptographic standards across the board.
Parameter clarity matters. The PHC submissions varied in how clear their parameters were. The clearer designs (Argon2, Yescrypt) saw faster adoption than the more abstruse ones.
A specific compression function is fine. Argon2 chose BLAKE2b; others chose Keccak (the SHA-3 permutation), Salsa20, or AES round functions. Each is fine; the differences were performance and audit familiarity.
What the Competition Did Not Settle
Hardware accelerators for password cracking. The PHC analysis assumed commodity GPUs and FPGAs. ASICs purpose-built for Argon2 are technically possible. The economics depend on what passwords are worth cracking; Bitcoin-scale economics could make even Argon2 ASICs viable.
Quantum attacks. The PHC predates the post-quantum standards push. Argon2 and the other finalists were not specifically designed for quantum resistance. As we noted in Argon2id vs bcrypt vs scrypt, the main quantum impact on password hashing is Grover's algorithm halving effective password entropy, not breaking the function.
Long-term parameter inflation. The PHC submissions assumed a defender latency of about 1 second. In 2026, deployment-ready parameters are still in the 100-500 ms range, balancing security against login experience. The right ceiling continues to be debated.
ROM and pepper schemes. Yescrypt's ROM design (a large read-only table baked into the algorithm) was not adopted by Argon2id. Some operators add a server-side pepper (a secret in an HSM, applied before or after Argon2id) for defense in depth. Best practices for pepper handling are still maturing.
FIPS approval. NIST has not approved Argon2 as of 2026. PBKDF2 remains the only FIPS-approved password-based KDF. Federal and regulated systems often must use PBKDF2 even when Argon2id would be technically stronger.
Argon2 Variants in Detail
The three variants of Argon2 differ in memory access pattern.
Argon2d (data-dependent) accesses memory in a pattern determined by the password and intermediate state. Maximum GPU resistance. Vulnerable to cache-timing side channels if attackers can run code on the same CPU.
Argon2i (data-independent) accesses memory in a fixed, password-independent pattern. Side-channel safe. Slightly weaker against time-memory tradeoff attacks: an attacker can store every other memory block and recompute the missing ones with about 2x time, while Argon2d would force a much larger time blowup.
Argon2id (hybrid) uses Argon2i in the first half-pass and Argon2d in the second. The first pass establishes a memory state that is hard to predict; the second pass uses data-dependent access to maximize cracking cost.
For password hashing on a server (where side channels exist), use Argon2id.
For client-side password derivation in trusted environments (e.g., a password manager running locally), Argon2d gives the strongest cracking resistance.
For environments where side channels are the primary threat (e.g., shared cloud servers running multiple tenants on the same CPU), Argon2i provides the cleanest analysis.
In practice, Argon2id is the right default for nearly all use cases.
Frequently Asked Questions
Why was scrypt not just upgraded?
scrypt's design is fundamentally tied to its parameters. Adding side-channel resistance would require changing the memory access pattern, which would change the security analysis. Yescrypt is essentially that upgrade, but it stayed niche. Argon2 won because it was a clean-slate design with all the desired properties built in.
Could a better PHC winner have been chosen?
The judges considered all finalists carefully. Argon2 won on a combination of security, performance, simplicity, and cleanliness. Yescrypt and Catena were close runners. Subsequent attacks have not changed the picture: Argon2 remains a sound choice.
Is Argon2 still secure in 2026?
Yes. There have been no significant attacks on Argon2id since the competition. Implementation bugs have been found in specific libraries (e.g., libsodium fixed a side-channel issue in early Argon2i implementations), but the underlying algorithm is intact.
Will there be another PHC?
There is no current plan. Argon2 is doing well enough that the field's energy has shifted to post-quantum cryptography. If a fundamental attack on Argon2 emerges, a follow-on competition could happen.
How do quantum computers affect this?
As discussed in our other password hashing articles, the main effect is Grover's algorithm cutting effective password entropy in half. Memory-hardness is unaffected. The remedy is longer or higher-entropy passwords.
Sources
- Aumasson, J.-P. and others. "Password Hashing Competition." 2013-2015. https://www.password-hashing.net/
- Biryukov, A., Dinu, D., and Khovratovich, D. "Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications." IACR ePrint 2015/430. https://eprint.iacr.org/2015/430
- Biryukov, A., Dinu, D., and Khovratovich, D. "The Memory-Hard Argon2 Password Hash and Proof-of-Work Function." IETF RFC 9106, September 2021. https://datatracker.ietf.org/doc/html/rfc9106
- Forler, C., Lucks, S., and Wenzel, J. "Catena: A Memory-Consuming Password Scrambler." IACR ePrint 2013/525. https://eprint.iacr.org/2013/525
- Simplicio, M. et al. "Lyra2: Password Hashing Scheme with improved security against time-memory trade-offs." IACR ePrint 2015/136. https://eprint.iacr.org/2015/136
- Percival, C. and Josefsson, S. "The scrypt Password-Based Key Derivation Function." IETF RFC 7914, August 2016. https://datatracker.ietf.org/doc/html/rfc7914
Related Articles
- Argon2id Explained: How Modern Password Hashing Works
- Argon2id vs bcrypt vs scrypt: 2026 Recommendations
- scrypt: Memory-Hard Password Hashing Explained
- BLAKE3 Hashing: Fast, Modern, Parallel
- What Is Post-Quantum Cryptography? A Plain-English Guide
- Code-Based Post-Quantum Cryptography: Future Beyond HQC
- NIST SP 800-90A/B/C: Random Number Generation
- Concat KDF (SP 800-56C): The Two-Step Approach
- NIST SP 800-57: Key Management Recommendations
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.