Annex B
- Public status
- The annex title and the three subclause titles are in the public contents. The definitions are not in the free public preview.
- Binding party
- The organisation that derives a cryptographic key from a human-memorised password, and anyone asked to show that its derivation follows this part.
- Evidence
- 3 items
- Read
- 2026-10-21
The register / Annex B
The compression function G
Not stated in the public preview. The annex defines the compression function G, the permutation, and the Gamma step used by the function in clause 6.
Our reading
The annex is a correctness annex. It exists so that independent implementations produce the same output. It is not a design choice for a product team, and the only sensible build decision is to consume a vetted implementation and verify it.
Annex B supplies the machinery under Argon2i. The contents list three subclauses: the function G, the permutation, and the Gamma step. The public preview stops before the definitions. What can be said without the text is structural: these are the low-level operations that make the memory-hard function reproducible across implementations.
A product team should read this annex as a boundary marker. The operations are specified at a level where a single off-by-one, a rotation count or an endianness assumption changes every output. Hand-written versions are a classic source of interoperability defects, and they are hard to test without the published vectors.
The assurance route is therefore short. Use a maintained library that implements the function. Check the library against published test vectors. Record the version and the date. Review the update policy so that a security fix reaches the product. Keep the test-vector output with the parameter record so that a future change can be compared.
If the organisation writes cryptographic code as a matter of policy, the annex is still not a substitute for a review. Treat the implementation as security-critical code: independent review, constant-time review where relevant, and a regression suite that includes the published vectors. The annex tells you what the code must compute, not how to make the code safe.
Reproducibility is the whole point of the annex. Two implementations that agree on the test vectors can exchange data; two that disagree cannot, even if both look correct in isolation. Store the vector output with the library version so a later upgrade can be compared rather than argued about. A vector file next to the code is cheap; a disputed output is not. The stored output is the proof.
The mistake to avoid
Treating a passing high-level test as proof that the low-level permutation is correct on every input.
Evidence to keep
- The library name, version and provenance for the compression functionThe annex is implemented by a dependency, so the dependency is the evidence.
- A stored test-vector output from the exact production versionA version upgrade is a change that should be proven, not assumed.
- The update and vulnerability policy for the libraryA correct implementation with an unpatched dependency is still a risk.
Test it
Re-run the published vectors after every library upgrade and diff the output against the stored result.
Cross references
- Clause 6, Argon2i
- Annex C, Blake2b
Source
https://www.iso.org/standard/87940.html
Read on 2026-10-21. The annex title and the three subclause titles are in the public contents. The definitions are 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.