fips205-slhdsa-verified/ATTESTATION-BASIS.md

110 lines
6.4 KiB
Markdown
Raw Permalink Normal View History

round 8: self-deriving harness pins, honest extraction guarantees, attestation basis Third reviewer returned ATTEST-with-conditions at 1bc4f39. Its conditions are committed verbatim as ATTESTATION-BASIS.md so the limits travel with the artifact instead of living in a review document a consumer never sees. Condition 9 — that extract.sh's byte-identical regeneration has never been observed by any party but the author — is the campaign's last open item, and the file records that both reviewers are now blocked on it for different environmental reasons. HARNESS PINS ARE NOW SELF-DERIVING. My round-7 fix hardcoded the required pin names, which the reviewer correctly called a second thing to keep in sync, and it supplied the boundary the harness does have: the executable bit. check.sh now requires every executable file in verification/ to be pinned (itself excluded — it cannot pin itself), plus Proofs/Audit.lean. A new harness script therefore fails closed until pinned. Consequence, and the reviewer argued for it: check-selftest.sh, drill.sh and extract.sh are now pinned too — the self-test is the only artifact demonstrating the gates work, and its assertions have been defective in four consecutive rounds, so weakening it should be a reviewable rotation rather than an unnoticed edit. THE EXTRACTION SCRIPT'S GUARANTEES ARE NOW STATED HONESTLY. The reviewer found a tautological assert in it — comparing a dict against the comprehension that had just built it — in the script written to fix a provenance-honesty defect. My first repair (comparing kept[k] against t[k]) was tautological for the same reason, which I confirmed by negative test. No check inside a transformer can detect a corrupted input, because the transformer defines the output from that input; that lesson is now recorded in the code. Both fake checks are gone and the header and provenance text name what actually protects the result — the pinned SOURCE_SHA256, the sk-must-be-present check, the group and test counts, and verify mode — each of which I negative-tested. Also: the self-test keeps its backups outside verification/ (cp -p preserves the executable bit, so an in-tree backup would have looked like an unpinned harness file and failed a run for an unrelated reason); the Phase-0 banner no longer says a file 'differs' when an entry is simply absent; and attack 18's assertion follows the renamed diagnostic and now requires both missing pins to be named. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 12:40:39 +00:00
# Attestation basis — independent technical review
This file records the **reviewer's own words**, verbatim, as the conditions
attached to any attestation of this repository. It is committed here so that the
limits travel with the artifact rather than living in a review document the
consumer never sees.
Nothing in this file is a decision to attest. The signing-key halt and the
paper-appeal gate are the operator's, and an attest verdict from a reviewer is a
technical input to that decision, not the decision. (The attestation has since
occurred: LTL leaf 18, 2026-08-08 — this file remains the conditions record.)
round 8: self-deriving harness pins, honest extraction guarantees, attestation basis Third reviewer returned ATTEST-with-conditions at 1bc4f39. Its conditions are committed verbatim as ATTESTATION-BASIS.md so the limits travel with the artifact instead of living in a review document a consumer never sees. Condition 9 — that extract.sh's byte-identical regeneration has never been observed by any party but the author — is the campaign's last open item, and the file records that both reviewers are now blocked on it for different environmental reasons. HARNESS PINS ARE NOW SELF-DERIVING. My round-7 fix hardcoded the required pin names, which the reviewer correctly called a second thing to keep in sync, and it supplied the boundary the harness does have: the executable bit. check.sh now requires every executable file in verification/ to be pinned (itself excluded — it cannot pin itself), plus Proofs/Audit.lean. A new harness script therefore fails closed until pinned. Consequence, and the reviewer argued for it: check-selftest.sh, drill.sh and extract.sh are now pinned too — the self-test is the only artifact demonstrating the gates work, and its assertions have been defective in four consecutive rounds, so weakening it should be a reviewable rotation rather than an unnoticed edit. THE EXTRACTION SCRIPT'S GUARANTEES ARE NOW STATED HONESTLY. The reviewer found a tautological assert in it — comparing a dict against the comprehension that had just built it — in the script written to fix a provenance-honesty defect. My first repair (comparing kept[k] against t[k]) was tautological for the same reason, which I confirmed by negative test. No check inside a transformer can detect a corrupted input, because the transformer defines the output from that input; that lesson is now recorded in the code. Both fake checks are gone and the header and provenance text name what actually protects the result — the pinned SOURCE_SHA256, the sk-must-be-present check, the group and test counts, and verify mode — each of which I negative-tested. Also: the self-test keeps its backups outside verification/ (cp -p preserves the executable bit, so an in-tree backup would have looked like an unpinned harness file and failed a run for an unrelated reason); the Phase-0 banner no longer says a file 'differs' when an entry is simply absent; and attack 18's assertion follows the renamed diagnostic and now requires both missing pins to be named. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 12:40:39 +00:00
---
## Verdict
**Round 8, third reviewer, 2026-07-28: ATTEST, with the conditions below.**
Basis the reviewer performed on hardware, an OS and a toolchain build that are
not the author's: `check.sh` ALL GREEN at `1bc4f39` with six pins verified and
the audit digest `d83e297a…`; `check-selftest.sh` green (17 attacks + the
digest-coverage check); the audit digest recomputed *outside* `check.sh` from a
bare `lean Proofs/Audit.lean` and matched byte-for-byte against the committed
`AUDIT-MANIFEST.txt`; NEW-13 attacked five ways; the NIST vector file
independently re-derived from the official 30.7 MB upstream file and found
byte-identical; the full empirical bridge executed on stable Rust; and the ACVP
harness mutation-tested (a flipped bit in a valid vector and a deleted NIST test
both correctly fail).
Not performed by any reviewer: `verification/extract.sh`. See condition 9.
---
## Conditions, verbatim from the reviewer
> What is established: eleven Lean 4 theorems over the Charon/Aeneas-extracted
> model of `verify_mono::slh_verify_128s`, the private monomorphic re-expression
> of the SLH-DSA-SHA2-128s verify path. Ten are loop-fidelity theorems; the apex,
> `fips205.slh_verify_128s_accepts_iff`, characterises acceptance — the extracted
> verifier returns `ok true` if and only if the recomputed hypertree root
> byte-equals the pinned public-key root. Every certificate's axiom cone is
> exactly Lean's three kernel axioms plus the named SHA-2 oracles that layer
> reaches, machine-checked inside Lean and bound by a SHA-256 digest over the
> policy constants, the elaborated statements and the specification bodies.
>
> This attestation carries the following limits, all of which are stated in the
> repository's own `TRUSTED-BASE.md` and all of which I verified are accurate:
>
> 1. **The five SHA-2 hash oracles are opaque assumptions.** Their conformance to
> FIPS 180-4 is not proven here. `oracle.t_l` and `oracle.t_len` are two
> independent axioms over one Rust primitive — conservative, but the model
> cannot express that they agree.
> 2. **The ten loop certificates are transliteration-fidelity results, not
> conformance results.** Each equates a generated loop with a hand-written
> reference fold built from the *same* extracted primitives, so it pins what
> the extracted code does at each index and makes it visible; it does not
> exclude a wrong ADRS field or a wrong schedule relative to FIPS 205. Mapping
> each fold onto the standard remains a human reading step.
> 3. **The apex does not compose the ten.** It is a structural factorization of
> the extracted verifier around its final equality check and references none
> of them; it would remain provable if one were deleted.
> 4. **`base_2b`'s inner accumulation loop has no certificate.** It determines
> the FORS indices and WOTS+ digits, so a defect there could change the
> recomputed root while all eleven theorems still hold.
> 5. **Everything above the extraction root is uncovered:** M assembly, the
> pure-versus-prehash domain-separator byte, the `ctx.len() > 255` bound, and
> signature/public-key deserialization.
> 6. **The bridge from the proved `verify_mono` facade to the deployed generic
> `pk.verify()` is empirical, not a machine-checked refinement:** 137 evaluated
> input/verdict cases on the proved path, of which 20 are NIST ACVP
> known-answer tests and 127 compare mono against the deployed verifier. A
> passing differential test is evidence, not a proof.
> 7. **Trusted and unbound by anything the button can check:** the Lean kernel and
> its three axioms; the Charon/Aeneas transpilation pair; `verification/check.sh`
> itself; `~/aeneas-toolchain/env.sh`; the `$AENEAS_HOME` Aeneas/Lean library
> the proofs are checked against; `python3`; and the Lean toolchain.
> `lean-guard` and `Proofs/Audit.lean` are sha256-pinned, so tampering with
> either is a build failure rather than a silent green; an author who edits one
> *and* rotates its pin in the same commit is caught only by reading the diff
> at the pin.
> 8. **Scope is SLH-DSA-SHA2-128s only**, verify path only. Key generation and
> signing are out of scope. No reproducible-builds claim: the proof is about
> the pinned source, not any compiled binary.
> 9. **`verification/extract.sh`'s byte-identical regeneration of the Lean model
> from the pinned Rust source has never been observed by any party other than
> the author.** Every other load-bearing claim in this repository has been
> reproduced by an independent reviewer on different hardware; this one has
> not, and it is the claim that ties the Lean model to the Rust source. Until a
> third party re-runs `extract.sh` at the pinned Charon/Aeneas commits and
provenance: name the pin the machine actually enforces Round-8 review (GPT-5.6, register key `slh-provenance-contradictory`, HIGH), raised in round 7 and unfixed since. The machine-enforced subject is unambiguous and appears in PROVENANCE.json and extract.sh: fips205-source @ a3ce8e8644fe302019ed7ae271912333f1476de4 It appeared in ZERO markdown files. The prose instead named three other revisions across four documents — README `797b4ef`, TRUSTED-BASE `3153988`, ATTESTATION-BASIS `c945821` — so a reader could not tell which Rust the proofs are about. Subject identity is part of the attestation object: a proof about a model is not evidence for an unspecified source revision. README.md current snapshot head -> a3ce8e8, with the lineage bea1051 -> 797b4ef -> a3ce8e8 stated explicitly and matching PROVENANCE.json's own upstream_deviation text TRUSTED-BASE.md current snapshot head -> a3ce8e8 ATTESTATION-BASIS.md subject -> a3ce8e8, AND the "four model_integrity_sha256 hashes" claim corrected: only TWO (Types.lean, Funs.lean) are regenerated by extract.sh; the two *External.lean files are hand-maintained and separately byte-pinned. Stating four invites a reproducer to expect extraction to produce files it never touches. RECORDED-RUN.md IS DELIBERATELY NOT REWRITTEN. It records a run that really happened on 2026-07-24 against `797b4ef`. Editing the identity of a past run to match today's pin would falsify the record rather than correct it. It now carries a header saying so and naming the current pin. Independent extraction remains UNVERIFIED — no third party has regenerated the Lean from the Rust. That is unchanged by this commit and is stated where a reader will meet it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-03 13:28:57 +00:00
> obtains the two EXTRACTION-GENERATED hashes in `model_integrity_sha256`
> (`Types.lean` and `Funs.lean` — the other two entries, `TypesExternal.lean`
> and `FunsExternal.lean`, are HAND-MAINTAINED and are not regenerated by
> `extract.sh`; they are separately byte-pinned), the correspondence between
> `fips205-source@a3ce8e8` and `verification/gen/SlhVerify/*.lean` rests on the
round 8: self-deriving harness pins, honest extraction guarantees, attestation basis Third reviewer returned ATTEST-with-conditions at 1bc4f39. Its conditions are committed verbatim as ATTESTATION-BASIS.md so the limits travel with the artifact instead of living in a review document a consumer never sees. Condition 9 — that extract.sh's byte-identical regeneration has never been observed by any party but the author — is the campaign's last open item, and the file records that both reviewers are now blocked on it for different environmental reasons. HARNESS PINS ARE NOW SELF-DERIVING. My round-7 fix hardcoded the required pin names, which the reviewer correctly called a second thing to keep in sync, and it supplied the boundary the harness does have: the executable bit. check.sh now requires every executable file in verification/ to be pinned (itself excluded — it cannot pin itself), plus Proofs/Audit.lean. A new harness script therefore fails closed until pinned. Consequence, and the reviewer argued for it: check-selftest.sh, drill.sh and extract.sh are now pinned too — the self-test is the only artifact demonstrating the gates work, and its assertions have been defective in four consecutive rounds, so weakening it should be a reviewable rotation rather than an unnoticed edit. THE EXTRACTION SCRIPT'S GUARANTEES ARE NOW STATED HONESTLY. The reviewer found a tautological assert in it — comparing a dict against the comprehension that had just built it — in the script written to fix a provenance-honesty defect. My first repair (comparing kept[k] against t[k]) was tautological for the same reason, which I confirmed by negative test. No check inside a transformer can detect a corrupted input, because the transformer defines the output from that input; that lesson is now recorded in the code. Both fake checks are gone and the header and provenance text name what actually protects the result — the pinned SOURCE_SHA256, the sk-must-be-present check, the group and test counts, and verify mode — each of which I negative-tested. Also: the self-test keeps its backups outside verification/ (cp -p preserves the executable bit, so an in-tree backup would have looked like an unpinned harness file and failed a run for an unrelated reason); the Phase-0 banner no longer says a file 'differs' when an entry is simply absent; and attack 18's assertion follows the renamed diagnostic and now requires both missing pins to be named. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 12:40:39 +00:00
> author's attestation alone.
The reviewer's instruction on condition 9: if a third party later succeeds at
`extract.sh`, sentence 9 is to be **replaced with a statement of what was
reproduced, by whom, on what platform and at which commits — not deleted.**
---
## Status of condition 9 as of 2026-07-28
Still open. Two independent reviewers have now been unable to close it for
different environmental reasons: one sandbox blocks `static.rust-lang.org` and
`opam.ocaml.org` so Charon and Aeneas cannot be built there; the other declined
the task of building the two pinned tools from source. The claim therefore
remains author-attested only, exactly as condition 9 states.