The register / Clause 7

PBKDF2

The document specifies PBKDF2 as its second password-based key derivation function. The public preview names it and shows subclauses for general matters, input values and parameters, and the specification.

Our reading

PBKDF2 is the older and more widely deployed of the two. Its cost is controlled by an iteration count and a pseudorandom function, usually an HMAC with a modern hash. A count that was defensible on a 2015 server is not automatically defensible on current hardware, so the count needs a date and a review trigger.

Clause 7 covers PBKDF2, the function most estates already own somewhere. The public contents show the same three-part shape as clause 6: general matters, input values and parameters, and the specification. PBKDF2 is standardised in the public PKCS series and profiled for passwords in NIST guidance, which makes it familiar to assessors and easy to source in libraries.

The operational levers are the iteration count, the salt, the pseudorandom function and the output length. Of these, the iteration count ages fastest. Hardware gets quicker, so a count chosen to take a fixed time on old hardware takes less time on new hardware. A parameter record without a benchmark date cannot show that the cost is still meaningful.

PBKDF2 has a practical advantage in regulated environments: it is available in validated cryptographic modules and in the libraries that teams already run. That can matter more than a theoretical preference. The trade is that it is not memory-hard, so an attacker with specialised hardware gets more from each unit of parallelism than with Argon2i. The choice should be explained in those terms.

The implementation risks are mundane and common. A salt that is fixed, truncated or reused. An iteration count left at a library default. A pseudorandom function chosen for compatibility rather than strength. A migration that changes the count but never re-derives old data. Each of those is testable, and each belongs in the evidence file.

Migration is the part teams underestimate. Raising the iteration count is easy for new data and hard for old data that was encrypted under the previous count. Record the count with each protected object, or record a version number that points at it, so a reader can tell which derivation produced which key.

Evidence to keep

• The iteration count, salt length, pseudorandom function and output length, with the benchmark dateThe count is only defensible with the hardware and date it was measured on.
• A migration note for raising the count, including how old data is re-derivedChanging the count without a migration plan strands existing data.
• A test-vector result using the production pseudorandom functionThe function and output length are part of the specification in practice.
• The reason PBKDF2 was chosen over Argon2i, or the reverseEither choice is defensible when the trade is written down.

Cross references

• RFC 8018, PKCS #5, PBKDF2 (public specification, not the ISO text)
• RFC 6070, PBKDF2 test vectors
• NIST SP 800-132, password-based key derivation

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.