Every verdict on the verifier page comes from the certified sephos-crypto CSE core — the WASM module and the JavaScript glue that calls it, a verbatim snapshot of the certified build. This page answers the last-mile question: are the artifacts actually served here that certified core?
Recomputes SHA-256 of every distributed artifact as served to your browser — the
wasm crypto/sephos_crypto_cse_bg.wasm, the JS glue crypto/sephos_crypto_cse.js
and the type declarations — and compares each to the hash pinned in
crypto/checksums.sha256 (the file emitted by the certified build). It also checks that
crypto/manifest.json agrees with checksums.sha256 and that every export
the app calls is in the certified allowlist. Fail-closed: any fetch error, missing file, hash
difference, or inconsistency is a MISMATCH. This catches corruption and stale or
swapped artifacts — but it still trusts this host to serve this page honestly, which is why levels
2 and 3 exist.
git clone <this repo> && cd sephos-verifier ./verify-build.sh
Same hash comparison, but over files you obtained yourself — nothing served by this host is trusted.
sephos-crypto and check out the pinned commit
(see crypto/PROVENANCE.md).cd bindings/wasm && ./build-cse.sh (toolchain + tool versions pinned in
crypto/PROVENANCE.md)..js) and types
(.d.ts) are byte-identical — diff them against crypto/ here.valid). The vendored wasm sha256 (levels 1–2) pins the integrity of the
served bytes, not reproducibility.The verifier reimplements no cryptography: it only calls four certified exports —
shielded_verify_redacted_public_audit_package (universal),
shielded_verify_cast_inclusion_cse (individual receipt),
shielded_verify_dkg_dispute_transcript_cse_v1 (§17.4 dispute) and
shielded_verify_eligibility_registration_bindings (eligibility) — all in the certified
binding allowlist of the sephos-crypto audit dossier. The one-click check above confirms each is
present in that allowlist.