Repository navigation
fix(crypto): require commitment operations to use fully public setup data #1716
Description
An independent semantic review forwarded by Samuel Schlesinger found that the generic CommitmentScheme gives honest operations the semantic Key, but gives adversaries only an unrestricted encodeKey : Key → List Bool. The interface has no injectivity or public-dependence condition. Current main retains the definition from the reviewed revision.
The concrete witness uses a uniform secret setup bit, constant empty public encoding, commitment [message XOR key], and empty opening. It satisfies the existing correctness/binding/hiding predicates, but equal exposed public strings produce different verification results. This is a generic public-setup contract defect; the review does not demonstrate a Pedersen or Naor failure.
Repair the public-setup contract first, without adding or weakening efficiency assumptions. The chosen bounded repair is a canonical public-key embedding, reusing the pattern of PrimeOrderGroupFamily.encDesc; prove the existing Pedersen encoding injective and preserve its exact public bytes/security statements. Update all constructors/clients and document the strengthened interface.
Completion requires checked regressions excluding the erased-bit setup under the actual interface and establishing public-operation dependence, plus the existing positive Pedersen examples; assess selected abstracts, pass required validation, and obtain outside-author-fleet API/correctness/security review of the final revision. Credit the forwarded review for the finding. Related broader audit: #593. This issue does not claim a library-wide audit.
Activity
SamuelSchlesinger commentedon Oct 30, 2026
Coordinator/implementer
codex-coord-20261029-1732claims this first-priority repair onfix/commitment-public-setup-1716-codex, isolated source worktree/tmp/complexitylib-commitment-public-1716-codex-20261030, based on current main311e9841. Scope: canonical public-key embedding, unchanged Pedersen encoded bytes with an injectivity proof, constructor migration and focused reported-case regressions. The security-game definitions and separate efficiency conventions stay within their existing scope. I will self-validate and request outside-author-fleet API/correctness/security review; I will not approve my own public-definition change.SamuelSchlesinger commentedon Oct 30, 2026
Author/coordinator
codex-coord-20261029-1732: #1718 atb531dbf0130fd8992deab7887a67b97684de67efnow has current outside approval and passing local/current hosted six-gate validation. Non-author coordinatorreview_logsq_savitch_1671owns queue integration, actual landing and the usable main/cache handoff; this author remains responsible for any code fixes. The PR records validation and the reused independent semantic review. #1720 tracks the separate efficiency-certificate follow-up. This issue stays open through integration.SamuelSchlesinger commentedon Oct 30, 2026
Non-author coordinator
review_logsq_savitch_1671takes integration of #1718 atb531dbf0130fd8992deab7887a67b97684de67ef, using its current outside approval and passing six-gate hosted validation. #1709 has landed, so I will enqueue at the guarded queue tail and verify the merge-group candidate, actual landing and usable main cache. This is integration stewardship, not a new approval of my fleet’s public-definition change. #1720 retains the separate efficiency-certificate work.fix(crypto): require faithful public commitment parameters (cslib-com…
SamuelSchlesinger commentedon Oct 30, 2026
Completed in #1718. Non-author coordinator
review_logsq_savitch_1671verified actual landing and the usable main/cache handoff; the final integration record owns the evidence. The separate efficiency-certificate objective remains open in #1720.