Commit graph

3 commits

Author SHA1 Message Date
7ebf9495d3 correspondence: keep the artifact that says what the model must answer
Round-8 estate review (GPT-5.6): this repository shipped a
FunsExternal_Template.lean / FunsExternal.lean pair and NO correspondence
check at all. This commit explains why, and fixes the cause rather than
bolting a check onto a missing input.

THE TEMPLATE WAS BEING DELETED. check.sh removed `*_Template.lean` on every
run and .gitignore excluded it. The stated reason was sound — "the verdict must
depend on COMMITTED BYTES, never on untracked build state", and an untracked
file on LEAN_PATH is exactly that problem. But it is the weaker of the two
available remedies. The ed25519 forks face the identical choice and COMMIT AND
PIN their templates, which removes the untracked state just as completely and
keeps the evidence.

The evidence is the point. The template is Aeneas's own statement of what the
extracted Rust needs from outside, and it is the ONLY artifact against which
"does the hand-written model ANSWER the extraction?" can be asked. Deleting it
made that question unaskable here — which is precisely why no check existed.

  · template committed and pinned in model_integrity_sha256
  · .gitignore no longer excludes it
  · check.sh no longer deletes it, and says why at length
  · Phase 0d runs model-correspondence.py — the forks' scanner, including both
    round-8 corrections: a named Lean `section` does not qualify declaration
    names, and an EXTRA AXIOM in the model (an assumption no template asks for)
    fails rather than passing as a silent row
  · MODEL-CORRESPONDENCE.txt committed, pinned, and compared byte-for-byte

Result: 11 externals, every one answered by the pinned model, no UNRESOLVED and
no EXTRA-AXIOM. Negative-tested — deleting one `axiom` from the model yields
`verify_mono.oracle.h_msg|UNRESOLVED` and a non-zero exit; restoring it returns
to green.

AND A REPRODUCIBILITY RESULT, obtained while recovering the deleted template.
charon is not available on this machine (the same wall the reviewer hit), but
SlhVerify.llbc IS committed and Aeneas is installed, so extraction step [2/2]
was re-run alone from the committed LLBC:

    Types.lean: IDENTICAL      Funs.lean: IDENTICAL

The LLBC -> Lean half of the extraction reproduces byte-for-byte from committed
inputs, on demand, by anyone with Aeneas and this repository. This does NOT
close `slh-extraction-unreproduced`: the Rust -> LLBC half still requires
charon, and this was still run by the author. Half the chain, verifiable today.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 15:49:16 +02:00
53c5b45e3f Phase 1: clean extraction + type-checking SLH-DSA-SHA2-128s model
The gate-0 fn-pointer blocker is cleared. This commits the phase-1
deliverable:

- verification/extract.sh: re-pointed at the monomorphic root
  crate::verify_mono::slh_verify_128s with crate::verify_mono::oracle as
  the opaque SHA-2 boundary (against fips205-source @ 2d89ee3).
- verification/gen/SlhVerify: the extracted Lean model — 62 defs, the
  full verify cone (chain -> wots -> xmss -> ht -> fors ->
  slh_verify_internal) up to the apex verify_mono.slh_verify_128s. No
  sorry, no admit.
- verification/gen/SlhVerify/FunsExternal.lean + TypesExternal.lean:
  hand-maintained externals with the two-class justification header —
  (1) the five SHA-2 hash oracles = the deliberate cryptographic
  boundary (the only axioms the apex certificate will carry beyond
  Lean's three); (2) transpiler plumbing (try_from, is_err, iterator
  Step/Take, zeroize) adopted as axioms for the phase-1 type-check, to
  be discharged in the proof phase.
- verification/check.sh: real Phase-1 button — compiles the model under
  lean-guard (memory-capped, serialized). GREEN. Still says NOTHING
  PROVEN: a well-formed model is not a correct one.

Zero certificates. Proof layers (chain semantics -> ... -> acceptance
equation) are the next task.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-22 22:21:19 +02:00
31f00fe756 SLH-DSA (FIPS 205) campaign skeleton: honest zero-certificate state
Subject pinned: integritychain/fips205 @ 30bac08 via
saymrwulf/fips205-source @ 5dca0db. Parameter set SLH-DSA-SHA2-128s.
Scope: verify path only (slh_verify -> ... -> chain); six SHA-2 hash
oracles opaque per the standing boundary.

Gate-0 record (2026-07-22): charon clean on the full verify cone;
aeneas translates everything except the Hashers fn-pointer struct
(3 unique errors, the sole obstruction) -> phase 1 = named-opaque-
free-function compat patch in the snapshot repo, the established
dalek sha512-shim pattern.

check.sh exits non-green and says NOTHING PROVEN YET (H5, R3).
lean-guard copied; every future compile runs under it (S1, S2).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-22 21:00:57 +02:00