Secure Aggregation in Federated Learning (2D)

Round Controls

Clients 6

Mask magnitude 2.0

What the Server Sees

Press "Run" to start round 1.

True aggregate ‖Σuᵢ‖

0.00

Server-reconstructed ‖Σ‖

0.00

Reconstruction error

0.000

Any single client's true update visible to server?

No — masked

How it works

Each client i holds a private local update vector uᵢ ∈ ℝ⁵ (e.g. a gradient or weight delta, drawn here per dimension for visualisation as bars). Before sending anything, every unordered pair of clients (i, j) agrees on a random pairwise mask vector s_ij (derived from a shared secret, e.g. a Diffie–Hellman key). Client i adds +s_ij to its own accumulator, client j adds −s_ij to its own — so mask contributions are antisymmetric per pair. Client i sends the server not uᵢ but a masked version:

yᵢ = uᵢ + Σⱼ s(i,j)   where s(i,j) = −s(j,i)

Server computes:  Σᵢ yᵢ = Σᵢ uᵢ + Σᵢ Σⱼ s(i,j)
                        = Σᵢ uᵢ + 0     (every pairwise term cancels)

Because the masks are pairwise-antisymmetric, they vanish once every client's masked value is summed — the server learns the exact aggregate Σuᵢ, but cannot invert any single yᵢ back to uᵢ without knowing every pairwise mask. This is the core idea behind Google's Secure Aggregation protocol used in production federated learning.

Server view — only the masked bars (red) leaving each client are shown; each one looks like noise on its own.
Debug view — additionally reveals the true raw uᵢ each client actually holds (green bars), for comparison.
Client dropout — if a client vanishes after masks are agreed but before sending, its partners' masks no longer cancel and the naive sum drifts off the true aggregate — the reason real deployments add Shamir secret-sharing of the masks so surviving clients can reconstruct and remove a dropped client's contribution.

Server Client raw update (debug) Masked update in flight