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 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.
87 lines
5.6 KiB
Markdown
87 lines
5.6 KiB
Markdown
# 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 (Fiat–Shamir 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. Cozzo–Smart style
|
||
MPC-Dilithium, and 2023–2024 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 (2024–2025) 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.
|