Path: blob/main/frontier/12-mpc/break/corrupt-party-additive.ipynb
483 views
Break: Corrupt Party in Additive Secret Sharing
Module 12 | Breaking Weak Parameters
Show how a single malicious party can bias the output in additive sharing --- and how SPDZ MACs catch them.
Why This Matters
Additive secret sharing (Notebook 12b) splits a secret into shares . It has perfect secrecy: any shares reveal nothing about .
But it has no redundancy. In Shamir sharing with threshold , corrupting one share can be detected by checking consistency across subsets. In additive sharing, there is only one "subset" --- all parties. If any single party modifies their share before the reconstruction step, the corrupted value is silently accepted.
Worse, the malicious party can choose their corruption adaptively: they can shift the output to any value they want, even without knowing the secret.
The Scenario
Three parties hold additive shares of a secret over . Party 2 is malicious: before the summation step, they add a bias to their share. The reconstructed value becomes , and the other parties have no way to detect the tampering.
Step 1: Honest Protocol
All three parties honestly reveal their shares. The sum equals the secret.
Step 2: Malicious Party Adds a Bias
Party 2 adds to their share before broadcasting it. The reconstructed value silently shifts from to .
Step 3: The Malicious Party Controls the Output
The attack is even more powerful than it looks. Party 2 can shift the output to any value they want --- even without knowing the secret .
Want the output to be 999? Set . But wait, Party 2 doesn't know . That's fine --- they can still shift the output by any relative amount , which is devastating in practice (e.g., adding funds to a balance, flipping a vote).
Step 4: No Detection Is Possible (Without MACs)
The fundamental problem: in additive sharing, every set of field elements that sum to some value is a valid sharing of that value. There is no "invalid" share.
Party 1 sees share , Party 3 sees share . When Party 2 broadcasts , the other parties have no way to know that was modified --- because is a perfectly valid sharing of .
The Fix: SPDZ-Style MAC Verification
The SPDZ protocol (Notebook 12e) adds a Message Authentication Code to every share. A global MAC key is shared among all parties. Each share is paired with a MAC share such that .
When a value is opened, parties check:
If any party tampered with their share, this check fails with probability . The cheater would need to know to forge a valid MAC, but no single party knows it.
Summary
| Aspect | Detail |
|---|---|
| Attack | Malicious party adds bias to their additive share before reconstruction |
| Impact | Output silently shifts from to ; cheater has full additive control |
| Detection (plain) | Impossible --- every set of shares summing to some value is a valid sharing |
| Root cause | Additive sharing has no redundancy and no authentication |
| Fix | SPDZ MAC: pair each share with a MAC tag; tampering is detected with probability |
| Real world | SPDZ, MASCOT, Overdrive all use MACs for malicious security |
Key takeaway: secret sharing provides privacy (no party learns the secret), but not integrity (no party can be caught cheating). For integrity, you need authentication. SPDZ's MAC-based approach adds minimal overhead to the online phase while providing overwhelming cheating detection.