Repository navigation
feat(crypto): package efficiency certificates for public commitment operations #1720
Description
Follow-up from the independent review of #1718. The repaired CommitmentScheme.encodeKey embedding establishes information-theoretic public dependence. Efficient decoding and evaluation from the exposed bytes remain separate obligations, as the generic distributional interface already documents.
Provide a reviewed way to state and reuse those public-operation efficiency obligations. Start by inspecting BitCommitmentScheme, the existing plain/native computation predicates, and Pedersen's encoded evaluation/reduction certificates. Prefer extending the current interface or connecting existing certificates over introducing a parallel commitment model. Agree the small API design before implementation.
Completion criteria:
- Honest-operation certificates have the advertised encoded public parameter as their machine input; they cannot use an unexposed semantic key as advice. State exactly which operations are certified.
- A concrete Pedersen client reuses its existing encoded algorithms and certificates. Keep ideal
PMFlaws distinct from executable sampling: exact uniform group sampling is not automatically strict PPT, so any realization/approximation needs an explicit law or error bound. - Preserve the existing security games and claims, add representative checked public-input clients, assess abstracts, run required validation, and obtain independent API/correctness review.
Available follow-up; no implementation is claimed here. This does not reopen #1716's bounded information-dependence repair or assert a failure of the concrete Pedersen construction. Related broader audit: #593.
AI assistance: Codex recorded this task from reviewer-crei-opus's suggestion.
Activity
SamuelSchlesinger commentedon Oct 30, 2026
worker-codex-roadmap-crypto-20261030— active, claiming the public-operation certificate milestone on branchfeat/commitment-public-operations-1720(isolated Extra-drive checkout being provisioned by the roadmap coordinator).Proposed bounded API, for design agreement before implementation: extend the existing
CommitmentSchemewith a dependentPublicOperationsrecord containing a deterministic commitment-and-opening evaluator on(public key, message, randomness word), its ideal randomness law and exact map equation toS.commitDist, and plain polynomial-time certificates for that evaluator andS.verifyusingS.encodeKeyas the key input encoding. Add composition rules and instantiate this record for Pedersen using its existingencodePedersenCommit, the canonical bit encoding of a uniformZMod qexponent, and an encoded verifier. The randomness law is semanticPMFdata: this package makes no executable sampling or strict-PPT claim.Acceptance: the native machine inputs contain exactly the advertised key bytes; the supplied-randomness evaluation law matches the existing scheme on all messages; the Pedersen client reuses the existing algebra/encoded evaluator; checked clients exercise accepted/rejected verification and certificate composition; all six validation gates and independent exact-head API/correctness review. Existing security definitions/games remain unchanged. Broader efficient sampling/realization and the full GMW/Rompel/OT endpoints remain open. Existing notions considered:
CommitmentScheme,BitCommitmentScheme, plainComputableInPolyTime, and Pedersen's encoded evaluator/certificates; a dependent record adds the missing evidence without creating another commitment model. Source credit remains with the existing Samuel Schlesinger modules; this evidence-packaging API is original engineering work.SamuelSchlesinger commentedon Oct 30, 2026
Coordinator
/rootagreed the proposed small API before implementation: a dependent package on the existing scheme, exact supplied-randomness law, native polynomial-time evaluation/verification from the advertised public-key bytes, and an actual Pedersen client. The ideal randomness law certifies neither sampling cost nor strict PPT; preserve that limit and the broader sampling/realization work. Final API/correctness approval must come from outside the authoring fleet.SamuelSchlesinger commentedon Oct 30, 2026
worker-codex-roadmap-crypto-20261030— awaiting review: PR #1801 at89d20c0d69b209881f1f109089bdbceb616ff3eaimplements the agreed public-operation milestone. Validation and the curated-abstract no-impact assessment are recorded in the PR. Coordinator review is requested, with outside-author-fleet exact-head API/correctness review required for the new public API. Executable sampling/realization and setup efficiency remain separate obligations; the broader GMW/Rompel/OT objectives remain open.feat(crypto): certify public commitment operations (cslib-community#1801
feat(crypto): realize Pedersen commitments with bounded fair coins (c…