Skip to main content

Mithril — threshold ML-DSA

Mithril is the implementation of the threshold ML-DSA protocol from "Efficient Threshold ML-DSA up to 6 parties" (ePrint 2026/013, USENIX Security 2026), submitted to the NIST Multi-Party Threshold Cryptography Call.

Note on naming. This is the PQShield / Brave "Mithril" (lattice-based threshold ML-DSA), not to be confused with Cardano / IOHK's "Mithril" (stake-based threshold signatures). Same name, entirely different scheme.

Status: Implementation complete. Pre-audit — not recommended for production without independent security review.

Performance​

Measured on Apple M4, single-threaded, ML-DSA-44:

(T, N)KeyGenSign + CombineVerify
(2, 2)~0.2 ms~0.5 ms~0.03 ms
(3, 3)~0.4 ms~0.7 ms~0.03 ms
(4, 6)~0.5 ms~12 ms~0.03 ms

The (4, 6) "sign + combine" number includes the typical retry overhead from lattice rejection sampling. End-to-end signing in a production custody pipeline (with TEE coordination, policy checks, network round-trips) lands around 1.5 seconds.

Key properties​

  • T-of-N threshold signing (2 ≤ T ≤ N ≤ 6).
  • Standard FIPS 204 output — signatures are verifiable by any conforming ML-DSA implementation. No custom verifier required.
  • 3-round signing protocol (commit → exchange → respond), followed by a combine step.
  • Constant-time polynomial arithmetic via RustCrypto's module-lattice primitives.
  • Zeroize on all secret material.
  • no_std compatible (with alloc).

Where Mithril is used​

Mithril is used for institutional custody workflows in the native Quantum wallet, combined with MPC and TEE architectures. It is not used for consensus threshold signing — the 6-party limit is incompatible with validator-scale quorum proofs. Validator-scale threshold signing is a separate research item (see Consensus → "Threshold research").

Institutional architecture​

Safely executing threshold ML-DSA in production requires solving two problems: lattice rejection-sampling aborts, and the authorization boundary that prevents the coordinator from requesting arbitrary signatures.

Hardware-enforced policy​

Mithril RSS shares are isolated inside hardware trusted execution environments (AWS Nitro, Intel TDX). The enclaves act as strict policy gates — they refuse to participate in the signing protocol unless the inbound transaction carries a valid cryptographic authorization token (e.g., a custodian's internal policy signature) verified against a hardcoded root of trust. This prevents the coordinator from requesting arbitrary signatures even if the coordinator host is fully compromised.

Stateful coordinator with transparent retries​

An untrusted, high-throughput routing layer handles the global mathematical aborts inherent to lattice rejection sampling. Custodians interact with a clean SDK (async/await sign()); the backend autonomously handles quorum reshuffling, state wipes, and retry loops. Typical end-to-end signing completes within ~1.5 seconds including retries.

Scoped key delegation​

The KeyVault's scoped permissions integrate directly with institutional custody. The vault's FullAccess key — stored as Mithril threshold shares across TEEs, typically 3-of-5 quorum — only comes online for addKey, removeKey, and high-value operations. Trading desks, operations teams, and automated systems receive Scoped keys restricted to specific contracts, methods, daily allowances, and expiry times. The cold-side FullAccess key never touches a trading workflow.

Legacy key import (a-posteriori migration)​

Mithril's trusted dealer model directly supports importing existing single-party ML-DSA private keys:

  1. The existing key is fed into the dealer ceremony inside an air-gapped provisioning TEE.
  2. It is split into T-of-N RSS shares.
  3. The original key is attested as destroyed after sharing.
  4. The public key — and therefore the on-chain address — remains unchanged.

This lets custodians upgrade to distributed vault security without rotating their public-facing addresses or migrating assets. From the chain's perspective, nothing changed: the address still verifies under the same public key. Internally, no single party can sign — and the TEE attestation chain proves it.

Standard ML-DSA output​

The critical property is that Mithril produces standard FIPS 204 signatures. A signature emitted by a 3-of-5 Mithril quorum is byte-for-byte indistinguishable from a single-party ML-DSA-44 signature. This means:

  • The on-chain verifier (Quantum, Arbitrum, anywhere) doesn't care that the signature was threshold-produced.
  • Audit and compliance flows that already accept ML-DSA signatures accept Mithril signatures unchanged.
  • Migration off Mithril (or onto a different threshold scheme) doesn't break the public key or address.

Standard output is the whole point. A bespoke "Mithril-only" verifier would create a separate compatibility surface; standard output keeps the surface to one.