mirror of
https://github.com/saymrwulf/fips205-slhdsa-verified.git
synced 2026-09-04 20:03:44 +00:00
mrwulf
c80c2bba5b
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>
108 lines
6.3 KiB
Markdown
108 lines
6.3 KiB
Markdown
# 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.
|
||
|
||
---
|
||
|
||
## 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
|
||
> 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
|
||
> 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.
|