Exercises
ex-ch12-01
EasyWhy does Bonawitz's overhead become impractical at large ?
Pairwise growth
Bonawitz requires pairwise DH exchanges. At users, this is exchanges per round.
Time per round
At s per DH exchange (mobile production), seconds = 6 days per round.
Result
Per-round latency far exceeds reasonable bounds (seconds-minutes). Bonawitz cannot be deployed at this .
ex-ch12-02
EasyState the CCESA edge probability and the aggregate communication cost. Compare with Bonawitz.
for .
Edge probability
for some constant . Typical –.
CCESA communication
Aggregate per round: . Sub-quadratic in .
Bonawitz comparison
Bonawitz: . CCESA improvement over Bonawitz: factor on the structural overhead. At : faster.
ex-ch12-03
EasyWhy does the random-graph approach allow CCESA to "escape" the Caire et al. (Ch 10 §10.4) optimality bound?
Caire et al. scope
The Caire et al. theorem applies to the uncoded groupwise-key class: schemes where each user's mask is a deterministic linear combination of subsetwise keys.
CCESA is outside this class
CCESA's mask structure is randomized (the Erdős–Rényi graph is random). The mask configuration is no longer a deterministic groupwise key; it's a randomized object with probabilistic properties.
Implication
The Caire et al. lower bound does not bind randomized schemes. CCESA's is below the Bonawitz bound — but only because it operates in a different scheme class with weaker (probabilistic) guarantees.
ex-ch12-04
EasyFor users at edge density , compute approximate per-user degree in the CCESA random graph.
Expected degree = .
Edge probability
.
Expected degree
— far less than Bonawitz's . Each user has mask partners instead of all others.
Concentration
By Chernoff, every user has degree within of the expected value with high probability. Production deployments use the maximum-expected-degree as a worst-case bound.
ex-ch12-05
MediumVerify CCESA's correctness: show that the server's aggregate equals the true sum when the random graph is connected.
Pairwise masks cancel along edges.
Mask cancellation per edge
For each edge , users and contribute and respectively to their uploads. Summed: zero.
Sum over edges
. All edges contribute zero; aggregate is correct.
Self-masks
Self-masks are reconstructed from Shamir shares (as in Bonawitz §10.3) and subtracted by the server. Final output: .
Connectivity required
If disconnects, some pairs of users cannot share masks, leading to leftover masks in the sum. Reliability depends on connectivity.
ex-ch12-06
MediumProve the CCESA reliability bound: with is connected with probability for any constant .
Use the classical Erdős–Rényi connectivity result.
Classical threshold
Erdős–Rényi (1959): is connected with probability as if for any .
CCESA density vs. threshold
. Compare to threshold : — much larger than 1 for large.
Implication
CCESA's edge density is - times higher than the connectivity threshold. Connectivity holds with probability — in fact much smaller failure than the classical threshold result (since CCESA is far above the boundary).
ex-ch12-07
MediumCompute the per-round communication for CCESA at users, model size , edge constant . Compare with Bonawitz.
CCESA edge probability
.
CCESA aggregate DH
DH exchanges per round.
Bonawitz aggregate DH
DH exchanges per round.
Reduction factor
. CCESA needs fewer DH exchanges than Bonawitz at this scale.
Time savings
At 100s per DH: Bonawitz days; CCESA hours. Production-deployable for CCESA, infeasible for Bonawitz.
ex-ch12-08
MediumWhy does CCESA's privacy guarantee require edge probability (above the connectivity threshold)?
Connectivity for reliability
Below , the graph disconnects, making the aggregate uncomputable. So is needed for correctness.
Privacy margin
For privacy: every honest user must have an honest neighbor (not in the colluder set). At near the connectivity threshold, some honest users have very few neighbors; a colluder set covering one of them removes their honest connection.
Why $\sqrt{\log n/n}$
CCESA uses — a margin over connectivity. The margin ensures every user has multiple honest neighbors w.h.p., so privacy holds uniformly.
Lower bound
Section 12.3 Theorem 12.3.5 establishes as the lower bound. Closing the polylog gap to CCESA's is open.
ex-ch12-09
MediumSketch how CCESA handles user dropouts. What changes from Bonawitz's dropout handling?
Bonawitz dropout
Pairwise seeds Shamir-shared with threshold . Surviving users provide shares to reconstruct dropped seeds.
CCESA dropout
Same Shamir mechanism, but only over the sparse graph. Only Shamir shares per user (matching the graph degree). Reconstruction overhead drops proportionally.
Threshold validity
Shamir threshold must satisfy the same constraints as Bonawitz: . Within this region, CCESA works with the sparse-graph adaptation.
Summary
Same privacy guarantee, lower communication — CCESA's sparse graph reduces both regular protocol and dropout-handling overhead in tandem.
ex-ch12-10
MediumWhy must the CCESA graph seed be honestly generated? What attack is possible if the server controls the seed?
Adversarial graph attack
If the server picks the seed, it can adaptively choose a graph that isolates specific honest users — making them have no honest neighbors. Their masks don't cancel against any honest user, exposing their gradient to the server.
Effective coalition
With adversarial graph control, the effective coalition is potentially the entire user set (the server controls who each user shares with). Privacy guarantees vanish.
Production solution
Use a randomness source the server cannot manipulate: blockchain hash, NIST beacon, distributed coin-flipping. The seed is unpredictable and verifiable, making adaptive attacks impossible.
ex-ch12-11
HardProve CCESA's privacy guarantee at the sparse-graph density: .
Setup
Fix honest user and coalition of size , . Privacy fails for iff .
Probability of failure for $(k, \mathcal{U})$
. For and : for some .
Union bound
Number of (honest user, coalition) pairs: . . For sufficiently large in the edge density, , giving failure probability .
Conclusion
With probability , privacy holds uniformly over all users and coalitions. When it holds, CCESA's guarantee is Bonawitz-equivalent.
ex-ch12-12
HardFor CCESA at , estimate the constant in the failure probability .
Compute exponent
. For : .
Numerical
At , , : .
Failure probability
. Essentially zero. Even with colluders, the union-bound factor is — still bounded by if , which requires slightly larger. In practice, choosing gives more comfortable margin.
Operationally
At reasonable values, CCESA's privacy failure is so improbable that "Bonawitz- equivalent w.h.p." is operationally equivalent to "always".
ex-ch12-13
HardDiscuss CCESA's compatibility with Byzantine aggregation. Can ByzSecAgg-style filtering work over a sparse graph?
Direct composition
ByzSecAgg's coded distance computation requires every pair of users' shares to compute pairwise distances. With CCESA's sparse graph, only edges exist for some pairs — distance computation is undefined for non-edges.
Adaptation
One approach: compute distances only along graph edges; aggregate distance scores require additional graph-theoretic reasoning. Krum-style filtering on edge-only distances is approximate but feasible.
Open question
Whether CCESA-Byzantine composition achieves the same privacy and efficiency as ByzSecAgg-Bonawitz composition is open. The combination of sparse graph + Byzantine resilience is an active research direction (Chapter 18).
Practical guidance
For and Byzantine threats, use ByzSecAgg + dense graph (Chapter 11). For large- passive threats, use CCESA
- dense graph (Chapter 12). For large- Byzantine: open research.
ex-ch12-14
HardSketch a hierarchical CCESA construction: organize users into smaller cohorts, run CCESA per cohort, then aggregate cross-cohort. What is the achievable communication overhead?
Hierarchical structure
Partition users into cohorts of size each. Run CCESA within each cohort to produce a per-cohort masked aggregate. Aggregate the cohort outputs at the server.
Per-cohort cost
Within each cohort: DH + gradient. Total across cohorts: .
Cross-cohort
Server aggregates values. Negligible cost.
Optimized $m$
Total = — minimized when small. But too small loses some privacy (cohort-internal privacy threshold must be at most ).
Tradeoff
gives . Slightly worse than plain CCESA's by a polylog factor — but conceptually cleaner. Hierarchical CCESA is a useful production tool when implementations need cohort-based parallelism.
ex-ch12-15
ChallengeOpen problem. CCESA achieves overhead. The Erdős–Rényi connectivity threshold is , giving aggregate overhead . Can this gap be closed? What kind of construction might achieve ?
The gap
CCESA: aggregate. Lower bound (connectivity-based): . Gap: factor of .
Source of the gap
CCESA's edge density is higher than the connectivity threshold to ensure every honest user has an honest neighbor (privacy condition), not just connectivity.
Candidate constructions
- Expander graphs: random graphs with better-than-Erdős–Rényi vertex-isoperimetry. Privacy may hold at lower density.
- Bipartite constructions: separate the masking graph from the user-pair graph, giving more flexibility.
- Combinatorial designs (Steiner systems): explicit, deterministic structures with similar density to random graphs.
Status
Several candidates exist (FastSecAgg uses regular expanders; Kadhe et al. 2020). None currently achieves with full Bonawitz-equivalent privacy. Closing the gap is a current research direction.