Summary

  • RFC 9106 specifies Argon2 version 1.3, exact inputs, a parameter-selection procedure and test vectors; it does not certify any authentication service's capacity or resistance to a real guessing campaign.
  • A defensible verifier records the algorithm and per-record work factor, then measures per-call memory and latency, active concurrency, queueing, overload behavior and migration coverage as separate evidence.

One login request reaches a verifier. The stored record says Argon2id, version 19, a unique salt, 64 MiB of memory, three passes and four lanes. On paper it looks expensive. The call returns successfully. Neither fact answers the question that governs the service: what happens when ordinary demand makes hundreds of those calls overlap?

RFC 9106 is unusually honest about this boundary. Its parameter procedure asks how much memory each call can afford and how much time each call can afford. It then tells the implementer to vary the pass count and, if even one pass exceeds the affordable time, reduce the memory. Security is not selected from a badge. It is selected inside a resource envelope.

The function binds that envelope into the computation. The password P, salt S, parallelism p, tag length, memory m, passes t, version and type all feed the initial hash, alongside optional secret and associated-data values. Memory is allocated in 1 KiB blocks and arranged into p lanes. Lanes can advance in parallel within each slice, but they synchronize at slice boundaries. Additional passes revisit the matrix. “Argon2id” therefore omits the values that determine most of the operational cost.

The standard recommends a 16-byte salt unique to each password. A salt separates equal passwords so that their stored tags do not collapse into one reusable precomputation target. It is not a hidden accelerator brake. The work is set mainly by memory, passes and the implementation's ability to use the lanes; a verifier still needs the exact stored version and parameter tuple for every record.

Two defaults illustrate the trade. The first recommendation uses one pass, four lanes and 2 GiB. The memory-constrained alternative uses three passes, four lanes and 64 MiB. The same document also gives examples tied to a stated 2 GHz processor, including a backend case with 4 GiB and eight lanes. Those are reference points under named assumptions. They are not promises about containers, virtual machines, memory bandwidth, allocators, NUMA placement or the tail of a production fleet.

The test vectors are narrower still. They let an implementer check intermediate blocks and the final tag for fixed inputs such as 32 KiB, three passes and four lanes. Passing them proves compatible arithmetic for that case. It proves nothing about resident-set high water, cancellation, memory wiping, scheduler interference, tail latency, queue growth or what the service does when memory cannot be allocated.

That missing layer is where a strong-looking hash can become weak operational policy. If one active call is configured for 64 MiB, multiplying 64 MiB by simultaneous calls gives a planning bound, not an observed peak. Library overhead, allocator reuse and memory bandwidth can change the result. The service must measure. It must also decide what happens at the boundary: queue, reject, throttle, time out, shed other work or fail closed. Quietly falling back to a cheaper verifier would alter the security claim; exhausting the process would turn a defensive cost into an availability weapon.

Migration creates a second illusion. NIST's current guidance says the scheme and cost factor should be stored with each password so work factors can rise over time. That makes migration possible. It does not make migration complete. A new default may govern only new passwords and accounts that have logged in since the change. The real control surface is the distribution of stored parameter tuples, the rehash trigger, failed upgrades and the residual population still verified under the old budget.

The attack conclusion must remain bounded. Memory hardness raises the resource cost of testing guesses and forces an attacker to confront time-space trade-offs. It does not reveal password quality, breach scope, attacker hardware, energy price or the value of an account. RFC 9106 explicitly calls itself an Informational IRTF product, not an Internet Standards Track specification, and says IRTF results may not be suitable for deployment. Its authority is the precision of the algorithm and analysis, not a certificate for a system it has never observed.

That is also the line separating this article from BTW's RFC 9807 coverage. OPAQUE places a key-stretching function on the client and raises questions about password invisibility, OPRF-seed custody and record migration. The present problem is the ordinary server-side verifier: what the service can afford when salt, memory, passes and lanes become many concurrent calls. One is a protocol custody map. The other is a capacity and evidence ledger.

The operating receipt should therefore preserve the exact type, version, salt policy, m, t, p, tag length and optional-secret policy; library and hardware class; warm and cold latency percentiles; per-call and process memory high-water marks; simultaneous active calls; queue depth; rejection and timeout behavior; memory cleanup; CPU and bandwidth pressure; parameter-population distribution; rehash outcomes; and throttling and recovery paths. A successful hash belongs near the beginning of that chain, not at its end.

Sources

Primary specification and status: RFC 9106, RFC Editor record, IETF Datatracker record, and the Argon2 paper. Design history: Password Hashing Competition. Verifier requirements: NIST authenticator guidance and NIST password analysis. Adjacent protocol boundary: RFC 9807. Analytical framing: Minimum Initial Specification, Reality Layers, and Running-Code Primacy.