fix(crypto): bound key derivation by wall clock (fuzz-found DoS)

[h4x0r]

The finding

The nightly unlock fuzz target does not crash — it stops:

==4250== ERROR: libFuzzer: timeout after 1780 seconds
MS: 2 ChangeBit-CMP- DE: "sha1"-

derive_key takes its iteration count straight from the LUKS keyslot, so it is
attacker-controlled, and floors it without ever capping it:

let iters = iterations.max(1);   // floor only — no ceiling

A crafted header can ask for up to 4,294,967,295 PBKDF2 rounds. An examiner
opening that image waits forever: denial of service in a tool whose entire job
is reading hostile input.

The fix

Measure this machine's PBKDF2 rate on a short calibration run, project the cost
of the full count, and refuse before starting anything over a 30-second budget.
u32::MAX now returns DerivationBudgetExceeded in milliseconds.

The bound is on projected wall clock, not on the iteration count, because
"too many rounds" is a property of the machine rather than a number fixable in
advance — a count that is absurd on a laptop can be routine on a workstation.
PBKDF2 is exactly linear in its iteration count, so scaling a 20,000-iteration
measurement is sound.

Refusal, never a silent clamp. Deriving with fewer rounds than the header
specifies yields a different key, so clamping would report a wrong passphrase
for a container that would in fact have opened — fabricating a failed unlock,
which is worse than declining to try. The error names the iteration count, the
projection and the budget.

Two designs deliberately rejected

• A deadline checked inside the iteration loop — the obvious shape, and the
  one first sketched. Reaching inside the loop means hand-rolling PBKDF2 around
  a raw HMAC, and this module's opening line is that every primitive comes from
  an audited RustCrypto crate.
• A worker thread with a timeout — returns promptly, but leaves a thread
  spinning on the malicious input for the life of the process.

Known consequence

Acceptance is machine-dependent: a container near the budget can be refused on a
slow host and accepted on a fast one. That is inherent to bounding wall clock,
and is why the error reports the projection rather than just failing.

Verification

• absurd_iteration_count_is_refused_rather_than_run asserts the reason —
  DerivationBudgetExceeded { iterations: u32::MAX, .. }, not is_err(), which
  would pass just as happily on an unrelated failure
• It runs behind a 60-second watchdog, so it failed in a minute before the fix
  rather than hanging the suite — a red that never terminates is not useful
• a_realistic_iteration_count_still_derives pins 200,000 iterations (inside
  what cryptsetup writes) as untouched and stable, so the bound cannot quietly
  start rejecting real containers
• fmt, clippy -D warnings, and the full workspace suite are clean; the suite
  now finishes in 3.4s instead of timing out at 60

Not addressed here

derive_key_argon2 takes memory and time costs from a LUKS2 keyslot and is
exposed the same way, bounded only by what Params::new happens to reject.
Worth its own change.

---

Update: the Argon2 half is now fixed too

The "Not addressed here" note below is resolved in this PR. derive_key_argon2
took both cost axes straight from the LUKS2 keyslot and handed them to
argon2::Params, whose ceilings are MAX_T_COST = u32::MAX and
MAX_M_COST = u32::MAX 1 KiB blocks — upstream rejects nothing at the top
end, so a crafted header can request 4 TiB of memory.

That failure is worse than the PBKDF2 hang. The red test did not produce a slow
return or a panic:

process didn't exit successfully: (signal: 9, SIGKILL: kill)

The OS killed the test binary. On an examiner's machine the tool doesn't stall
— it dies, taking the rest of the run with it.

That also settles the design. Memory cannot be bounded by wall clock the way
the time cost is: attempting the allocation is itself the harm, and there is
no moment at which a deadline could fire. So the axes get different treatment:

• Memory — capped at 4 GiB and refused before anything allocates, via a
  dedicated DerivationMemoryExceeded naming the requested value and the
  ceiling. cryptsetup benchmarks LUKS2 keyslots to about 1 GiB at most, so this
  is generous headroom over any genuine container.
• Time — the Argon2 analogue of the iteration count, bounded exactly as
  PBKDF2 is: measure one pass, project, refuse over DERIVATION_BUDGET. Argon2
  is linear in t_cost, so scaling a single pass is sound.

Order is load-bearing: the memory ceiling is enforced first, because the
calibration pass runs at the requested memory cost — the measurement must
itself be safe.

Verification

• 4 TiB memory cost refused, and the error names the value — an examiner
  needs to see which cost the header asked for
• u32::MAX time cost refused behind a watchdog rather than run
• a realistic 64 MiB / t=4 cost still derives reproducibly — a bound that
  rejected real containers would be worse than the bug
• fmt · clippy -D warnings · 7 suites, 0 failures · coverage gate 0
  uncovered lines

One note on the tests: the memory assertion deliberately avoids matches! with
a literal field pattern. That generates a never-taken region which the coverage
gate reports as an uncovered line, and exempting it with // cov:unreachable
would have annotated a macro artifact rather than a defensive arm.