Confirmer Signatures — Crypto Lab (Research Gate)

Current research status (2026-10-18): The real BLS12-381 workbench computes issuance, signer/confirmer confirmation, and a candidate affirmative inequality proof. The candidate correction argument now gives completeness, two-special-soundness and special honest-verifier zero knowledge for the specified prime-order protocol, supported by executable witness extraction. These are local research results, not an independently verified correction of the complete published DCS scheme. Full DCS security remains unestablished. The owner authorized a separate Advanced · Research Preview catalog card on 2026-10-18; that listing does not certify the complete scheme.

Catalog entry: Signature Gate is an Advanced research-preview demo under Public-Key & Signatures. The project entry URL opens the real-pairing workbench; the earlier ordinary-signature comparison and symbolic model remain available.

The visitor now becomes Bob: The real-pairing workbench has a four-step guided story, explicit commitment → challenge → answer controls, an altered-claim experiment, and Eve’s passing recording beside its rejection under a different challenge. Explore mode opens all experiments; the evidence view provides public transcript downloads and the review packet.

Reproducible verification: A separate Python/py_ecc verifier checks the same public transcripts using a different cryptographic library. CI reproduces fixed vectors, checks polynomial identities and 100,972 small-field extraction cases, tests tampering and verifies actual browser exports. This is not independent expert review or a machine-checked full security proof.

Kernel-checked mathematics: The Lean 4 proof project proves completeness, explicit witness extraction and OR two-special-soundness in a field model, including the crucial nonzero denominator. It also proves the exact joint honest-branch sampling distribution. Fourteen declarations pass a restricted axiom gate; Pages publication now requires that proof check on the same commit. Concrete BLS12-381/code refinement, the full OR distribution and full DCS security games remain outside the formalization.

Security repair: Proof work exposed a vacuous subgroup check: reducing the group-order exponent to zero let an order-two element support a false denial of a valid signature for even challenges. The verifier now uses raw subgroup exponentiation and validates group membership. The new regression reproduces that attack and requires rejection. This is why passing honest examples alone was insufficient.

Designated-verifier proofs (A-D-09): The real-pairing workbench now has a fifth chapter implementing the non-interactive designated-verifier proof of Jakobsson, Sako and Impagliazzo, EUROCRYPT '96, LNCS 1070, pp. 143–154, §5. The same verifier accepts a proof made by the signer or confirmer with the branch witness and a proof the visitor forges with the secret behind their own verifier key. From the transcript alone, an outsider therefore cannot establish statement truth or proof origin; the visitor can even produce an accepting proof of a statement Alice never signed. A separate publicly verifiable Fiat–Shamir proof of the same relation supplies the transferability contrast, and neither verifier accepts the other's proofs. Any reader can recompute that public proof's equations, but this lab supplies no proof-of-knowledge or soundness theorem for it. The two designated-proof origins are shown to be exactly interchangeable on a true statement through the bijection that maps prover randomness to simulator randomness, checked by reproducing proofs byte for byte rather than by sampling. A separate py_ecc implementation recomputes every equation, and eight source mutations are each killed by their own named test in CI. Scope, the random-oracle model, and all six deviations from the printed construction are recorded in DESIGNATED-VERIFIER.md. This is Definition 1, not the Appendix's strong designated verifier, and it changes nothing about the open full-DCS obligations.

Reading the history below: Earlier symbolic and 2016-oriented experiments remain available, but they are separate constructions. Current real-pairing claims and remaining obligations are recorded in the security ledger.

New source-specific research, kept separate from the 2016 construction: XIA2013-UNIFIED-CONFIRMATION.md documents the signed-ElGamal/BLS-shaped issuing algebra and both interactive OR-confirmation diagrams from Xia's 2013 Chapter 5. The working browser workbench computes each value, samples Bob's challenge after the prover commits, and verifies public equations, including altered-message failures. It uses exponent-visible symbolic groups (not a real pairing), so its keys are openly recoverable and it proves no zero knowledge or non-transferability. The printed affirmative disavowal diagrams contain an apparent non-identity inconsistency requiring source review; the symbolic path is not a secure disavowal implementation; the separate real-pairing candidate and its proof argument are linked above. This symbolic research does not complete the 2016 DCS; the catalog card describes the separately scoped real-pairing research preview.

New live challenge: The symbolic workbench now has a “Can Eve fool Bob?” experiment. The visitor predicts the outcome, makes Eve fabricate a false proof after choosing the challenge, inspects the independent five-equation check, then forces a different verifier challenge and watches it reject. Source-backed explanation. The symbolic proof arithmetic is genuine, but the model deliberately exposes its discrete logs and cannot be presented as a secure DCS.

Mathematical research gate: An exhaustive check of all 1,018 nonzero toy keys now demonstrates that the literal text-extracted disavowal factor in Xia 2013 Figures 5.3–5.4 is always the identity despite a non-identity requirement. Typeset thesis Figures 5.3–5.4 have now been visually checked and contain the same contradiction; author/erratum reconciliation remains open. Disavowal figure audit. Real pairing groups and the local inequality proof are now implemented separately. Full malicious/concurrent-verifier zero knowledge and DCS non-transferability remain unestablished.

Visitor experience: Signature Gate — Become the verifier. Alice signs a fictional agreement, Carol or Alice answers Bob’s challenge, and Eve demonstrates how an equation-valid recording can be fabricated. The workbench separates signature validity, affirmative inequality evidence, challenge timing and the truth of a signed statement. Full controlled-verification security remains a research obligation.

Working parts of the actual protocol research: The issuing experiment now constructs a Pedersen-style commitment, signs that commitment using real WebCrypto ECDSA, encrypts its opening separately for signer and confirmer, and checks a partial initial π0 equality proof. The toy issuer-to-confirmer protocol then has either signer or confirmer independently decrypt the opening and engage a public-only verifier in a genuine three-message, seven-equation arithmetic exchange. Its verdict is explicitly TOY_EQUATIONS_HOLD, not DCS confirmed. All operations run; their security parameters are intentionally broken. The source/negative-claim matrix documents exactly what is still required for real confirmation, affirmative disavowal, soundness and non-transferability.

Research progress: Fubiao Xia's 2013 doctoral thesis, a closely related full-verification DCS construction by a coauthor of the 2016 paper, supplies explicit labeled-encryption, confirmation and disavowal formulas. We have implemented and locally tested the intentionally insecure n=253 Camenisch–Shoup-style labeled encryption arithmetic in research/cs-paillier.mjs. The new research-only π0 equality subproof implements the displayed Fiat–Shamir response/recomputation relation from thesis §6.5.2 over the same trivially factorable toy group. Its independent tests also demonstrate that the subrelation alone does not bind a message commitment ψ or verify the complete ciphertext label/tag. See research/PI0-RELATION.md and research/THESIS-EQUATIONS.md for exact formulas and blockers. The new toy π1 witness-relation checker evaluates seven separate source-defined arithmetic equations, plus independently checks a labeled decrypt; its arguments include the private witness and therefore it is not a proof, interactive confirmation, or DCS. See research/PI1-WITNESS-RELATION.md for the exact boundaries. The four-branch research-only disavowal inspector evaluates the four invalidity predicates outlined in Camenisch–Shoup §7.3, including the important difference between a malformed ciphertext and an affirmative invalidity proof. It is handed the decryption key and does not generate an interactive OR proof, exact interval proof, or non-transferable transcript. The documents why those are required. Original research suites covered (9 ECDSA baseline, 8 labeled-encryption, 12 toy π0, 9 toy π1 witness relations, 11 disavowal diagnostics). The current integrated issuer/protocol and security-regression suites now execute , plus , with separate actual Chromium desktop/mobile flow tests; see GitHub Actions for the checked count.

New arithmetic milestone: research/pi1-interactive-toy.mjs implements a thesis-derived three-move toy π1/π2 relation: seven equations checked by a public-only verifier after a fresh two-bit challenge. The limitation report explicitly demonstrates why accepting those equations is not a designated-confirmer signature verification, including a zero-challenge counterexample and replay. The source's strict range condition, a concurrent-ZK compiler, a full issuance certificate, and affirmative disavowal remain unimplemented. The visitor-facing Chapter 02 stays locked.

New negative control: the demonstrator's tiny encryption generator has order only 5, so a different label can alias under the same modular exponent despite changing the hash. The research tests intentionally show the verifier accepting that toy relation under an altered label. This is why we cannot claim production-strength label binding or a sound designated confirmer proof.

Two-challenge research finding: pi1-special-soundness.mjs demonstrates that reusing the SAME proof commitment with different verifier challenges lets an observer recover the toy decryption key exponents and hidden opening from the public response differences. Documented negative controls include fresh-mask behavior, challenge validation and misleading zero-challenge acceptance. This teaches a genuine algebraic failure mode but is NOT evidence of a completed DCS protocol. None of this research Node code is included in the ordinary-signature web preview.

This repository records the development brief and the cryptographic selection gate for a proposed interactive lab on designated confirmer signatures. Genuine confirmation and disavowal protocols must come from a reviewed, published construction and pass independent mathematical checks. A normal signature hidden by encryption is not automatically a designated confirmer signature.

• Chapter 01 — ordinary signature research preview — a separately gated Pages preview of ONLY the P-256/SHA-256 public-signature comparison, Bob/Dave verification, and tamper experiment. It is not a designated confirmer signature. The deployment checks a live source-SHA marker; if GitHub Pages has not been enabled or if deployment fails, use the GitHub source and check the workflow. Tests: node --test tests/baseline.test.mjs, plus GitHub Actions desktop/mobile browser checks.
• PRODUCT-VISION.md — intended visitor journey, educational outcome, interaction flow, and go/no-go criterion.
• SCHEME-NOTES.md — the five-part issued-object inventory confirmed in both the 2013 thesis and the detailed 2016 paper. Complete 2016 proof equations, security assumptions and disavowal remain unverified.
• research/SOURCE-RECONCILIATION.md — explains why the final 2016 paper does include π0 despite an abbreviated introduction, and what mathematical-security discrepancies remain unresolved.
• brief.md — required full build and teaching brief.
• RESEARCH-GATE.md — scheme-selection prerequisites, literature and acceptance criteria.
• Crypto Lab master template — binding Build → Teach → Look → Accessibility → README → Deploy standard, to apply after research passes.

Non-goals for this stage: claiming designated-confirmer signature correctness, presenting simulated proofs as genuine, deploying unfinished DCS as a complete lab, or presenting its research-preview card as approval of the complete scheme. Publishing the explicitly scoped ordinary-signature, symbolic and real-pairing research previews is permitted and is not evidence that the full DCS research gate passed.

---

One of the proposed exhibits for the Crypto Lab suite.

"So whether you eat or drink or whatever you do, do it all for the glory of God." — 1 Corinthians 10:31