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.
5.7 KiB
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, computesz = y + c·s, and rejection-samples: it aborts and retries whenzleaks information about the secrets. Distributing this is an open problem: the parties must jointly sampley, jointly run the abort check without revealing partialz, 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.
- 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
-
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:
-
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 composesAereThresholdRegistrywith the existingAerePQCKeyRegistry/ 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. -
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.