The register / Clause 6

Argon2i

The document specifies Argon2i as one of its two password-based key derivation functions. The public preview names it and shows the subclauses for general matters, input values and parameters, and the specification itself.

Our reading

Argon2i is the data-independent variant of Argon2. Its memory access pattern does not depend on the password, which is the property a side-channel-sensitive environment wants. The trade is that data-independent access gives a memory-hard function less resistance to some time-memory trade-off attacks than the data-dependent variant. That trade belongs in a decision record, not in a default.

Clause 6 is the longer of the two function clauses. The public contents show three subclauses: general matters, input values and parameters, and the specification of Argon2i. Two annexes support it. Annex B defines the compression function G, with the function, the permutation and the Gamma step. Annex C defines the Blake2b hash function that Argon2 uses.

Argon2i is a memory-hard function with a data-independent addressing scheme. The design goal is to make each guess cost both time and memory, so that parallel guessing with cheap hardware is less attractive. Because the addresses do not depend on the password, the function is easier to protect against cache-timing observation. That is why it is often chosen for shared or virtualised hosts.

The parameters are the heart of the operational decision. A deployment has to settle memory, iterations and parallelism, plus the salt length and the output length. The right numbers depend on the hardware, the acceptable delay and the memory the process can afford. They are not a universal constant, and copying numbers from another organisation without a benchmark is not a parameter choice.

The annex structure is a warning against hand-rolling. G, the permutation and Blake2b are specified so that independent implementations agree, not so that product teams write them again. Use a maintained library, check it against published test vectors, and record the library version. If the library exposes Argon2id but not Argon2i, that is a finding to resolve, not a detail to rename.

Evidence to keep

• A parameter record with memory, iterations, parallelism, salt length and output length, and the benchmark that chose themThe parameter record is the central artefact for either function.
• The library name and exact version, with its provenance and update policyThe annexes exist so implementations agree; the library is the implementation.
• A test-vector result for the Argon2i variant specificallyA pass on another variant does not prove this one.
• A side-channel and memory-exhaustion note for the host classArgon2i is chosen partly for its access pattern, and memory cost has a denial-of-service edge.
• A decision record if Argon2id or another variant is used insteadThe difference is material and should be an explicit, reviewed choice.

Cross references

• RFC 9106, Argon2 memory-hard function (public specification, not the ISO text)
• Annex B, the compression function G
• Annex C, Blake2b

Source

https://www.iso.org/standard/87940.html
Read on 2026-10-21. The function is named in the public introduction and its clause and subclause titles are in the public contents. The normative text is not in the free public preview. ISO free public preview carries the foreword, the introduction, clauses 1 to 3 and the table of contents. It is the DIS, not the FDIS, and the FDIS may differ. Clauses 4 to 7, annexes A to D, the figures and the object identifiers are not in the free preview; ISO sells the text. This site does not reproduce it and does not invent it.