Is Multisig Quantum Safe?

Is multisig quantum safe? It is one of the most important questions in cryptographic security right now, and the honest answer is: not in the way most people assume. Multisignature wallets are widely regarded as the gold standard for institutional crypto custody, and rightly so against classical attack vectors. But when a sufficiently powerful quantum computer enters the picture, the multi-key architecture provides far less protection than it appears. This article explains exactly why, walks through the relevant cryptographic mechanisms, compares threshold schemes to post-quantum alternatives, and identifies what genuinely raises the security bar.

What Multisig Actually Does — and What It Does Not Do

Multisig (multisignature) requires M-of-N private keys to authorise a transaction. A 2-of-3 setup, for example, means any two of three keyholders must sign before funds move. This protects against:

• A single compromised key (classical theft, phishing, insider attack).
• A single point of hardware failure.
• Unilateral control by one party in a joint custody arrangement.

What multisig does not address is the underlying mathematical assumption that makes every one of those keys secure in the first place: the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP).

Bitcoin and Ethereum keys — whether you hold one or ten — are generated using ECDSA (Elliptic Curve Digital Signature Algorithm) on the secp256k1 or secp256r1 curves. The security guarantee is that deriving a private key from a public key is computationally infeasible on classical hardware. A quantum computer running Shor's algorithm breaks that guarantee entirely.

---

How Shor's Algorithm Threatens Every ECDSA Key

Shor's algorithm, published in 1994, solves the integer factorisation and discrete logarithm problems in polynomial time on a quantum computer. For ECDSA specifically:

1. The attacker observes a public key (which is broadcast on-chain whenever a transaction is signed, or derivable from an address in many schemes).
2. A sufficiently large fault-tolerant quantum computer runs Shor's algorithm against the elliptic curve group.
3. The private key is recovered — typically estimated to require ~2,000–4,000 logical qubits with full error correction, a threshold that does not yet exist but that hardware roadmaps at IBM, Google, and others are progressively approaching.

The critical point for multisig: Shor's algorithm does not care how many ECDSA keys you are using. Each key is individually vulnerable. If an attacker can crack one, they can crack all three in a 2-of-3 setup given enough quantum compute time. The multisig structure adds latency to the attack, not immunity from it.

The Public Key Exposure Problem

The quantum threat is specifically acute once a public key is exposed on-chain. In traditional P2PKH (Pay-to-Public-Key-Hash) Bitcoin addresses, the public key is only revealed when you spend. In multisig P2SH or P2WSH scripts, the full redeem script — including all N public keys — is revealed at spend time. From that moment, any observer (including a future quantum adversary with a sufficiently powerful machine) can attempt key recovery.

Reusing multisig addresses, a common operational pattern, compounds the risk significantly.

Grover's Algorithm and Hashing

Grover's algorithm, a separate quantum algorithm, provides a quadratic speedup against brute-force search. For SHA-256 (used in Bitcoin address derivation and mining), Grover's effectively halves the bit-security from 256 bits to 128 bits. 128-bit quantum security is still considered acceptable by most standards bodies today. The hash-based exposure is therefore a lower-priority concern than the ECDLP exposure, but it is worth noting in a complete threat model.

---

Threshold Signature Schemes: More Sophisticated, Same Underlying Vulnerability

Threshold signature schemes (TSS) are sometimes conflated with or presented as an evolution of multisig. In TSS, the signing process uses multi-party computation (MPC) so that the private key is never reconstructed in a single location. Common protocols include:

• GG18 / GG20 (Gennaro-Goldfeder)
• FROST (Flexible Round-Optimised Schnorr Threshold signatures)
• CGGMP21

TSS eliminates several classical attack vectors that multisig leaves open — notably the exposure of the full redeem script on-chain and the single-point-of-reconstruction risk in some M-of-N implementations.

However, TSS protocols built on ECDSA or Schnorr over secp256k1 inherit the same ECDLP security assumption. A quantum adversary attacking the resulting public key faces exactly the same problem as when attacking a simple single-key ECDSA wallet. The distributed key generation ceremony and threshold structure are irrelevant once Shor's algorithm is in play.

Comparison: Multisig vs TSS vs PQC

The table makes the core problem plain: neither classical multisig nor MPC/TSS addresses the quantum column of that risk matrix.

---

What Genuinely Helps: Post-Quantum Cryptography

The only cryptographic approach that addresses the quantum threat at its root is replacing ECDSA with algorithms whose hardness assumptions are not broken by Shor's or Grover's algorithms. In August 2024, NIST finalised three post-quantum cryptography standards:

• ML-KEM (FIPS 203) — Key encapsulation, based on the CRYSTALS-Kyber lattice problem.
• ML-DSA (FIPS 204) — Digital signatures, based on CRYSTALS-Dilithium lattice problem.
• SLH-DSA (FIPS 205) — Stateless hash-based signatures, based on SPHINCS+.

For a cryptocurrency wallet, the relevant standard is a post-quantum digital signature scheme to replace ECDSA. The lattice-based ML-DSA and the hash-based SLH-DSA are the two primary candidates. Each works differently:

Lattice-Based Signatures (ML-DSA / Dilithium)

Lattice problems, particularly the Module Learning With Errors (MLWE) problem, are believed to be hard for both classical and quantum computers. Dilithium signatures are compact relative to other PQC options and offer efficient verification, making them viable for blockchain applications. Key sizes are larger than ECDSA (public keys ~1.3 KB vs. 33 bytes for a compressed ECDSA key), which has transaction-size and fee implications on existing chains.

Hash-Based Signatures (SLH-DSA / SPHINCS+)

Hash-based schemes rely only on the security of the underlying hash function — an assumption considered extremely conservative. They require no new mathematical hardness assumptions beyond hashing, which makes them attractive to highly risk-averse implementations. Signature sizes are larger (8–50 KB depending on parameter set), and they are stateless (unlike earlier XMSS/LMS schemes), simplifying key management.

Combining PQC with Threshold Structures

The most robust architecture emerging in research and early implementations combines PQC signing algorithms with threshold or MPC structures. For example, a threshold Dilithium scheme distributes key shares so that no single party holds the full signing key, while the underlying cryptographic assumption is quantum resistant. This addresses both classical custodial risk and quantum risk simultaneously. Projects implementing this are still primarily in the research and testnet phase as of 2025.

---

Practical Implications for Crypto Holders Today

Quantum computers capable of running Shor's algorithm at scale do not yet exist. Current estimates from cryptographers at NIST, ETSI, and the BSI range from 10 to 20 years before a cryptographically relevant quantum computer (CRQC) is plausible, though the range has wide uncertainty. The "harvest now, decrypt later" threat model is relevant for long-term HODL addresses: an adversary could record public keys and transactions today, then decrypt them once quantum hardware matures.

Practical steps to consider:

1. Avoid address reuse. Funds sitting in addresses whose public key has already been broadcast on-chain carry more exposure than funds in fresh, unspent outputs where the key is still hashed.
2. Audit your custody stack. Understand whether your hardware wallet, exchange, or institutional custodian has a PQC migration roadmap.
3. Monitor NIST PQC adoption in blockchain. Ethereum's roadmap includes quantum resistance discussions (EIP-7885 and related proposals). Bitcoin's path is slower given its conservative governance culture.
4. Evaluate purpose-built PQC wallets. Some projects are building wallets and tokens from the ground up with lattice-based cryptography rather than retrofitting ECDSA chains. BMIC.ai, for instance, is one such project using NIST PQC-aligned, lattice-based cryptography to protect holdings from Q-day exposure at the wallet level.
5. Do not panic-migrate. Moving funds to a PQC-native solution is sensible planning. Rushed migrations under pressure introduce their own operational risks.

---

Why the Misconception Persists

The multisig-is-quantum-safe misconception is understandable. Multisig solved a real and significant problem — classical key compromise — and it solved it well. The mental model of "more keys equals more security" is intuitive and mostly correct in a classical threat environment. It breaks down precisely because the quantum threat is not about key management practices; it is about the mathematical trapdoor on which every ECDSA key is built.

Security vendors and custody providers have commercial incentives to describe their multisig or MPC solutions as "institutional grade" or "the most secure available" without always clarifying that "secure" implicitly means "against classical adversaries." Reading the small print on quantum risk disclosures in custody agreements is worthwhile.

---

The Timeline Question

No one can state with certainty when a CRQC will arrive. The honest position is that the timeline is uncertain but the direction of travel is not. IBM's quantum roadmap targets millions of physical qubits in the next decade. DARPA launched a dedicated program in 2024 specifically focused on accelerating fault-tolerant quantum computing. The NSA and CISA have both recommended that organisations begin PQC migration planning now, not at the point a CRQC is demonstrated.

For cryptocurrency specifically, the migration challenge is harder than for traditional IT systems. Blockchain transactions are immutable, key schemes are baked into protocol consensus rules, and upgrades require community coordination. Starting the conversation early is not alarmism — it is prudent engineering.