proof-aware-crypto-tooling-.../provider
mrwulf b7c8c58529 paper: depth pass to IACR standard (no padding) — 14->17pp
Not size for its own sake; each addition is a definition, proof, figure,
or measurement the genre expects and the rejection implied:
- §2: the signature apex given real depth — the four tiers stated as an
  explicit lifting ladder T1-T4 (byte apex -> canonical half-lift ->
  injectivity/point-eq via non-square d -> constructive full lift), each
  naming the one new mathematical fact; the corpus's actual achievement,
  previously an appendix bullet list
- §4: scheme-syntax Definition (KeyGen/Append/ProveIncl/VerifyIncl/
  ProveCons/VerifyCons/Verdict) in DGHS style, so the goals name real
  algorithms; new subsection making the observation-not-verdict /
  requirements-card idea explicit (the system's distinguishing claim)
- §5.3: the consistency verifier DEFINED (recursive ConsRec form),
  closing the gap where Theorem 3 previously reasoned about an
  undefined verifier — differential-tested == deployed RFC verifier on
  5508 cases (honest + 4 mutation classes, n<=256)
- §6: Theorem 3 now a FULL proof (was a sketch), factored through a
  shared Lemma 2 (Root binding) that both soundness theorems use
- §8: Figure 1 (the twelve-leaf tree w/ grey failure leaves + 3-run
  braces) reinstated and improved; Table 1 (per-fork files/boundary/
  diff/hash-shape) replacing a prose paragraph
- App D slimmed to the verbatim Lean theorem-name mapping (no longer
  duplicates §2)
Both recursive verifiers regression-tested against deployed code. 102
tests green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-09 19:27:13 +02:00
..
src/pacta_provider paper: depth pass to IACR standard (no padding) — 14->17pp 2026-07-09 19:27:13 +02:00
pyproject.toml add nested proof check provider 2026-07-03 13:03:58 +02:00
README.md add transparency log trust provider 2026-07-03 14:09:34 +02:00

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.