Analysis: Privacy, Reliability, and Scaling
Proving the Sparse Graph Works
Section 12.2 specified the CCESA protocol: a sparse Erdős–Rényi random graph replaces Bonawitz's complete graph. The protocol reduces overhead from to . The analytical question is: does the privacy guarantee still hold?
Section 12.3 answers this in three parts:
-
Privacy. With high probability over the random graph, no coalition of users can fragment the graph — i.e., every honest user retains at least one mask partner that is outside the coalition. This ensures Bonawitz- equivalent privacy.
-
Reliability. The random graph is connected w.h.p. at CCESA's density, so the mask-cancellation structure is well-defined and the aggregate can always be computed.
-
Scaling. Both the privacy and reliability guarantees hold for at edge density with .
The tools are standard random-graph theory: Chernoff concentration, first-moment bounds on adverse events, and union bounds over subsets. Section 12.3 presents them in the CCESA context.
Theorem: CCESA Privacy: High-Probability Bonawitz-Equivalent
Let be the number of users, the collusion threshold, and for some . For the CCESA protocol with Erdős–Rényi graph , define the event "privacy holds" as: for every honest user and every coalition of users, has at least one neighbor outside .
Then: When privacy holds, CCESA's guarantee is the same as Bonawitz: the adversary (server + colluders) learns only the aggregate and nothing about individual gradients.
Privacy holds iff the coalition of users cannot "isolate" any honest user from its neighbors — i.e., honest users always have at least one neighbor outside the coalition. In a random graph with edge probability , the probability of a specific user being isolated from a specific coalition decays exponentially in . Union-bounding over all coalitions and users gives the failure probability at CCESA's density.
Operationally: the privacy failure probability is so small that in practice the guarantee is "Bonawitz-equivalent" — no production deployment sees a failure. The random-graph analysis is a formal way to justify this.
Fix a coalition
Fix an honest user and a coalition of size , . "Privacy fails for " means .
Probability that $k$ has no honest neighbor
. For and : for some .
Union bound over all coalitions
Number of (honest user, coalition) pairs: . Union bound: . For (achievable by taking in the edge density large enough), the failure probability is .
Conclusion
With high probability, privacy holds uniformly over all users and coalitions. When it holds, the server + colluders learn only the aggregate — same guarantee as Bonawitz. The privacy is "Bonawitz-equivalent w.h.p."
Theorem: CCESA Reliability: Aggregation Succeeds W.H.P.
Under the same CCESA setup (edge probability , constant ), the event "reliability holds" is defined as: the graph is connected, so that the mask-cancellation structure is well-defined.
Then: When reliability holds, the server's aggregate equals exactly (up to the self-mask contributions, which are handled as in §12.2).
A random graph is connected w.h.p. whenever (Erdős–Rényi classical result). CCESA's density is much higher than this threshold — essentially -times denser. The reliability guarantee is therefore very robust.
In practice, the random graph is not just connected but highly connected — typical user degree . The reliability guarantee degrades gracefully as decreases toward the connectivity threshold.
Erdős–Rényi connectivity
Classical: is connected w.h.p. iff . At (for any constant and large), the condition is satisfied. Hence is connected w.h.p.
Reliability from connectivity
Connectedness implies every user is (transitively) connected to every other via the mask-pair structure. The aggregate is well-defined: sums over all users, masks cancel in pairs along the edges.
Failure probability
Connectivity fails with probability at CCESA's density. Reliability follows the same bound.
Theorem: CCESA: Privacy + Reliability + Sub-Quadratic Scaling
The CCESA protocol with users, collusion threshold , edge probability (constant ), and model dimension satisfies:
-
Privacy w.h.p.: . When it holds, the adversary's information-theoretic view is Bonawitz-equivalent.
-
Reliability w.h.p.: . When it holds, the server's aggregate equals the honest sum exactly.
-
Communication: aggregate per round — sub-quadratic in . Per-user: .
Combined: with probability , CCESA provides Bonawitz-level guarantees at sub-quadratic communication cost.
The combined result is the headline: Bonawitz-equivalent privacy and reliability at a fraction of the communication cost. The "with high probability" caveat is so strong () that it is operationally equivalent to deterministic.
The CCESA construction is the information- theoretic optimum for the random-graph class of secure-aggregation schemes. Within the deterministic class, Caire et al. (Chapter 10 §10.4) proved is tight; CCESA moves outside this class to achieve sub-quadratic at minimal cost in guarantee strength.
Privacy
Theorem 12.3.1 above.
Reliability
Theorem 12.3.2 above.
Communication
Section 12.2's communication analysis: DH overhead + gradient upload + Shamir-share overhead = aggregate.
Combined
Union bound on the privacy and reliability failure events: failure probability. Both guarantees hold simultaneously w.h.p.
Key Takeaway
CCESA delivers Bonawitz-equivalent privacy and reliability at communication. The random-graph-theoretic analysis gives tight failure probabilities — so small that the guarantee is operationally deterministic. The -factor communication saving over Bonawitz is the advantage. At , this is a reduction.
Example: CCESA Failure Probabilities at
For a CCESA deployment with users, collusion threshold, and edge probability , compute approximate privacy and reliability failure probabilities.
Edge probability
.
Connectivity check
Classical threshold: . CCESA's is above threshold — well-connected w.h.p.
Privacy failure probability
for some depending on constants. At , , and CCESA's margin, empirically . Failure probability or smaller.
Reliability failure probability
Connectivity at : failure probability from classical for some constant — essentially zero in practice. .
Interpretation
Both failure probabilities are negligible. In a production deployment with users, CCESA succeeds in essentially every round. The guarantees are "Bonawitz-equivalent w.h.p." in the strongest possible sense.
CCESA Failure Probability vs. Edge Density
Plot the privacy and reliability failure probabilities as a function of the constant in the edge probability , for various . Show that both failure probabilities decay rapidly with : at , failure is ; at , . Practical CCESA uses – for comfortable margins.
Parameters
Is CCESA Optimal?
Within the class of sparse-graph-based secure-aggregation schemes with information-theoretic privacy, CCESA achieves overhead. Is this tight?
Lower bound argument: any scheme requiring every honest user to have at least one honest neighbor (privacy requirement) under Erdős–Rényi edge distribution must have — the classical connectivity threshold. Below this, the graph disconnects and privacy breaks.
CCESA uses , which is -times larger than the connectivity threshold. The slack is used for the privacy margin (every user's neighborhood must contain honest node w.h.p.). Closing the gap between CCESA's rate and the classical connectivity threshold is an open problem.
The Choi et al. (2022) paper establishes that CCESA matches the lower bound for the non-adaptive random-graph class, up to a polylog factor. Adaptive constructions (graph depends on user identities) may achieve tighter bounds; this is one of the open problems of Chapter 18.
Theorem: Lower Bound for Random-Graph SecAgg
For any secure-aggregation protocol where the pairwise-mask graph is a random Erdős–Rényi and where the privacy guarantee holds with high probability, the edge probability must satisfy Hence the aggregate DH-exchange overhead is , and any CCESA-variant achieving this bound is near-optimal in the sparse-graph class.
CCESA's is at the information-theoretic optimum within an factor. Closing this factor is open.
The lower bound comes from the classical Erdős–Rényi connectivity threshold. Below , the graph disconnects w.h.p., leaving isolated users whose masks don't cancel. Privacy would break (and reliability too).
CCESA's density sits above this threshold by a factor of . Whether this factor is necessary for the privacy margin (not just reliability) is a delicate analysis. The Choi et al. (2022) paper gives a tighter lower bound matching CCESA's rate; the gap is in the polylog factors.
Reliability lower bound
For the aggregate to be computable, must be connected. Classical ER connectivity threshold: . Hence reliable CCESA requires .
Privacy lower bound
For privacy to hold against -colluders w.h.p., every honest user must have an honest-neighbor w.h.p. This is a stricter requirement than bare connectivity. Analysis shows is needed for the privacy margin at . CCESA matches this with the same scaling.
Aggregate overhead
At , . CCESA matches this rate. Hence it is optimal within a polylog factor within the random-graph class.
Common Mistake: The Graph Seed Must Be Honestly Generated
Mistake:
Allow the server to unilaterally choose the CCESA graph seed.
Correction:
If the server controls the graph seed, it can adaptively choose a graph that isolates specific honest users (e.g., removes all their edges). This would break privacy even though the "graph is random" from the server's perspective.
Production CCESA uses a round-specific seed derived from an external randomness source: blockchain hashes, NIST beacon, or distributed coin-flipping. The seed must be unpredictable before user gradients are chosen; otherwise the adversary can adaptively shape the graph. The Choi et al. paper assumes honest seed generation as a protocol assumption.
Honest Seed Generation in Production
CCESA's honest-seed assumption is handled in production via:
- Blockchain randomness: seed derived from the hash of a recent block, publicly verifiable, hard to manipulate.
- NIST Randomness Beacon: government-run public randomness source (limited by centralization concerns).
- Distributed coin-flipping: multi-party protocol where users collectively generate the seed. Adds overhead but fully decentralizes.
The choice depends on deployment trust model: blockchain for trustless environments, distributed flipping for FL deployments with no external beacon. Production implementations use blockchain by default.
- •
Blockchain seed: unpredictable, verifiable
- •
Distributed flipping: overhead, fully decentralized
- •
Server-chosen seed: insecure, must be avoided
Quick Check
For CCESA with users at edge density , the failure probability of the privacy guarantee is approximately:
(1% failure rate)
or smaller (negligible in practice)
Exactly 0 (deterministic guarantee)
(linear decay)
Correct. The failure probability is for depending on the constants. For and reasonable margins, this is at most — negligible in practice.