When your decryption committee members can profit from revealing their shares, your threat model changes. Traditional static and adaptive corruption models assume parties are compromised by external attackers. They don't account for participants who choose corruption based on private information they hold.
This gap matters for any system using threshold encryption with rotating committees, particularly encrypted blockchain mempools where financial incentives can motivate insiders to leak decryption shares.
Scope
This guide covers threshold encryption security under internally motivated corruptions. You'll learn how these corruptions differ from standard models, what the security implications are, and how to evaluate your encryption architecture against this threat class.
This applies to:
- Encrypted mempool implementations with committee rotation
- Multi-party computation protocols where participants hold varying secret state
- Any threshold encryption deployment where participants face asymmetric incentives
Key Concepts
Static Corruption: The adversary chooses which parties to corrupt at the start of the protocol. This choice is fixed throughout execution.
Adaptive Corruption: The adversary corrupts parties one-by-one during protocol execution based on public information like keys and ciphertexts.
Internally Motivated Corruption: A party decides whether to accept corruption based on its own secret state. The adversary submits a motivation function, and every party for which that function outputs 1 (evaluated on their private information) becomes corrupted.
Motivation Function: A function submitted by the adversary that each party evaluates on its local secret state to determine corruption behavior.
The Security Gap
Neither static nor adaptive models capture scenarios where corruption depends on secret information held by the party itself.
Consider an encrypted mempool with randomly rotating committees. An attacker deploys a smart contract that pays anyone who reveals their decryption share. A rational committee member might check: "Am I on the next committee? If not, I'll take the payment and reveal my share." The decision to corrupt depends on information only that party knows.
Your existing security proofs don't cover this. The adversary isn't choosing victims based on public data. The parties are self-selecting based on private state.
Requirements Breakdown
What You Can't Defend Against
Certain motivation functions and query patterns make security impossible. If your threat model includes:
- Arbitrary motivation functions with unlimited queries
- Motivation functions that can distinguish between any two secret states
- Environments where all parties face identical incentive structures
...then no threshold encryption scheme satisfies security under internally motivated corruptions. This isn't an implementation problem. It's a fundamental limitation.
What Constructions Exist
Two classes of constructions from Bilinear Diffie-Hellman assumptions offer partial solutions:
Construction Class 1: Secure when partial decryptions on the challenge ciphertext are internally motivated. Use this when you can bound which ciphertexts face internal motivation risk but can't control corruption behavior itself.
Construction Class 2: Secure under both internally motivated partial decryptions and internally motivated corruptions. Deploy this when parties may choose corruption based on secret state, not just choose whether to release shares.
Both constructions are efficient. The security guarantee depends on restricting either the motivation function class or the number of queries the adversary can make.
Implementation Guidance
Evaluate Your Threat Model
Map your deployment to these questions:
- Can participants profit from revealing decryption shares?
- Do participants hold private information that would affect their corruption decision?
- Are committees randomly rotated or does membership depend on secret state?
- Can an attacker deploy incentive mechanisms (smart contracts, bribes) that participants can claim based on private information?
If you answered yes to questions 1 and 2, your system faces internally motivated corruption risk.
Choose Your Construction
If you can prevent corruption but not control share revelation: Use Construction Class 1. This fits systems where:
- Party membership is public and fixed
- Incentives exist only for revealing shares, not for full corruption
- You need to protect specific challenge ciphertexts from motivated share releases
If parties can choose full corruption based on secret state: Use Construction Class 2. Required when:
- Committee membership or role assignment depends on secret information
- Attackers can offer payments for both shares and full secret state
- Rotation schedules or future assignments are known only to individual parties
Bound Your Motivation Functions
You can't secure against arbitrary motivation functions. Restrict the class by:
Limiting query complexity: Cap how many times the adversary can submit motivation functions. Each query increases the adversary's ability to partition the secret space.
Restricting function expressiveness: Define allowable motivation predicates. For instance, "am I on the next committee?" is more restrictive than "does my secret satisfy this arbitrary circuit?"
Separating incentive domains: If possible, ensure that motivation for revealing shares doesn't correlate with motivation for full corruption. This lets you use the weaker Construction Class 1.
Common Pitfalls
Assuming adaptive security covers internal motivation: It doesn't. Adaptive corruption lets the adversary choose victims based on public information. Internal motivation lets parties self-select based on private state. These are distinct threat models.
Ignoring financial incentives in your threat model: If your protocol runs on a blockchain or involves financial transactions, assume attackers can deploy smart contracts that pay for shares or secrets. Model this explicitly.
Treating all committee members as equally motivated: Parties with different secret states face different incentives. A member rotating off the committee has different motivation than one rotating on. Your security analysis must account for this heterogeneity.
Deploying schemes proven secure only under standard corruptions: A concrete attack exists against schemes proven secure under adaptive corruptions but not evaluated under internally motivated corruptions. Don't assume your existing proofs transfer.
Failing to bound motivation function queries: Unlimited queries let the adversary effectively learn the secret state distribution. Set explicit query limits in your security parameters.
Quick Reference Table
| Corruption Model | Who Chooses | Based On | Covers Internal Motivation? |
|---|---|---|---|
| Static | Adversary | Nothing (fixed at start) | No |
| Adaptive | Adversary | Public information (keys, ciphertexts) | No |
| Internally Motivated | Party itself | Private secret state | Yes |
| Construction Class | Secure Against | Use When |
|---|---|---|
| Class 1 (Bilinear DH) | Internally motivated partial decryptions | Share revelation is the primary threat |
| Class 2 (Bilinear DH) | Internally motivated corruptions + partial decryptions | Full corruption based on secret state is possible |
| Security Boundary | Achievable? | Notes |
|---|---|---|
| Arbitrary motivation functions, unlimited queries | No | Fundamental impossibility result |
| Restricted motivation class, bounded queries | Yes | Use Construction Class 1 or 2 |
| Standard adaptive security only | Insufficient | Concrete attacks exist |
Your threshold encryption deployment needs a threat model that includes internal motivation if participants hold asymmetric private information and face financial incentives. Choose your construction based on whether you're defending against motivated share releases, motivated corruptions, or both.
