Skip to content

Repository files navigation

crypto-lab-gg20-wallet

What It Is

GG20 Wallet demonstrates the GG20 threshold ECDSA protocol (Gennaro & Goldfeder, 2020) — the cryptographic foundation of institutional MPC custody used by Fireblocks, Coinbase MPC, and ZenGo. Threshold ECDSA allows t-of-n parties to jointly produce a standard ECDSA signature without any party ever holding the full private key. GG20 is significantly more complex than threshold Schnorr (FROST) because ECDSA's nonlinear nonce computation requires Paillier homomorphic encryption for joint computation. The protocol provides security against malicious adversaries with identifiable abort.

This is a faithful, runnable 2-of-2 implementation — not a mock-up. It performs real secp256k1 arithmetic (@noble/curves), real Paillier homomorphic encryption (1024-bit modulus), real MtA (multiplicative-to-additive) share conversion, the two Phase-5 consistency checks (Σ kᵢ·R = G and Σ σᵢ·R = X) that abort a deviating round before any sᵢ is released, and a real zero-knowledge range proof (the GG18/Lindell Σ-protocol) that demonstrably rejects the out-of-range value behind the MtA wraparound attack. The full private key x = x₁ + x₂ and the full nonce k = k₁ + k₂ are never reconstructed at any point: each party computes its own sᵢ locally and the signature is s = s₁ + s₂, verifiable as an ordinary secp256k1 signature. The core (src/gg20.ts) is covered by a 19-test suite (npm test) proving 25 random end-to-end signatures verify, MtA yields correct additive shares (including the step-through diagram's mtaTrace intermediates: α+β = a·b, and the homomorphic reply really decrypts to a·b+β′), the Phase-5 identities hold on honest runs and break under a cheating party, and the range proof accepts honest values while rejecting out-of-range ones and tampered proofs. Scaled down for the browser: Paillier key size, the Paillier–Blum modulus proof, the MtA discrete-log binding, and the ZK proofs that make the Phase-5 abort attributable rather than merely detected (all documented in Exhibit 7). The protocol logic is the genuine article.

On the abort verdict specifically: it is derived from the two Phase-5 point identities computed over that run's own values, not from knowing whether the "malicious Party 2" toggle was set. Flip the toggle and the identities are what change; the banner follows them. A test asserts the Phase-5 verdict and the final signature verification never disagree, so neither can quietly stand in for the other.

When to Use It

  • Institutional crypto custody requiring no single point of key compromise
  • Signing on secp256k1 chains (Bitcoin, Ethereum) without key assembly
  • Consumer wallets with device + server 2-of-2 signing
  • Any ECDSA application requiring threshold signing without on-chain multisig
  • New protocols where Schnorr is available — use FROST instead (simpler, faster, no Paillier requirement)
  • Non-secp256k1 curves where ECDSA is not required
  • Applications where on-chain multisig is acceptable (simpler to implement, though reveals threshold policy)
  • Do NOT use this for real custody — it is a scaled-down educational 2-of-2 demo, not an audited MPC custody system.

Live Demo

systemslibrarian.github.io/crypto-lab-gg20-wallet

A "Start here" 30-second guided path opens the page (with an inline symbols key glossing every Greek/algebraic term), followed by eight exhibits: why ECDSA threshold is harder than Schnorr threshold, Paillier homomorphic encryption as the core MPC primitive, GG20 distributed key generation with hash-commit-then-reveal, faithful threshold signing via MtA over Paillier — now with a step-through MtA diagram (a real, unit-tested conversion showing how a secret product a·b becomes two harmless additive shares α+β) and a two-column party diagram that places each signing value in the column of the party that holds it (so "no party holds the full key" is spatially obvious), plus a "malicious Party 2" toggle, a Phase-5 panel showing both consistency identities evaluated against the run's own values, and a 25-signature self-test — then security analysis, a runnable zero-knowledge range proof that catches the out-of-range/wraparound attack live (with a wraparound number-line showing the q³ fence that stops it, and all four verifier checks reported individually so you can see that only the range bound rejects the cheater), a walkthrough of the full identifiable-abort stack (what's implemented vs. described), and real-world deployments in Fireblocks, Coinbase MPC, ZenGo, and PayPal/Curv. Symbols are glossed inline throughout, and each exhibit includes a "What's real / what's simplified" disclosure.

What Can Go Wrong

  • Omitting the zero-knowledge range proofs. Several production GG18/GG20 libraries shipped without the required range/consistency proofs and were shown to leak or fully extract private key shares — the proofs are mandatory, not optional.
  • MtA wraparound / out-of-range inputs. If a party feeds out-of-range values into the multiplicative-to-additive conversion, it can bias the result; the range proof exists specifically to reject this.
  • Weak Paillier parameters. Too-small or improperly generated Paillier moduli (or a missing Paillier–Blum modulus proof) break the homomorphic step the protocol relies on.
  • Nonce / randomness failures. As with all ECDSA, predictable or reused nonce contributions can expose key material; the threshold setting adds more places for randomness to go wrong.
  • Mishandling abort and blame. Identifiable abort only helps if the implementation actually runs the type-5/7 blame phase; silently retrying after a malicious abort can mask an active attacker.

Real-World Usage

  • Institutional MPC custody — Fireblocks, Coinbase MPC, and ZenGo use threshold ECDSA so no operator ever holds a full signing key.
  • Consumer and enterprise wallets split signing across a user device and a server in a 2-of-2 arrangement, removing a single device as a single point of compromise.
  • Exchange and treasury signing on Bitcoin and Ethereum uses threshold ECDSA to avoid revealing the signing quorum on-chain (unlike script multisig).
  • secp256k1 blockchains generally benefit because the output is an ordinary ECDSA signature, so no chain-side changes are needed.
  • PayPal/Curv and similar platforms brought MPC-based key management into mainstream financial custody.

How to Run Locally

git clone https://github.com/systemslibrarian/crypto-lab-gg20-wallet
cd crypto-lab-gg20-wallet
npm install
npm run dev

Related Demos

Architecture

  • src/gg20.ts — the DOM-free cryptographic core: Paillier (Miller–Rabin keygen, encrypt/decrypt), MtA share conversion, GG20 DKG and signing. This is the single source of truth, imported by both the UI and the tests.
  • src/main.ts — the UI: rendering, state, and event wiring only.
  • test/gg20.test.ts — Node built-in test runner suite exercising the same module the browser runs.

Part of 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

About

Browser-based GG20 threshold ECDSA demo — Paillier encryption, distributed key generation, and joint signing without any party holding the full private key. The protocol behind Fireblocks and Coinbase MPC.

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages