# 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.