Cowrie Research

threshold-ceremony-share-leakage

13 min read

Threshold-Ceremony Share Leakage

  • Name: threshold-ceremony share leakage
  • Category: exploit pattern / threshold-signature implementation failure / MPC custody failure / signer-set collapse
  • Summary: Some signer systems fail not because an attacker stole enough keys up front, but because the threshold-signing ceremony itself leaks the honest parties’ long-term secrets over repeated runs. The attacker enters the signer set as a legitimate participant, feeds malformed parameters, malicious proofs, or attacker-shaped nonce / encryption material into the protocol, and harvests share leakage a little at a time until the advertised M-of-N threshold collapses into unilateral signing power. The dangerous inversion is that the attacker can look like a routine participant during keygen or signing right up until the recovered full key starts authorizing real withdrawals. Healthy review gets materially better once teams stop flattening three different questions into the threshold still worked: did one participant still have a live path into enough ceremonies to accumulate leakage at all, did those ceremonies still count as cryptographically sound threshold truth for this exact vault key, and how much live release authority should even that accepted vault key still carry right now?

Three threshold-ceremony promotions reviewers should not collapse

  1. One participant can still accumulate meaningful ceremony exposure

    • A newly admitted or still-live signer can keep joining keygen or signing rounds, supplying cryptographic objects and observing enough honest responses to make transcript harvesting economically relevant.
    • This is only the reachability question: one participant still has enough live ceremony access to try extraction at all.

  2. Those ceremonies still count as sound threshold truth for this exact vault key

    • The harder question is whether the participant-supplied Paillier setup, modulus structure, proofs, nonce commitments, transcript rules, and abort semantics were actually sufficient for malicious-participant security in the deployed implementation.
    • This is the authenticity question: the protocol is still right to treat these rounds as producing honest threshold truth rather than attacker-shaped leakage.

  3. That accepted vault key still deserves this much live release authority right now

    • Even if the key material the system accepts is real, it should not automatically imply ordinary-speed release of deep multi-chain or multi-asset reserves.
    • This is the authority-budget question: why does one key recovered from this ceremony family still have this much immediate custody reach?

Healthy review gets materially better once teams stop flattening those three promotions into one vague the threshold cryptography held until it didn't story.

  • What it is:
    • A protocol relies on MPC / TSS signing to keep any one participant from learning the complete custody key.
    • The implementation fails to validate some ceremony-critical property: setup proofs, Paillier modulus soundness, nonce correctness, parameter bounds, participant commitments, abort handling, or transcript consistency.
    • A malicious participant joins the legitimate ceremony rather than attacking from outside.
    • Repeated honest signing rounds leak enough information about other parties’ long-term shares for offline key recovery.
    • Once the attacker reconstructs the full private key, later withdrawals no longer require the threshold protocol at all.
  • Typical preconditions:
    • The custody system uses a threshold-signature scheme such as GG18 or GG20 for high-value vaults.
    • Ceremony inputs from participants are trusted too early or validated incompletely.
    • One malicious participant can stay in the signing set long enough to observe repeated keygen or signing rounds.
    • A recovered full key directly authorizes withdrawals on destination chains without an independent release throttle.
    • Operations treat the threshold cryptography library as a solved primitive and do not continuously track upstream cryptographic advisories or implementation drift.
  • Common vulnerable surfaces:
    • Paillier modulus / factor proof validation during GG18 / GG20 setup
    • participant-supplied keygen parameters and zero-knowledge proof verification
    • nonce generation, nonce commitments, and identifiable-abort handling
    • custom forks of upstream MPC / TSS libraries that lag security patches
    • bridge or custody stacks where one recovered signing key can release multi-chain reserves directly
  • Exploit sequence:
    1. The attacker gets admitted into the signer set as a normal participant.
    2. During key generation or signing, they submit malformed but insufficiently checked cryptographic material.
    3. Honest participants continue the ceremony, leaking bounded pieces of long-term share information through apparently valid rounds.
    4. The attacker accumulates leakage across many ceremonies and reconstructs the complete private key offline.
    5. They stop depending on the threshold protocol and sign raw withdrawals directly.
    6. Downstream chains accept those withdrawals as authentic because the recovered key is real.
  • Variants:
    • Malformed Paillier setup — missing MOD / FAC or biprime-soundness checks let an attacker use attacker-shaped Paillier keys to extract honest shares, the central GG18 / GG20 advisory class behind CVE-2023-33241.
    • Transcript-only leakage — insecure parameter choices make normal ceremony transcripts sufficient for recovery or sharply reduce the work needed for extraction.
    • Fork-lag cryptography — the product inherits a known vulnerability because it runs an old or custom fork of an MPC library after the broader ecosystem has already patched.
    • Signer-admission monetization — the attacker first pays the cost to become a legitimate validator / signer, then uses that privileged seat as the exploit precondition rather than as a trust signal.
  • Boundary tests that keep this pattern distinct:
    • Classify it here when the threshold collapses because a malicious participant learns too much from honest ceremony interaction itself. If the decisive step is join signing set -> feed malformed setup material or observe enough rounds -> reconstruct full key, this note is the right home.
    • Classify it under signer-quorum compromise when the attacker mainly steals, coerces, or socially engineers enough existing keys without needing ceremony leakage. The threshold still failed, but the preserved lesson there is operational capture of authority rather than cryptographic share extraction from protocol participation.
    • Classify it under operator-boundary opacity when the marketed threshold was never the real control boundary in the first place. If one vendor, MPC operator, or hidden admin path could already move funds without the advertised ceremony assumptions, the deeper problem is hidden centralization, not leakage through a sound-looking ceremony.
    • Classify it under blind-sign payload substitution or authorized-action origination compromise when the signatures stayed cryptographically ordinary but humans or backend workflows were tricked about what they were authorizing. Those incidents use valid signing rails; this pattern is about the signing primitive itself ceasing to protect the secret.
    • Ask whether the attacker ever needed the threshold protocol again after the exploit matured. If the answer becomes no, they now possess the full key and can sign raw withdrawals directly, that is a strong signal this note is doing the main analytical work.
  • Detection heuristics:
    • Review the ceremony implementation itself, not just the published threshold number or validator count.
    • Ask which participant-supplied values must be proven well formed and exactly where the code verifies those proofs.
    • Compare deployed forks against audited upstream libraries and published advisories; cryptographic lag is custody risk, not maintenance debt.
    • Treat unexplained signing retries, repeated aborts, or unusual churn-in behavior from new signers as possible extraction setup rather than harmless operations noise.
    • Map how many ceremonies a malicious signer can participate in before rotation, slashing, or quarantine can remove it.
    • Ask whether a recovered full key would immediately bypass all proactive signing-policy checks.
  • Defenses:
    • Treat TSS / MPC code as custody-critical application logic, not as a black-box library dependency.
    • Verify all setup proofs, participant commitments, modulus-soundness checks, and parameter bounds required by the protocol specification and by later security advisories.
    • Minimize divergence from maintained upstream cryptographic libraries; if a fork is necessary, track upstream security fixes with the same urgency as bridge hot patches.
    • Prefer schemes and implementations with strong identifiable-abort behavior, audited malicious-participant security, and clear guidance on parameter selection.
    • Shorten the time a fresh signer can accumulate useful transcript exposure before deeper trust is earned.
    • Add independent balance-sheet throttles so possession of one recovered key does not imply unlimited immediate extraction.
    • Instrument ceremonies, retries, and abort patterns as security telemetry rather than only reliability telemetry.

What sound design looks like

  • Healthy systems keep three promotions separate on purpose: one participant can still reach enough ceremony exposure, those ceremonies still count as sound threshold truth, and that accepted key still deserves this much release authority. The fastest way to hide this family is to narrate all three as one vague the MPC threshold still protects us claim.

  • The protocol can explain not only its nominal threshold but also the exact ceremony assumptions that keep one participant from learning too much. M-of-N is incomplete without under which validated protocol conditions.

  • Cryptographic setup validation is complete, explicit, and continuously maintained against current advisories. A production fork is not allowed to silently skip proof families that newer research has shown to be mandatory.

  • Fresh signer admission and long-term custody exposure are staged. Joining the quorum does not immediately grant enough repeated ceremony access to extract the crown jewels if something in the cryptography is wrong.

  • A recovered signing key is still not the whole game: withdrawal caps, staged release, solvency checks tied to execution, and cross-vault compartmentalization keep cryptographic failure from becoming instant total failure.

  • Incident response assumes cryptographic primitives can fail operationally. Rotation, churn, signer eviction, and emergency vault migration are rehearsed before a live extraction event.

  • Fresh signer exposure is staged by blast radius. New participants do not immediately accumulate enough high-value ceremony access across one shared vault key to make transcript harvesting economically decisive before the rest of the system can react.

  • Design routing companions worth preserving:

    • Ceremony-completeness companion — use threshold-ceremony proof completeness and fresh-signer exposure discipline when the sharper question is what exact proof families, signer-admission staging, and churn / vault-assignment rules should have prevented one new participant from turning routine ceremonies into key recovery.
    • Blast-radius companion — keep bridge bounded release design nearby when the recovered key signs a bridge or multi-chain custody vault, because the second important question is why one recovered vault key still had immediate reach over so much spendable inventory.
    • Hidden-threshold companion — keep operator topology map and effective-threshold discipline nearby when the postmortem starts to drift from the ceremony leaked toward the public threshold story never described the real operational choke points around the ceremony anyway.

Failure-prevention checklist

  • Review three separate promotions every time: one participant can still accumulate ceremony exposure, those ceremonies still count as sound threshold truth for this exact vault key, and that accepted key still deserves this much live release authority now. Healthy custody review proves all three instead of assuming one implies the next.
  • Inventory every MPC / TSS dependency, fork, and local patch that touches key generation, signing, proof verification, nonce handling, or abort logic.
  • For each participant-supplied cryptographic object, write down the exact well-formedness property required for safety and the code path that enforces it.
  • Track upstream advisories and academic breaks for the specific protocol family in use; widely used is not a substitute for ongoing security maintenance.
  • Review whether the deployed fork still performs all required Paillier modulus, biprime, range, and proof checks from the patched reference implementation.
  • Limit the blast radius of new signers: probationary vault assignment, reduced signing exposure, or smaller capped vaults are safer than immediate access to system-wide high-value custody.
  • Add ceremony-level monitoring for retries, abnormal aborts, repeated failed signatures, or other patterns consistent with leakage harvesting.
  • Stage new signers into low-blast-radius custody first. Fresh participants should not immediately gain repeated exposure to the system’s largest multi-asset vaults before the operator set has observed them over time.
  • Rehearse emergency signer eviction, vault rotation, and patched-library rollout before an incident forces cryptography and operations work to happen at once.
  • Keep downstream release controls meaningful even after one vault key is compromised: per-vault caps, rapid halts, segmented reserves, chain-specific throttles, and cross-chain compartmentalization.

Audit prompts

  • Which exact proof families and parameter checks does the implementation rely on to keep malicious participants from extracting honest shares?
  • Is the deployed code a maintained upstream release, a lagging fork, or a bespoke adaptation, and who owns tracking cryptographic security advisories for it?
  • Can a newly admitted signer immediately participate in enough high-value ceremonies to make transcript accumulation economically worthwhile?
  • What telemetry exists for abnormal ceremony behavior such as repeated aborts, retries, signer-specific failure clusters, or compatibility-mode fallbacks that quietly skip proof checks?
  • If one vault key were reconstructed offline today, what independent controls would still slow or cap asset release, and how much multi-asset inventory sits behind that one key?
  • How quickly can the system evict a signer, rotate vaults, and migrate funds after suspicion of ceremony compromise?
  • Are operators able to explain why each participant-supplied Paillier key, nonce commitment, proof, or transcript object is safe to trust?
  • Has the team reviewed post-2023 research and advisories relevant to GG18 / GG20 or whichever threshold scheme is actually in production?

Lessons that should already be standard

  • Live ceremony access exists, those ceremonies still produce honest threshold truth, and the resulting key still deserves deep release authority are different properties.

  • Threshold cryptography is only as strong as the ceremony checks actually enforced in production.

  • A signer seat is not merely governance membership. In some architectures it is privileged exploit pre-positioning.

  • No one ever sees the full key is a promise about protocol correctness, not a magical property of using MPC buzzwords.

  • Custom forks of cryptographic libraries age badly. Security debt in proof verification is custody debt.

  • Cryptographic failure needs balance-sheet compartmentalization. If one recovered key can drain everything, the surrounding system is too trusting.

  • Security review for signer systems must include malicious-participant analysis, not only outsider compromise and key-theft scenarios.

  • Fresh-signer onboarding is part of custody design. If a new participant can quickly accumulate high-value transcript exposure, the churn process itself becomes exploit fuel.

  • One recovered vault key spanning many chains or assets is a blast-radius multiplier, not just a cryptography detail.

  • High-signal incidents:

    • THORChain Asgard vault GG20 (2026-05-15) — the sharp corpus exemplar where a newly churned node allegedly exploited missing GG20 proof checks, accumulated leakage across routine ceremonies, and then signed vault withdrawals directly across many chains.

Where this pattern helps most

  • Use this note when the custody boundary failed inside the threshold-signing protocol itself rather than through plain key theft or visible operator capture.
  • Reach for signer-quorum-compromise when the higher-level question is still how did the threshold collapse in practice? across both cryptographic and organizational routes.
  • Reach for operator-boundary-opacity when the deeper problem is that the public threshold story never matched the real operating boundary even before any ceremony bug.
  • Reach for bridge-verification-failure when the recovered key ultimately served as the bridge-side authenticity oracle for cross-chain release.

Internal linkages

Control surface

Graph View

Backlinks