fix(thumos): record the KDF parameters a device's secrets were derived under

[forkwright]

Draft — one gap is named below and should be closed before this merges

Finding

Stored secrets carry no record of how their keys were derived. Changing the KDF later would silently make every provisioned device unreadable, with no way to tell which algorithm a given sector predates.

What changes

Format version 1 → 2, adding a bounds-checked 16-byte KDF record. V1_KDF is PBKDF2/100k — byte-identical to the retired PBKDF2_ITERATIONS — and MASTER_KDF currently equals it, so no derivation output changes for any existing device. parse() accepts both versions and resolves a v1 header to V1_KDF.

Every call site of derive_from_passphrase, store_boot_verifier, render(, and every DeviceSecrets{} construction across crates/thumos/src was checked — none left un-threaded.

Two defects found while finishing the branch's own earlier work

• secrets.rs:329 — a doc comment describing a slot count (2 when present, 1 otherwise) the function had stopped writing.
• secrets.rs:732 — a test asserting an on-disk slot count of 2 where store_boot_verifier always renders three slots. It had been patched to compile against the new signature without being reconciled to the new semantics.

The code is right and the test was stale, established on three independent sources rather than by re-deriving the same arithmetic twice: the module-level format doc (secrets.rs:46-48, untouched and predating both), parse()'s own accepted-count and has_verifier logic (:221-224, :240-244), and the caller's behaviour. Rendering 2 would have made parse() stop recognising its own verifier.

Two tests added, because their absence was the real gap

v1_preamble_bytes_parse_under_v1_kdf — builds a v1 sector from literal bytes, never via render(). render() only ever writes v2 today, and a fixture generated by the writer under test proves only that the writer and reader agree with each other. Covers both real v1 shapes (salt-only, and salt+verifier). Before this, VERSION_V1 appeared only in production parse() branches and zero times in tests.

derive_from_passphrase_differs_per_kdf_parameters — same passphrase, same salt, two KDF parameter sets, different derived keys. This is #914's own "Done when", and without it the record is decorative.

The gap that remains — read this before merging

The v1 fixture would NOT catch a wrong V1_KDF value. It proves parse() routes a v1-tagged sector to whatever V1_KDF currently is — a self-consistency check between parse() and the constant, not an external check on the constant. If the iteration count were typo'd or silently repriced relative to what real provisioned devices used, this test still passes tautologically.

What would close it: a known-answer test — a fixed passphrase and salt with an expected key derived independently of this crate, under PBKDF2-HMAC-SHA256 at 100,000 iterations. Nothing in this suite asserts V1_KDF's value against any external reference, before or after this change.

Until that exists, "cannot break existing secrets" is argued from reading, not proven. For a master-key derivation on a device whose stored secrets become unreadable if it is wrong, that distinction is the whole thing.

Verification status

Nothing here has been compiled or run — this box has no build role for this repo. Confidence comes from manual tracing: type and visibility checks, every call site cross-referenced, and the three-source argument above. cargo test -p thumos on a build box is the actual verdict.

[forkwright]

Both failures were this branch's own, and both are fixed in 12b0646. Verified against main rather than assumed: the same kernel (i686 tests + armv7a build) job passed on main's run 32750096823 (head 5602f3f) a day before this PR's failing run, so neither defect was inherited.

rustfmt — four call sites this branch touched were never formatted, in key_manager.rs (two new test calls), secrets.rs, and security.rs.

Worth knowing why it slipped: cargo fmt --all -- --check over the workspace passes. The thumos crate carries its own manifest and toolchain and is checked separately as cargo fmt --manifest-path crates/thumos/Cargo.toml --check, which is the one that failed. A green workspace fmt is not evidence about that crate. Both exit 0 now.

kernel (i686 tests + armv7a build) — all 2564 kernel host tests passed; the job failed one step later in scripts/check-target-test-ledger.sh:

LEDGER DRIFT: module 'key_manager': ledger says 16 tests, i686 test binary has 17 runnable
LEDGER DRIFT: module 'secrets': ledger says 14 tests, i686 test binary has 15 runnable

The branch adds exactly one #[test] to each — derive_from_passphrase_differs_per_kdf_parameters and v1_preamble_bytes_parse_under_v1_kdf — and never updated docs/target-test-ledger.toml. Counts corrected to 17 and 15.

The ledger is working as designed and I did not touch its mechanism. It exists because a test that fails to compile for a target is silently not run (#124, #619, #631, #645); a declared count cross-checked against the derived one is what makes that visible. The count is meant to be updated deliberately alongside the tests, not derived away — deriving it would defeat the check.

Nothing was built, tested, or clippy'd locally; cargo fmt needs no build admission, and the kernel diagnosis is log-only plus a static diff and TOML parse.

CI note: GitHub Actions is in a major outage (incident opened 2026-08-26T15:11:58Z). Checks on this push may queue, startup_failure, or never be created — none of that will be evidence about the change. I will re-read once the incident closes rather than merging on an empty rollup.

[forkwright]

Independent completion/architecture review agrees with the draft's self-identified blocker: the v1 route fixture proves parse → V1_KDF, but it does not anchor what historical PBKDF2-HMAC-SHA256/100,000 actually produces.

To make the remaining author-owned step mechanical, I generated a KAT outside this crate using Python 3's OpenSSL 3.5.7-backed hashlib.pbkdf2_hmac:

passphrase = b"production entry point test"
salt       = b"thumos-unit-test-salt"
PRF        = HMAC-SHA256
iterations = 100000
dkLen      = 32
expected   = b881bcb2a54bfcfcf55619c2530a10b6ae82a1081ab4cbe86798f5d4e5378e23

Reproduction:

hashlib.pbkdf2_hmac(
    "sha256",
    b"production entry point test",
    b"thumos-unit-test-salt",
    100_000,
    dklen=32,
).hex()

Those inputs already exist in derive_from_passphrase_production_entry_point, so asserting the exact 32 bytes there would anchor both the production entry point and V1_KDF without inventing a second fixture. The branch remains yours; t0-thumos has not changed or rebased it. Once the KAT is committed and the draft is made ready, I can shepherd its CI/merge without colliding with the storage lanes it gates.