mrwulf
ec9f085615
New \S5.4 'Scheme-level games and a composition theorem' (operator order: third attempt targets an IACR venue): - Game PB (position binding): two accepting openings of different leaves at one (m,n,r) -> explicit B_pb outputs a SHA-256 collision in <= 2(ceil(log2 n)+1) hash evaluations (two-transcript top-down comparison; 32-byte widths make argument pairs recoverable). - Lemma (prefix transport): an accepted ConsRec transcript plus an accepting opening at m<n0 under the NEW head yields a collision or an assembled accepting opening under the OLD head (frontier comparison + old-root spine assembly; degenerate power-of-two case handled). - Game HIST (local history binding): pin-rule chains + contradictory openings at any two accepted heads -> collision, by transport induction + PB. Supplies the multi-step closure at paper level. - Game FORK: evidence completeness by construction; frame resistance reduces to EUF-CMA. Win condition deliberately over canonical PAYLOADS, not heads — a second signature on an already-signed payload is not an EUF-CMA forgery (SUF/EUF trap caught in the self-audit pass before integration). - Policy separation as a deterministic lemma (per GPT B6's own suggestion), formal Definition 3, and Theorem 7: the construction is an accountable replay-distribution scheme. - Fixed-function SHA-256 handled per Rogaway's human-ignorance treatment (new citation, arXiv-API/DBLP/Springer-verified: VIETCRYPT, LNCS 4341, pp. 211-228, 2006 — note Rogaway's own page carries a 221- typo): every hash statement is an explicit reduction, the scheme-level continuation of the named-extractor discipline. - Games are non-interactive BECAUSE the operator-adversary holds the signing key (no secrets, no oracles) — stated in the section, mirroring the deployment's non-interactive verification. - Honesty anchored: scope remark + new coverage-table row (two- transcript comparisons and prefix transport are paper-level, not mechanized); Definition 2 re-badged informal with pointer; DGHS two-transcript lineage credited in related work. 19 pages, 0 overfull, suite 115 green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src/pacta_provider | ||
| pyproject.toml | ||
| README.md | ||
PACTA Proof Check Provider
This nested project is a prototype third-party proof-checking service. It reuses host Lean/Aeneas infrastructure, runs portable PACTA replay/audit checks, and emits signed attestation certificates.
It does not modify anything outside this repository. It may read configured toolchains such as /Users/oho/GitClone/ClaudeCodeProjects/your-lean-project/aeneas-toolchain/env.sh.
It can also maintain a local transparency log. The log is an RFC 9162-style Merkle accumulator over signed attestations. It emits Signed Tree Heads with Ed25519 today and records an ML-DSA/FIPS 204 signature slot as unavailable unless a real backend is present. Agents that require both signatures must reject such receipts.
Commands
PYTHONPATH=src:provider/src python -m pacta_provider discover
PYTHONPATH=src:provider/src python -m pacta_provider init-key --key-dir provider/state/demo-provider
PYTHONPATH=src:provider/src python -m pacta_provider check \
--config examples/repos.yaml \
--repo-name dalek-ed25519-verified \
--repo repos/dalek-ed25519-verified \
--provider local-pacta-provider \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.attestation.yaml
Transparency log:
PYTHONPATH=src:provider/src python -m pacta_provider log-init \
--log-dir provider/state/transparency-log \
--provider local-pacta-provider \
--public-key provider/state/demo-provider/provider.ed25519.pub
PYTHONPATH=src:provider/src python -m pacta_provider log-append \
--log-dir provider/state/transparency-log \
--attestation provider/out/dalek.attestation.yaml \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub \
--out provider/out/dalek.receipt.yaml
PYTHONPATH=src:provider/src python -m pacta_provider log-sth \
--log-dir provider/state/transparency-log \
--private-key provider/state/demo-provider/provider.ed25519.key \
--public-key provider/state/demo-provider/provider.ed25519.pub
The resulting certificate can be consumed by pacta with --attestation, --trust-attestation-provider, and --attestation-public-key.
The receipt can be consumed with --transparency-receipt, --transparency-log-public-key, and --require-transparency-receipt.
The private key must remain provider-side. Downstream agents only need the public key, the inclusion receipt, and a policy decision that the provider name/log key is trusted.