Annex C
- Public status
- The annex title and the two 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 C
Blake2b
Not stated in the public preview. The annex defines the component functions and the Blake2b hash function H used by the function in clause 6.
Our reading
Blake2b is a public hash function with a public specification. Its presence here is a dependency to inventory, not a reason to write a hash. The regulated question is whether the chosen module is approved in the market where the key is used.
Annex C defines the hash function that Argon2i uses. The public contents list two subclauses: the component functions and the Blake2b hash function H. Blake2b also has a public specification outside the ISO series, which makes the dependency easier to check than most.
For an assessor, the interesting question is not whether Blake2b is a good hash. It is whether the implementation in use is the approved one for the market and the data. Some regulated environments restrict the approved algorithms and modes. A function that is sound in general can still fail a local approval rule, and that failure belongs in the risk register, not in a footnote.
The evidence is a dependency record. Name the library, the version, the digest length and the mode of use. Keep the test-vector result. Note any approval status and the market it applies to. If the product ships to several markets, the record may need more than one answer.
The correction to a common assumption is worth stating. A hash function is not a key derivation function. Blake2b appears here as a component of one. Using Blake2b directly on a password, without the memory-hard construction around it, is a different design and is not what this part specifies.
Digest length is a parameter that is easy to truncate by accident. If a protocol needs a shorter value, truncate deliberately and record where, rather than letting a library default decide. The annex defines the hash; the product still owns the choice of how much of its output to use. Record that choice with the algorithm name. The algorithm name and the output length should travel together in every record.
The mistake to avoid
Substituting a fast hash for the full construction because the underlying hash is named in an annex.
Evidence to keep
- A dependency record with the hash library, version, digest length and approval statusThe annex is a dependency, so the dependency record is the evidence.
- A test-vector result for the hash function as usedProves the component behaves as specified in the built product.
- A market-by-market approval note where the data is regulatedA sound algorithm can still fail a local approval rule.
Test it
Confirm that the production path calls the complete construction, not a bare Blake2b digest, and that the library version is the one in the dependency record.
Cross references
- RFC 7693, BLAKE2 (public specification, not the ISO text)
- Clause 6, Argon2i
Source
https://www.iso.org/standard/87940.html
Read on 2026-10-21. The annex title and the two 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.