Security and trust model

This page documents integration-level security expectations. It supplements but does not replace ProveKit’s audit, the formal proof-system specification, or your own production-readiness review; use it to decide where artifacts live, who may generate them, and which checks must run before accepting a proof.

Pin v1 for production

The v1 branch is the current stable, audited release. The main branch is the rolling-development line and may change proof, key, or recursive-verifier formats between commits. Pin a release tag or the v1 branch for any user-facing workflow, and walk through the production checklist before shipping.

Trust boundaries

Boundary	What crosses it	Required control
Circuit authoring → key preparation	Noir source, hash choice	Code review, pinned commit, reproducible command line.
Key preparation → prover runtime	.pkp	Access control, integrity checks, recorded provenance.
Prover runtime → verifier runtime	proof.np / proof JSON and public inputs	Verification with the matching .pkv; public-input review.
Verifier runtime → application decision	Boolean validity plus decoded public inputs	Application-level authorization and policy checks.
Recursive export → Go/gnark wrapper	params_for_recursive_verifier, r1cs.json	Regenerated from the exact verifier/proof pair; setup keys managed explicitly.
Untrusted client → verifier server	pkvUrl, r1csUrl, proof JSON	Restrict artifact URL sources or proxy downloads through trusted storage; tune VERIFIER_* concurrency and timeout limits.

What verification proves

A successful ProveKit verification means the proof is valid against the verifier key and public-input binding presented to the verifier. It does not tell your application what to do with that proof.

Your application still owns these decisions:

• Whether a user is allowed to submit a proof for a given account or session.
• Whether public inputs match the expected credential, nullifier, domain separator, or request ID.
• Whether the proof / key / artifact version is still accepted by the service.
• Whether replay protection or one-time-use semantics apply.

Cryptographic assumptions

ProveKit’s security rests on different assumptions for the base proof and the optional recursive wrapper. Treat them separately when modeling threats.

Layer	Underlying primitives	Quantum-resistance
Base WHIR proof	Hash-based polynomial commitment scheme (WHIR) + Spartan-style sumcheck. Security reduces to the chosen hash’s collision resistance.	Post-quantum secure under conjectured hash-function PQ-security. Grover’s algorithm imposes a quadratic speedup on preimage finding, so 256-bit hashes retain ~128-bit security against quantum adversaries.
Recursive Groth16 wrap	Pairing-based SNARK over BN254. Soundness reduces to the q-PKE (q-Power Knowledge of Exponent) assumption on pairings.	Not post-quantum secure. Shor’s algorithm breaks discrete-log on elliptic curves; any Groth16-wrapped proof is vulnerable to a sufficiently capable quantum attacker.

If post-quantum security is part of your threat model, scope on-chain settlement carefully: verify the base WHIR proof off-chain (post-quantum secure path) rather than relying on the Groth16 outer proof for cryptographic guarantees. The wrapper is appropriate for cost-efficient EVM verification, not as a long-term cryptographic anchor.

Sensitive material

Material	Sensitivity
Private witness inputs	Sensitive by default. Keep out of logs and client-visible telemetry.
.pkp prover keys	Operationally sensitive; they enable proof generation for the prepared circuit.
.pkv verifier keys	Usually distributable, but always integrity-protected and versioned.
Proofs	May carry public inputs and metadata that are sensitive in your application context.
Recursive proving keys	Only relevant when using the Groth16 recursive wrap. Manage the trusted-setup proving and verifying keys explicitly; development-time generation is not sufficient for production. The base WHIR proof needs no trusted setup.

Operational controls

The controls that are specifically security-shaped — for the broader pre-launch checklist, see Production checklist.

• Review public inputs with show-inputs --hex for byte-exact comparison before accepting a proof.
• Reject proofs whose provenance is unknown or spans multiple generations.
• Restrict verifier-server artifact URLs to trusted sources, or proxy downloads through trusted storage.
• Keep private witness values, prover keys, and proofs out of logs, telemetry, and crash reporters.

Red-team prompts for reviewers

Ask these questions during every integration review:

1. Can a client choose the .pkv, r1cs.json, proving key, or verifying key used by a verifier service?
2. Are public inputs bound to the correct account, session, chain, domain, or request?
3. Can a previously valid proof be replayed after a policy or circuit change?
4. Could artifacts from a different branch, commit, or hash configuration be accepted by mistake?
5. Are witness values, proofs, or prover keys logged anywhere (CLI wrappers, web servers, mobile crash reporters)?