Skip to content

README.md

Latest commit

 

History

History
163 lines (117 loc) · 12.4 KB

README.md

File metadata and controls

163 lines (117 loc) · 12.4 KB
Raw

crypto-lab-threshold-mldsa

What It Is

This repository demonstrates the central threshold-signing question for post-quantum cryptography:

  • Can multiple parties cooperate to produce a single valid ML-DSA signature?
  • Can the verifier remain unchanged and still accept that signature under standard FIPS 204 verification?
  • Why is this harder than threshold Schnorr or threshold BLS?

The demo explores those questions with an educational two-party split-custody simulation (the genuine ML-DSA key is additively shared, then combined to sign) based on the current research direction. It illustrates the protocol shape honestly — it does not implement a real threshold scheme (see "What's Real and What's Simulated" below):

  • Trilithium — Dufka, Kravtsenko, Laud, Snetkov, ePrint 2025/675
  • Quorus — Borin et al., ePrint 2025/1163
  • TOPCOAT — 2024 two-party HighBits compression approach
  • Dufka–Kravtsenko identifiable aborts — ePrint 2025/871
  • del Pino–Prest unmasking TRaccoon — ePrint 2025/849
  • THED — ePrint 2026/638
  • Threshold Raccoon — Saarinen, EUROCRYPT 2024

A guided "Start here — a 5-stop path" strip sits at the top so a newcomer follows one intuition-building route (additive sharing → why it's hard → walk a round → watch the ideal → sign live) instead of landing on the dense research table first. The live UI includes five exhibits, plus three hands-on teaching widgets layered on top of the honesty framing:

  1. Why threshold ML-DSA is harder than classical threshold signatures — with an interactive "why aborts make it expensive" micro-demo that runs rounds until one is accepted and counts the coordinated restarts.
  2. An animated step-by-step protocol walkthrough with fixed SERVER / SHARED CHANNEL / PHONE lanes: as you advance a round, value chips physically travel from the party lanes into the channel — nonce shares into w, then w₁ high bits, the Fiat–Shamir challenge c, and the z-shares summing into z — with a live infinity-norm accept/reject check. The tiny numbers are computed with genuine toy modular / additive-sharing math (illustrative choreography, real arithmetic), and an on-screen honest caveat notes the two abstractions (w = y^S + y^P not A·y; challenge applied as a single scalar). Includes an inline glossary of the lattice jargon.
  3. Interactive two-party (split-custody) signing, with each step labelled real or illustrative, and two separate result indicators — Signature valid (green) vs Distributed-trust enforced (red) — plus a plain-language bridging sentence spelling out that both cards describe the same run (custody achieved, key-non-reconstruction not).
  4. A comparison table of the 2024–2026 threshold ML-DSA research landscape, with a glossary for the security column (UC, malicious, identifiable aborts, FHE-based, std compat).
  5. Real-world applications for post-quantum multi-party signing.

Two additional interactive panels make the honesty concrete: a live additive-share combiner (click to sum one real key byte's two shares mod 256) and an escrow-vs-ideal contrast experiment. The escrow view shows the full-key buffer light up red when combined; the ideal view is a playable animated sequence of what real threshold signing would look like — each party computes its own z^i = y^i + c·s₁^i locally, only the masked z-shares cross the channel, and only their sum z is published while the full secret-key buffer stays greyed out and is never assembled. It fills the "what it IS" gap next to the "what it is NOT" contrast.

This repo is educational, not production-safe. No threshold ML-DSA scheme is NIST-standardized as of 2026.

When to Use It

Use this demo when you want to:

  • understand why threshold lattice signatures are more complicated than threshold Schnorr or BLS
  • study the structure of a two-party ML-DSA protocol in a browser-only environment
  • see additive secret sharing applied to ML-DSA-flavored key components
  • compare the measured wall-clock cost of the combine-then-sign path against standalone signing
  • explain threshold post-quantum signing to engineers, students, auditors, or security teams
  • explore future design ideas for root CAs, validator networks, recovery flows, and enterprise approvals
  • Do NOT use this repository for production signing systems, HSM deployments, or compliance-sensitive infrastructure — it is a teaching demo.

Live Demo

systemslibrarian.github.io/crypto-lab-threshold-mldsa

A guided 5-stop "Start here" path leads newcomers through the material in intuition-building order. The live UI walks through five exhibits: why threshold ML-DSA is harder than classical threshold signatures (with an interactive rejection/restart micro-demo), an animated round-by-round protocol walkthrough with fixed party/channel lanes where value chips travel across the channel as you advance (every step labelled real or illustrative, with an on-screen honest caveat and a jargon glossary), interactive two-party split-custody signing with separate Signature valid / Distributed-trust enforced indicators and a plain-language bridge explaining they describe one run, a comparison table of the 2024–2026 threshold ML-DSA research landscape, and real-world applications for post-quantum multi-party signing. A live additive-share combiner and an escrow-vs-ideal contrast experiment — the latter a playable animation of the never-combine ideal path — make the key-non-reconstruction gap tangible. The math is genuine ML-DSA-65 from @noble/post-quantum, so every emitted signature verifies under the unmodified standard FIPS 204 verifier.

What Can Go Wrong

Threshold ML-DSA remains an active research area, and several practical issues remain:

  • No NIST threshold standard yet. Verifier compatibility exists in research papers, but the threshold protocols themselves are not standardized.
  • Rejection sampling compounds coordination cost. If a signing attempt is rejected, all parties must regenerate fresh randomness.
  • Communication overhead matters. Even efficient two-party designs exchange far more than standalone signing.
  • Malicious security is difficult. Semi-honest approximations are not enough for real-world adversaries.
  • Non-linear gadgets are tricky. HighBits, LowBits, MakeHint, and norm checks need careful MPC treatment.
  • Implementation pitfalls remain. Timing leaks, replay handling, message binding, transcript consistency, and abort accountability all matter.
  • This demo simplifies MPC internals. It is meant to teach the protocol shape and compatibility goal, not to serve as a hardened implementation.

Real-World Usage

If threshold ML-DSA matures and standardizes, likely deployment targets include:

  • post-quantum root CA protection across multiple HSMs or organizations
  • blockchain validator signing without single-node compromise risk
  • government and enterprise approval workflows with t-of-n control
  • social recovery and emergency access for long-lived user credentials
  • distributed randomness beacons and other collective authorization systems

For now, production systems generally use classical threshold schemes such as FROST or threshold ECDSA while tracking post-quantum migration plans.

A reasonable forward-looking timeline is:

  • 2026–2027: research consolidation and cryptanalysis
  • 2027–2028: possible draft threshold standards or profiles
  • 2028–2030: early production rollouts if the field stabilizes

How to Run Locally

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

Related Demos

What's Real and What's Simulated

A cryptography demo earns trust by being precise about its own limits. This one draws a hard line:

Real (standard FIPS 204):

  • Key generation, signing, and verification use @noble/post-quantum's ML-DSA-65.
  • The public key and every emitted signature are genuine and verify under the unmodified standard verifier.
  • All randomness comes from the Web Crypto CSPRNG — there is no Math.random anywhere in src/.
  • Additive secret sharing is real: each share on its own is uniform and reveals nothing about the secret.

Simulated (for teaching):

  • The round-by-round nonce / w₁ / challenge / z exchanges are choreography. They show the protocol's shape but do not produce the signature.
  • The round-by-round walkthrough (nonce / w₁ / challenge / z / secure norm check) shows the protocol's shape; it does not run real MPC and does not produce the signature. Each step is explicitly labelled real or illustrative.
  • To actually sign, the demo combines the two additive byte shares into the full secret key in one place and calls the standard signer. It therefore does not achieve real key-non-reconstruction — the central property a production threshold scheme must provide.

Bottom line: the ML-DSA math is real and the output is a valid FIPS 204 signature; the distributed-trust property is illustrated, not enforced. Closing that gap is the open research problem this lab exists to explain.

Stack

Browser-based educational demo of ML-DSA (NIST FIPS 204, the standardized post-quantum digital signature algorithm) held in two-party split custody. The app illustrates the shape of a Trilithium-style two-party signing flow, but the emitted signature is produced by combining the two additive byte shares of the genuine secret key in one place and calling the standard signer — so it still verifies with the unmodified ML-DSA verifier while being honest that it does not enforce key-non-reconstruction.

Stack: Vite + TypeScript strict + vanilla CSS + @noble/post-quantum/ml-dsa. No backends.

Verification

npm run build    # typecheck (tsc) + production build
npm test         # vitest crypto unit tests (KATs / round-trip / forgery-rejection)
npm run verify   # end-to-end verification suite (exits non-zero on failure)

npm test runs focused crypto unit tests: additive byte/polynomial sharing round-trips, that the recombined shares are bound to this public key (and that a foreign public key is rejected — the regression that guards the old share/key disconnect), that a single party cannot forge, forgery/tamper rejection by the standard verifier, and that no fabricated MPC byte counts leak into results. npm run verify additionally checks the no-Math.random rule and the honesty disclosures. build, test, and verify all run on every push and pull request via GitHub Actions (.github/workflows/ci.yml).

Repo Description

Browser-based educational demo of ML-DSA-65 (FIPS 204) in two-party split custody — the genuine secret key is additively shared between server and phone so neither party can sign alone, and combining both shares produces a signature that verifies with the standard verifier. It teaches the shape of Trilithium-style (2025) threshold lattice signing and explains why it is harder than classical threshold signatures. It does not achieve key-non-reconstruction: to sign, the two shares are combined in one place — closing that gap is the open research problem. Research status: no NIST threshold standard yet, expected 2027+.

Suggested GitHub Topics

cryptography
post-quantum
ml-dsa
threshold-signatures
distributed-signing
multi-party-computation
trilithium
lattice-cryptography
fips-204
mpc
browser-demo
educational
typescript
vite

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