https://github.com/systemslibrarian/crypto-lab-zk-proof-lab

Browser-based zero-knowledge proof lab — six exhibits from Ali Baba cave to zk-SNARK. Real Schnorr arithmetic, SHA-256 commitments, transcript replay, and deterministic scenario presets. No framework, no backend.
https://github.com/systemslibrarian/crypto-lab-zk-proof-lab

commitment-schemes crypto-compare fiat-shamir interactive-proofs schnorr-protocol sha256 webcrypto zero-knowledge-proofs zkp

Last synced: 9 days ago
JSON representation

Browser-based zero-knowledge proof lab — six exhibits from Ali Baba cave to zk-SNARK. Real Schnorr arithmetic, SHA-256 commitments, transcript replay, and deterministic scenario presets. No framework, no backend.

• Host: GitHub
• URL: https://github.com/systemslibrarian/crypto-lab-zk-proof-lab
• Owner: systemslibrarian
• Created: 2026-04-03T00:57:33.000Z (3 months ago)
• Default Branch: main
• Last Pushed: 2026-04-11T13:09:00.000Z (2 months ago)
• Last Synced: 2026-06-01T23:24:48.668Z (17 days ago)
• Topics: commitment-schemes, crypto-compare, fiat-shamir, interactive-proofs, schnorr-protocol, sha256, webcrypto, zero-knowledge-proofs, zkp
• Language: HTML
• Homepage: https://systemslibrarian.github.io/crypto-lab-zk-proof-lab/
• Size: 1.3 MB
• Stars: 0
• Watchers: 0
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# ZK Proof Lab

[![Deploy GitHub Pages](https://github.com/systemslibrarian/zk-proof-lab/actions/workflows/pages.yml/badge.svg)](https://github.com/systemslibrarian/zk-proof-lab/actions/workflows/pages.yml)

[Live Demo](https://systemslibrarian.github.io/zk-proof-lab/)

## 1. What It Is

ZK Proof Lab is an interactive educational demo for zero-knowledge proof workflows, with conceptual exhibits (Ali Baba Cave, Graph 3-Coloring ZKP, zk-SNARK intuition) and cryptographically real primitives in the browser (`Schnorr Identification Protocol`, `Hash Commit-Reveal` with `window.crypto.subtle.digest('SHA-256', ...)`, and `Fiat-Shamir (Non-Interactive)`). It addresses the problem of proving knowledge or correctness without disclosing the secret witness. The security model shown in code is primarily honest-verifier ZK for the interactive proofs, plus hash-based binding/hiding for commitments, with explicit notes where the exhibit is pedagogical rather than production hardened. It is a teaching lab, not an audited cryptographic library. Parameters are intentionally small in the real-math exhibits for traceability and UI clarity.

## 2. When to Use It

- Use it for onboarding engineers to zero-knowledge protocol flow because the exhibits show the full transcript lifecycle (commitment, challenge, response, verification) with inspectable values.

- Use it in interviews or classroom demos when you need concrete Schnorr and commit-reveal mechanics in a browser, since the implementation uses real BigInt modular arithmetic and Web Crypto SHA-256.

- Use it for replayable protocol walkthroughs when deterministic scenarios matter, because the scenario preset and transcript lab pages let teams compare runs and reason about verifier outcomes.

- Use it to explain why Fiat-Shamir removes interactivity, because the dedicated exhibit derives the challenge from hashing transcript inputs and verifies the resulting non-interactive proof.

- Do not use it for production security decisions, because the project explicitly uses toy parameters and pedagogical models (especially cave/graph/snark intuition) rather than deployment-grade cryptographic hardening.

## 3. Live Demo

Live demo: https://systemslibrarian.github.io/zk-proof-lab/

The demo lets users run six exhibits, execute protocol rounds, simulate cheating behavior, and inspect verification outcomes and logs. It includes real `Run Protocol`, `Simulate Cheat`, `Submit Bids`, `Reveal Bids`, replay, and reset controls, plus explicit toy-vs-production parameter tables (for example `p = 2053`, `g = 5`, and challenge range in the Schnorr exhibit). The project does not provide encryption/decryption flows; it focuses on identification proofs, commitment verification, and transcript-based verification.

## 4. What Can Go Wrong

- Reusing Schnorr nonces (`r`) can leak the secret (`x`) from two transcripts, which breaks the core secrecy guarantee of identification proofs.

- Using small or weak group parameters makes discrete-log attacks practical, so a verifier equation that passes in the toy demo would not imply real-world security.

- Omitting transcript/domain separation details in Fiat-Shamir challenge derivation can enable replay or malleability across contexts, undermining non-interactive soundness assumptions.

- Reusing or biasing commit-reveal nonces weakens hiding and can leak bid information before reveal, defeating fairness of the commit phase.

- Failing to enforce reveal windows in commit-reveal protocols allows strategic non-reveal (griefing), which is a protocol-level failure even when hash checks are correct.

## 5. Real-World Usage

- Bitcoin Taproot (BIP340): uses Schnorr signatures over secp256k1 for key-path spends and signature aggregation-friendly design.

- MuSig2 and related multisignature constructions: build threshold/co-signing workflows on Schnorr-style signing equations and nonce commitments.

- Zcash Sapling/Orchard proving systems: use Fiat-Shamir style transcripts to make zk proofs non-interactive in the random-oracle model.

- PLONK-family proving systems (including Halo2-style transcript designs): derive verifier challenges via Fiat-Shamir hashing of commitments and transcript state.

- Commit-reveal workflows in blockchain applications (sealed-bid auctions, name-registration schemes): use hash commitments first and delayed reveal to prevent premature disclosure and last-moment changes.

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