aere-contracts/contracts/mpc/THRESHOLD_PQC.md
Aere Network acac2f00a6
Some checks failed
contracts-ci / Install (lockfile) → compile → full test suite (push) Has been cancelled
contracts-ci / Ethereum interop (EIP-2537 BLS, prague hardfork) (push) Has been cancelled
contracts-ci / PQC known-answer tests (NIST vectors) (push) Has been cancelled
contracts-ci / Coverage (scoped, with artifacts) (push) Has been cancelled
The unpublished line of work joins the sanitized public line
The published line and the local line had no common ancestor: the public one
carried the redaction pass, the local one carried three weeks of corrections
that never shipped. This commit ports the local work onto the public line,
keeps every public redaction, and extends the same discretion to seven client
mentions that were still named in published comments.

Carried: LICENSE year and LICENSING.md; the measured burn figures replacing
the deflation claim (the vault holds ~0.137 AERE of 2.8 billion, and burn is
a share of validator coinbase revenue, which is zero today); 'audited' removed
from next to Bouncy Castle; citation paths rewritten to published form with
CITATIONS-UNRESOLVED.md remeasured 2026-08-11; VERIFY-POLICY.md; slashing and
ownership comments brought down to what the code does; the AerePyth repair;
the shutter test helper the tests cite; runnable package.json entries; the CI
file split into a GitHub/Gitea twin pair with a real measured test-run status;
and the .gitignore hardening written after a compiled artifact leaked a local
path in a sibling repository. A false '2-of-3 multisig' description of the
owner account is corrected to what the chain measures: an externally owned
account. The self-audit findings catalog stays unpublished pending an explicit
decision.
2026-08-15 13:59:30 +03:00

87 lines
5.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Threshold PQC on AERE, honest maturity assessment
Scope: can we make the MPC/TSS custody committee **post-quantum**, i.e. produce a *threshold*
ML-DSA (Dilithium) / Falcon / SLH-DSA signature where no single party ever holds the whole
PQC key? This document states, bluntly, where that is today. **Nothing in this repo implements
threshold PQC. It is not claimed to work.**
## TL;DR
| Layer | Status on AERE today | Threshold (t-of-n) variant |
|---|---|---|
| ECDSA (secp256k1) group signing | shipped here (`AereThresholdRegistry` + `sdk-js/src/mpc`) | **mature protocols exist** (GG20/CGGMP21, DKLs23); non-reconstructing signer is delegated to an audited lib, not reimplemented |
| ML-DSA-44 verify | LIVE precompile `0x0AE3` (single-key only) | **research**, no standard, no audited production lib |
| Falcon-512 / 1024 verify | LIVE precompiles `0x0AE1/0x0AE2` (single-key) | **research, hard**, Gaussian sampling resists thresholding |
| SLH-DSA-128s verify | LIVE precompile `0x0AE4` (single-key) | **effectively N/A**, stateless hash-based, thresholding is impractical |
The five PQC precompiles verify **ordinary, single-signer** PQC signatures. They have nothing
to do with the threshold construction and do not make it post-quantum.
## Why threshold ECDSA works but threshold PQC does not (yet)
Threshold ECDSA succeeds because the *verification* equation is unchanged: a t-of-n signature
is a normal `(r,s,v)` under one group key. All the difficulty is confined to *signing*
(multiplying two shared secrets `k` and `x`), solved by MtA/OT sub-protocols. The lattice
schemes are harder to thresholdise at the signing step, for scheme-specific reasons:
- **ML-DSA / Dilithium (FiatShamir with aborts).** Signing samples a masking vector `y`,
computes `z = y + c·s`, and **rejection-samples**: it *aborts and retries* when `z` leaks
information about the secret `s`. Distributing this is an open problem: the parties must
jointly sample `y`, jointly run the abort check without revealing partial `z`, and bound the
noise growth from summing shares. Academic constructions exist (e.g. CozzoSmart style
MPC-Dilithium, and 20232024 threshold-Raccoon / threshold lattice-signature papers using
Raccoon which was *designed* to be thresholdisable), but:
- Threshold-friendly schemes like **Raccoon are NOT ML-DSA**, different scheme, not
NIST-FIPS-204, and not one of AERE's precompiles. A Raccoon threshold signature would need
a *new* verifier, not `0x0AE3`.
- No audited, maintained production library produces a **FIPS-204 ML-DSA** signature from
distributed shares. NIST is only now (20242025) exploring a threshold call; there is no
standard.
- **Falcon (hash-and-sign over NTRU with Gaussian sampling).** Signing requires **discrete
Gaussian sampling over a lattice with the secret trapdoor**. Distributing trapdoor sampling
without leaking the basis is notoriously hard; Falcon's own authors flag thresholding as
difficult. There is no practical t-of-n Falcon.
- **SLH-DSA / SPHINCS+ (stateless hash-based).** A signature is a large Merkle/one-time-key
authentication path. There is no algebraic structure to share; you would essentially need
generic MPC over the whole hash-tree signing circuit, impractical (huge SLH-DSA signatures,
hash circuits in MPC). Treat as not-applicable for thresholding.
## What IS honestly available for post-quantum custody today
Threshold PQC is not the only route to quantum-resistant *custody*. Honest, shippable options:
1. **Hybrid, not threshold.** Keep the t-of-n **ECDSA** committee (this repo) for the
distributed-trust / no-single-point-of-failure property, and additionally require a
**single-key PQC co-signature** (ML-DSA-44 via `0x0AE3`) from a separate quorum device, so a
quantum attacker must break *both* ECDSA *and* ML-DSA. This is real today: it composes
`AereThresholdRegistry` with the existing `AerePQCKeyRegistry` / precompiles. It does **not**
give you a *threshold* PQC key, the PQC key is single-party, so it trades one property
(distributed PQC key) for another (defence-in-depth). Label it honestly as hybrid, not
threshold-PQC.
2. **Threshold of independent PQC signers (k-of-n multisig, not TSS).** n parties each hold
their **own** ML-DSA key; a policy contract accepts when ≥ t *distinct* PQC signatures
verify. This is a genuine on-chain **multisig** (each precompile call is independent) and is
quantum-resistant *and* distributed, but it is an m-of-n **multi-signature**, not a single
compact **threshold** signature, and the on-chain cost is t precompile verifications, not
one. This is buildable today on AERE and is the most honest "distributed PQC" you can ship
now. It is out of scope for this task (which targets threshold ECDSA TSS) but is the
recommended near-term path for PQC custody.
## Recommendation
- **Now:** ship threshold **ECDSA** custody (this deliverable) with an audited GG20/DKLs signer;
for PQC assurance use option (2), a k-of-n **independent-PQC multisig** using the live
precompiles, and/or option (1) hybrid co-signing. Do not market either as "threshold PQC".
- **Watch:** FIPS-204 threshold standardisation, threshold-Raccoon, and MPC-Dilithium research.
Revisit true threshold-ML-DSA only when an **audited** library targets the **standardised**
scheme and a matching on-chain verifier exists.
## One-line honesty statement for external copy
> AERE's threshold-custody registry uses classical threshold ECDSA (secp256k1). Threshold
> post-quantum signatures (threshold ML-DSA/Falcon) are an open research area and are **not**
> implemented or claimed. AERE's PQC precompiles verify single-signer PQC signatures only.