Answers / How do you record KDF parameters for an auditor?

How do you record KDF parameters for an auditor?

The columns that survive a review

Start with the use case and the asset, not the algorithm. Then the function and variant as named in the standard, the salt length and how uniqueness is guaranteed, the cost parameters with their units, the output length, the library and exact version, and the date the settings were benchmarked on the weakest supported hardware. Add the owner and the next review date.

Why the variant and the version matter

Argon2i and Argon2id are different functions, and a library that passes one set of vectors has not thereby proved the other. A version number is not bureaucracy: a dependency update can change behaviour, and the test-vector output is how you prove it did not. The record should point at the stored output.

What an auditor will test

They will pick a row, ask you to re-derive a key from a known password and salt, and compare it with a stored vector. They will ask why the cost is enough on the weakest device. They will ask what happens when the count is raised and old data must still be read. A row that cannot answer those three questions is a screenshot, not a record.

Keep it with the decision

The numbers are only defensible with the decision that chose them: the attacker, the asset, the availability trade and the residual risk. Keep the one-page decision record next to the parameter row. The kit XLSX has a sheet for each, and the dated plan puts a review on the calendar.

The short answer, with its limit

Use one row per use with these columns: use case, asset, function and variant, salt source and length, cost parameters with units, PRF, output length, library version, benchmark date, owner and review date. Store the test-vector output with the row so a reviewer can re-run it.

Where the public record is silent, this page says so and does not fill the gap. The register carries the clause-level detail.