Clause 3
- Public status
- All five entries and the inherited definitions are in the public preview. They are summarised, not reproduced.
- 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 / Clause 3
Terms and definitions
Clause 3 adopts the vocabulary of ISO/IEC 11770-1:2010 and adds five terms of its own: hash-function, key derivation function (KDF), weak secret, password, and salt.
Our reading
The definition of a KDF is the one to carry into design reviews. It requires at least one secret input and an output of keys appropriate to the intended algorithms and applications. A function that stretches a password but produces something that is never used as a key does not meet the definition, even if the code calls it a KDF.
Five definitions carry the document. A hash function maps a variable-length input to a fixed-length output and makes collisions and preimages impractical to find. A key derivation function takes several inputs, at least one of them secret, and returns keys suited to the algorithms and applications that will use them. A weak secret is one a person can conveniently memorise. A password is a memorised weak secret used for entity authentication. A salt is an input to a derivation that might not be secret.
The KDF definition is the hinge. It says the output must be appropriate for the intended algorithm and application. That is a design statement, not a formatting statement. A 256-bit output from a weak password is still a key drawn from a small set of candidates. The function can only make each guess expensive; it cannot add entropy that the password does not have.
The salt definition is deliberately modest. A salt might not be secret. Its job is to make precomputed tables useless and to stop two identical passwords producing identical keys. It is not a pepper and it is not a secret key. Confusing the two leads teams to put the salt in a secret store and then lose the ability to re-derive after a restore.
The inherited definitions matter as much as the five new ones. ISO/IEC 11770-1:2010 supplies the key management vocabulary, so terms such as key, key pair and key lifecycle should be read there. When a policy uses a term that neither document defines, write the meaning down and say where it came from. An assessor will ask.
The mistake to avoid
Using salt to mean a secret pepper. The definition allows a salt that is not secret, and treating it as a secret creates a recovery problem.
Evidence to keep
- A project glossary mapped to the five defined terms and to the inherited 11770-1 vocabularyShows the team is using one vocabulary across design, code and assessment.
- A review note that distinguishes the salt from any secret key or pepperPrevents a recovery failure when a restore is tested.
- The password entropy assumption stated in the design recordThe definitions make the weak secret explicit, so the assumption should be explicit too.
Test it
Ask three engineers to define salt and pepper without notes. If the answers disagree, the glossary is not in use.
Cross references
- ISO/IEC 11770-1:2010, terms and definitions
- ISO/IEC 10118-1:2016, hash-function source note
Source
https://www.iso.org/standard/87940.html
Read on 2026-10-21. All five entries and the inherited definitions are in the public preview. They are summarised, not reproduced. 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.