fips205-slhdsa-verified/verification
mrwulf 2e48d9c6d0 phase 2: THE APEX — slh_verify_128s accepts iff recomputed root = pk_root
fips205.slh_verify_128s_accepts_iff (Proofs/ApexSpec.lean): the extracted
top-level SLH-DSA-SHA2-128s verifier returns `ok true` if and only if the
recomputed hypertree root byte-equals the pinned public-key root pk.pk_root.
There is NO acceptance path other than root equality.

    slh_verify_128s mprime sig pk
      = (do let root ← slhVerifyRoot 63 30 mprime sig pk
            ok (decide (root.val = pk.pk_root.val)))

where slhVerifyRoot is byte-for-byte the extracted slh_verify_internal_free
pipeline (H_msg digest -> md/idx_tree/idx_leaf split via to_int + masks ->
fors_pk_from_sig -> hypertree recompute over xmss over wots over chain), with
only the final ht_verify_free comparison factored out.

#print axioms cone = EXACTLY [propext, Classical.choice, Quot.sound,
verify_mono.oracle.{f, h, h_msg, t_l, t_len}] — the three kernel axioms plus
PRECISELY the five SHA-2 hash oracles, and nothing else. No plumbing, no
transpiler artifacts. This is the boundary the whole campaign targeted: the
deployed verify path is machine-checked down to five named hash functions.

Structure:
- arrayEqU8_spec: the library array equality PartialEqArray.eq on two
  Array U8 N returns exactly the decidable byte-equality of their lists (a
  List.allM induction; the one real lemma). This is what makes "accepts" mean
  "root byte-equals pk_root" explicitly, in the spirit of the ed25519
  verify_accepts_iff.
- ht_verify_free_split: ht_verify_free = htVerifyRoot >>= (byte-compare to
  pk_root), via arrayEqU8_spec on the tail; bind_congr threads the setup.
- slh_verify_internal_accepts_iff (generic, all param sets) + the 128s
  corollary: unfold the internal, rewrite the ht tail with the split, flatten
  with bind_assoc; both sides become the identical do-block (simp closes
  structurally — no whnf of the nested ht_verify_free_loop, the ForsOuter
  lesson).

Honest scope: the apex is an ACCEPTANCE characterization — it pins that the
top-level accept is exactly root equality over the extracted recomputation,
whose every loop is individually fidelity-certified by the ten preceding
theorems (chain/wots/xmss/ht/fors/input-prep). It does NOT re-derive the
recomputation as a closed-form mathematical hypertree value; that composition
of all ten fold-fidelity theorems into one expression is a further step, not
claimed here. The security-relevant statement — an accepted signature means
the verifier recomputed a root matching the pinned key, down to five hash
oracles — is exactly what is proven.

check.sh: PROOFS += ApexSpec; CERTS += fips205.slh_verify_128s_accepts_iff;
audit imports it. Green over ALL ELEVEN certificates at default caps.

The verify-path proof pyramid is COMPLETE. What remains before any LTL
attestation is operator-gated and NOT started (the big halt): the pacta
allowed-cone table entry + the append ceremony with the operator signing key.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 09:58:06 +02:00
..
gen/SlhVerify phase 2: INPUT-PREP layer — to_int, to_byte, WOTS+ checksum (3 kernel-3 certs) 2026-07-24 08:55:34 +02:00
Proofs phase 2: THE APEX — slh_verify_128s accepts iff recomputed root = pk_root 2026-07-24 09:58:06 +02:00
check-selftest.sh post-flip drill over the WOTS+ certificate: HELD; one rotted gate fixed 2026-07-23 15:07:07 +02:00
check.sh phase 2: THE APEX — slh_verify_128s accepts iff recomputed root = pk_root 2026-07-24 09:58:06 +02:00
drill.sh drill: the post-flight drill becomes a button (drill.sh) 2026-07-23 15:36:00 +02:00
extract.sh audit catch 2: the oracle boundary is FIVE, not six 2026-07-22 23:02:40 +02:00
lean-guard SLH-DSA (FIPS 205) campaign skeleton: honest zero-certificate state 2026-07-22 21:00:57 +02:00