a13a649b77
Aere Network public source. Everything here can be checked against the live chain (chain id 2800, https://rpc.aere.network). Scope note, stated up front rather than buried: consensus on chain 2800 is classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at the signature, precompile, account and transport layers. Nothing here makes the consensus post-quantum, and no document in it should be read as claiming so.
87 lines
5.7 KiB
Markdown
87 lines
5.7 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.
|