mirror of
https://github.com/saymrwulf/fips205-slhdsa-verified.git
synced 2026-09-03 19:53:49 +00:00
mrwulf
05c4412168
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>
105 lines
6 KiB
Markdown
105 lines
6 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 four `model_integrity_sha256` hashes, the correspondence between
|
||
> `fips205-source@c945821` 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.
|