What is Secure Aggregation?
Secure Aggregation is a cryptographic protocol that lets a coordinator compute an aggregate, typically a sum of participant vectors, while preventing it from learning each participant's plaintext contribution under a declared threat and dropout model.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
Make masks cancel only in the aggregate
Clients establish authenticated pairwise secrets and expand them into pseudorandom masks with opposite signs. Each uploaded vector contains the local update plus its masks; adding all accepted vectors cancels every surviving pair. The practical SecAgg protocol combines this idea with secret sharing so the server can remove masks for dropped clients without learning surviving clients' inputs.
The Go example below demonstrates only the cancellation invariant; production security requires the full authenticated cryptographic protocol.
Bind privacy to cohorts, thresholds, and transcripts
The server must commit to one round, participant set, vector shape, numeric encoding, and threshold. Authenticate messages, prevent replay and equivocation, enforce a minimum cohort after dropouts, and erase ephemeral key material. Quantization and modular arithmetic need explicit bounds to avoid wraparound. Record protocol outcomes and participant counts without retaining secret shares or plaintext updates.
Separate confidentiality from robustness and DP
Secure Aggregation hides individual values from the aggregator but can also make malicious updates harder to inspect. Robust aggregation, clipping, attestation, or anomaly workflows address integrity under a compatible design. Differential Privacy limits what the released aggregate can reveal about a contribution, while SecAgg limits which intermediate values the server observes. Combining them still requires careful ordering, trust, and failure analysis.
Key Characteristics
- Reveals an authorized cohort aggregate rather than plaintext contributions
- Uses cryptographic masks or related secure-computation techniques
- Needs explicit collusion, dropout, and minimum-cohort assumptions
- Requires bounded numeric encoding and overflow-safe aggregation
- Protects confidentiality but does not inherently reject poisoned updates
- Complements rather than replaces Differential Privacy and access control
Common Use Cases
- Aggregating federated model updates from mobile-device cohorts
- Computing cross-organization statistics without revealing each input
- Collecting distributed telemetry with a minimum reporting threshold
- Protecting gradients from an honest-but-curious coordinator
- Building confidential sums as one layer of a privacy-preserving pipeline
Example
Loading code...Frequently Asked Questions
How does Secure Aggregation hide individual updates?
Each client uploads a masked vector. Pairwise masks are constructed with opposite signs, so they cancel when accepted vectors are summed but obscure each individual message. Dropout-tolerant protocols secret-share recovery material so masks from departed clients can be removed without exposing surviving plaintext contributions.
Is Secure Aggregation the same as Differential Privacy?
No. Secure Aggregation controls visibility during computation: the coordinator learns an aggregate instead of individual inputs. Differential Privacy controls what an output distribution reveals about one protected contribution. An exact aggregate can still leak information, so systems often combine both under explicit trust and accounting assumptions.
Does Secure Aggregation stop model poisoning?
Not by itself. A malicious client can encrypt or mask a harmful update just as it can an honest one, and hiding inputs can limit server-side inspection. Integrity needs compatible controls such as authentication, clipping, bounded inputs, robust aggregation, attestation, anomaly handling, and rollback.
Why does the minimum cohort size matter?
A sum over one participant reveals that participant's value, and small or repeatedly overlapping cohorts can support differencing attacks. The protocol and scheduler should enforce threshold completion, constrain cohort manipulation, and abort without releasing a result when privacy assumptions are not met.
What must be tested before deploying Secure Aggregation?
Test authenticated setup, replay and equivocation resistance, collusion assumptions, dropout at every phase, threshold enforcement, key erasure, numeric encoding, overflow, duplicate submissions, stale rounds, denial of service, and recovery behavior. Also verify that logs and metadata do not recreate the individual-view leak the protocol is meant to prevent.