# A Sum without Its Summands: Secure Aggregation under Dropout and Collusion Codex (AI) | English analytical review | Local draft v1 | 2026-10-25 ## Abstract Secure aggregation hides individual messages while intentionally disclosing an aggregate, making its privacy meaning inseparable from participant selection, collusion, and repeated releases. This analytical review examines those boundaries using selected original secure-aggregation protocols, original composition attacks, and official implementation documentation. It distinguishes adversarial corruption from random dropout, recovery thresholds from output ambiguity, and correct finite-domain summation from the application's intended numeric result. Two reproducible constructed figures quantify threshold recovery under independent client survival and the number of unknown summands remaining after collusion. A finite-field example checks threshold reconstruction and the ambiguity left by insufficient shares, while separate examples demonstrate pairwise-mask cancellation and disclosure through overlapping sums. These checks use only standard-library code and do not implement or certify a cryptographic protocol. We propose an evaluation that tracks phase-specific dropout, participant agreement, numeric encoding, and the information accumulated across related rounds. The resulting contract makes explicit what the server is allowed to learn and which assumptions justify that limit. It avoids treating a successful single-round privacy theorem as an automatic guarantee for malicious orchestration, robust learning, or unrestricted repeated output. ## 1. The sum is an intentional disclosure Secure aggregation lets a server learn an aggregate while concealing individual inputs beyond what that aggregate and permitted auxiliary information reveal. The qualification is central. A sum over one unknown contribution reveals that contribution; two carefully chosen overlapping sums may reveal a difference. Neither observation requires defeating the cryptographic mechanism that computed the sums correctly. This manuscript examines the joint contract among confidentiality, dropout recovery, collusion, and the application's choice of participants. We use selected original protocol papers, original attacks on composition, and official implementation documentation. The aim is not to propose a new protocol or reproduce a federated-learning benchmark. Instead, two constructed models separate a threshold's availability effect from the information disclosed by aggregate outputs. Small finite-field checks verify reconstruction and ambiguity under explicitly chosen parameters. The analysis argues that a deployment must state which clients are honest, when dropout is declared, what the server can choose, and how repeated outputs are governed. Without those conditions, the phrase only the sum is revealed can be both technically accurate and practically misleading. Author analysis or proposed verification. ## 2. What the protocol literature contributes Bonawitz and colleagues develop a practical failure-robust secure aggregation protocol for high-dimensional vectors, with security analyses under specified adversary models. Bell and colleagues reduce client overhead using sparse communication structure under their stated corruption and dropout conditions. FastSecAgg uses a multi-secret sharing construction and explicitly distinguishes adversarial corruption from random-subset dropout in its reported guarantees. These differences prevent a universal comparison based only on participant count. A protocol robust to a random dropout distribution does not automatically tolerate an adversary selecting the worst set. A semi-honest guarantee does not authorize treating a malicious coordinator as harmless. An asymptotic saving in client communication may coexist with different round structure, server work, setup, or vector-size assumptions. We therefore use these sources to map the design space, not to rank implementations whose parameters were not normalized here. The original Bonawitz paper was opened; the Bell and FastSecAgg records were inspected at abstract and metadata scope. Their published performance claims are not presented as measurements performed for this manuscript. Sources: cs2-14-1, cs2-14-2, cs2-14-3 ## 3. The functionality and its leakage Let U be the accepted participant set and each client contribute a vector over a finite ring or field. The ideal functionality releases the coordinate-wise sum for U, possibly together with public membership and status information. Security compares the real transcript with what an adversary could simulate from allowed inputs and outputs under the protocol's corruption model. It does not promise that the output contains no information about an individual. A useful application specification names the participant identifiers visible to the server, the vector dimension, the numeric encoding, the accepted set, and whether an abort reveals additional status. If the server chooses U adaptively, that choice is part of the privacy analysis. If colluding clients disclose their own inputs, the server can subtract those inputs from the aggregate. If all but one accepted participant colludes, the remaining input is exposed by the functionality itself. This is not a failure of simulation-based security. It is a mismatch between an application's privacy expectation and the information its selected computation is designed to release. Such mismatches must be resolved before optimizing cryptographic overhead. Author analysis or proposed verification. ## 4. Masks cancel only over the right set An elementary pairwise-masking illustration assigns an antisymmetric mask to every pair of clients. One endpoint adds a mask and the other subtracts it. Summing all masked inputs cancels every pairwise term. If a client drops out before contributing its masked vector, masks on edges connecting that client to survivors remain uncancelled, so the server cannot simply add the received vectors and obtain the intended sum. Practical protocols include carefully controlled recovery mechanisms, and the Bonawitz work is a central source for this design problem. Our illustration is intentionally simpler: deterministic small masks demonstrate the algebraic residual and its repair when the missing endpoint is publicly identified. The construction is not secure because its masks are fixed and known, and it must never be used as cryptographic code. Its value is explanatory. Dropout recovery is not merely a transport retry; it changes which secrets or masks must be reconstructed. Revealing the wrong combination of recovery information can expose a surviving client's input. Consequently, the accepted participant set and the recovery phase must be authenticated and interpreted consistently across honest clients. Sources: cs2-14-1 ## 5. Threshold recovery and collusion bounds In a threshold sharing abstraction, any t valid shares reconstruct a secret, while fewer than t shares provide no information under the sharing scheme's assumptions. A deployment needs enough surviving shares to reconstruct permitted recovery material and must prevent the adversary from obtaining enough shares of material that protects an honest survivor. This produces a feasibility relation between corruption, recovery threshold, and surviving participants, but that relation is not a complete secure-aggregation theorem. Our toy finite-field example uses a degree-two polynomial over the field with 257 elements, with the secret in its constant coefficient. Three shares reconstruct it. Given two fixed shares and an arbitrary candidate secret, exactly one pair of remaining polynomial coefficients fits those observations. Enumerating every candidate secret therefore leaves all 257 possibilities consistent. The program checks this finite instance and all three-share subsets of five generated shares. It does not test authenticated sharing, adaptive corruptions, distributed key exchange, or malicious recovery messages. Those mechanisms determine whether the threshold abstraction actually applies in a real protocol, and their omission is explicitly preserved in the artifact's scope. Author analysis or proposed verification. ## 6. A constructed dropout-availability model Assume n clients independently survive the relevant recovery phase with identical probability p. If t surviving shares are required, the probability of recovery is the upper tail of a binomial distribution. The first figure plots that probability for ten clients and thresholds five, seven, and nine as p varies. Every value is computed analytically; no simulated device population or observed dropout rate is claimed. The independence assumption is useful for a baseline and dangerous if forgotten. A power outage, software deployment, regional network failure, or server scheduling error can correlate many clients' failures. A malicious server may also manipulate the apparent survivor set unless the protocol prevents inconsistent views. The binomial curve cannot justify security against such an adversary. It instead asks a narrow operational question: under this stated independent-survival model, how sensitive is recovery to the threshold? The answer helps reveal why a parameter should not be selected solely from a privacy slogan. Increasing the threshold can strengthen one sharing condition while lowering completion probability, and the full protocol must show which security condition the threshold actually enforces. Author analysis or proposed verification. ## 7. Worked availability and privacy arithmetic With ten clients, threshold seven, and survival probability 0.8, the constructed recovery probability is 0.8791261184. The model independently verifies the closed-form binomial tail by enumerating every survival subset for the small population. At survival probability one, every threshold at most ten succeeds; at survival probability zero, every positive threshold fails. These endpoint checks detect mistakes that a smooth-looking plot can hide. Suppose an accepted aggregate contains seven clients and three of them collude with the server. Subtracting the colluders' known inputs leaves a sum of four honest contributions. This count is only a lower bound on unknown contributors when the corruption assumption is valid; it is not a differential-privacy parameter or a guarantee that each contribution is unrecoverable from auxiliary information. The second figure holds the accepted-set size at seven and varies the number of known colluding contributors. At six colluders, only one unknown remains, making the output directly identifying at the vector level. The figure therefore pairs a liveness calculation with an output-ambiguity calculation, rather than presenting one threshold as if it solved both problems automatically. Author analysis or proposed verification. ## 8. Overlapping aggregates form a counterexample Take four fixed scalar contributions with values three, five, seven, and eleven. One aggregate releases their sum, twenty-six. A second aggregate releases the sum of the last three, twenty-three. Subtracting the two public results reveals the first contribution, three. Every aggregate can be computed by a perfectly secure summation protocol, and each can satisfy a minimum group size greater than one. This constructed example assumes the relevant inputs remain unchanged across the two releases. Real federated-learning updates evolve, so the exact subtraction argument does not by itself establish recovery in arbitrary training workloads. It nonetheless refutes the unrestricted claim that a minimum group size alone guarantees privacy across releases. The original Multi-RoundSecAgg work investigates privacy leakage from participation patterns across training rounds, and the model-inconsistency work of Pasquini and colleagues studies a malicious server's control over model inputs. We use those papers for the composition concern while keeping our simpler arithmetic example separate from their attacks and evaluation results. Output governance must therefore consider related rounds and server-controlled context, not merely the cryptographic transcript of one successful round. Sources: cs2-14-4, cs2-14-5 ## 9. Model consistency and participant agreement The model-inconsistency source reports attacks that exploit differences in the models sent to clients. Its significance for system design is that a secure aggregation layer cannot ensure clients computed comparable updates unless that condition is supplied by the surrounding protocol. A server may learn more from a valid aggregate when it manipulates the functions whose outputs are being aggregated. A concrete evaluation should bind a round identifier, model digest, training configuration, and accepted participant-set commitment to each client's participation. Honest clients should have a protocol-defined way to detect incompatible context where the threat model requires agreement. This recommendation does not assert that a digest alone solves malicious aggregation: a coordinator can distribute a uniformly malicious model, and clients still need a policy for what computation they accept. The distinction is between consistency of context and acceptability of context. Both affect privacy but require different evidence. A round that aborts after a context mismatch should remain visible in analysis, since repeated targeted aborts may themselves reveal participation or help the coordinator shape later cohorts. Sources: cs2-14-4 ## 10. Numeric encoding and aggregate correctness Secure sums usually operate over a finite numeric domain, while learning applications reason about real-valued updates. Quantization, clipping, modular arithmetic, and division by an accepted-set weight connect those domains. If their conventions differ across clients, a cryptographically correct aggregate can be numerically wrong for the intended training step. If the modulus is too small for the allowed sum, wraparound can change the interpretation without causing any cryptographic verification failure. Our finite-field checks use small values only to make reconstruction transparent; they are not a recommended encoding for model updates. A deployment should state the representable input range, maximum accepted population or total weight, rounding rule, and decoding convention. Weighted averages require special care when clients drop out: both the numerator and the intended denominator must correspond to the same accepted set. Reporting a sum from survivors while dividing by the original population produces a biased result even if confidentiality holds. Numeric correctness and privacy should thus have separate reference oracles, and test vectors should include boundary magnitudes, negative values, and populations at the configured maximum. Author analysis or proposed verification. ## 11. Aggregation privacy does not provide robust learning A malicious participant can submit an adversarial vector that falls within the protocol's accepted syntax. Secure aggregation conceals that vector from the server while adding it to the sum, so privacy can complicate individual-input inspection. This does not mean privacy and robustness are inherently incompatible; it means the chosen functionality must specify any validation or robust estimation that the application requires. Input range proofs, clipping enforced at a trusted client boundary, secure computation of a robust statistic, or accountable enrollment each introduce different assumptions and costs. A plain sum does not automatically provide these properties. The evaluator must avoid crediting a cryptographic protocol with detecting poisoned data unless that detection is part of its mechanism and analysis. Similarly, differential privacy requires an appropriate randomized release mechanism and privacy accounting; secure aggregation can support its deployment but does not supply it merely by hiding summands. The design problem is a composition of distinct goals: conceal individual messages, limit what outputs reveal, and constrain the influence of malicious inputs. A result about one goal should not be silently promoted to the other two. Author analysis or proposed verification. ## 12. Implementation evidence and deployment boundaries Flower's official documentation identifies server and client components implementing SecAgg and SecAgg+, and describes how those components sit within its application and transport structure. This establishes the existence and placement of implementation interfaces, not an independent security audit of a deployed configuration. It also illustrates why protocol selection alone is not enough: configuration, client enrollment, authentication, and phase transitions must match the intended threat model. A deployment review should pin versions and record which parties persist recovery shares, how those shares are erased, and whether retries can cross round boundaries. A message from an earlier round must not be accepted as evidence for a later survivor set merely because it has a recognizable client identifier. Recovery logs should not expose seeds or reconstructed masks. Operational dashboards should distinguish clients missing before setup from clients missing after masked-input submission, because those states can require different recovery actions. These are proposed checks, not assertions of defects in Flower. They provide a path from paper-level assumptions to concrete implementation evidence that can be collected without claiming the paper's theorem applies automatically. Sources: cs2-14-6 ## 13. An evaluation that can fail meaningfully The proposed protocol evaluation uses an independent plaintext oracle for the intended accepted-set sum and a transcript checker for phase and context consistency. Generate dropout schedules at every phase boundary, including clients that reconnect with delayed messages. Vary colluding clients up to the supported bound and include configurations just beyond it as documented out-of-contract cases. A test should identify whether a failure concerns liveness, incorrect aggregation, or excess disclosure. For repeated releases, retain a public matrix describing which clients contributed to each output and analyze the information those outputs reveal under explicitly stated input assumptions. Include the four-contribution differencing example as a regression test for any claimed cohort-only privacy rule. The executable companion independently checks binomial availability, finite-field reconstruction and ambiguity, pairwise-mask cancellation, and the overlapping-output counterexample. None of these checks proves a production protocol secure. They verify that the manuscript's arithmetic and distinctions are internally coherent and provide small fixtures for a future implementation study. Real evaluations must additionally test cryptographic authentication, message parsing, adversarial phase behavior, and the exact server powers assumed by their security model. Author analysis or proposed verification. ## 14. The complete contract for a private sum A defensible secure-aggregation deployment states the sum it intends to release, the participants included, the maximum collusion, the dropout model, the recovery mechanism, and the policy governing repeated related outputs. It also records what happens when those assumptions fail. An abort is not equivalent to an incorrect sum, and a correct sum is not equivalent to harmless disclosure. The constructed results show why these distinctions have operational consequences. Raising a recovery threshold changes the completion probability under independent failures. Increasing collusion shrinks the number of unknown summands. Overlapping releases can reveal an individual even when each round has several participants. These observations are deliberately modest and reproducible; they do not rank protocols or invent experimental privacy guarantees. The next research questions concern correlated availability, adversarial cohort selection, and efficient enforcement of consistent application context. Progress requires carrying cryptographic assumptions through the orchestration layer and into the release policy. Only then can the statement that the server sees a sum be evaluated as a meaningful privacy claim. Author analysis or proposed verification. ## Mathematical model y=\sum_{i\in U}x_i\pmod q Coordinate-wise ideal sum for accepted set U over the declared finite domain q; does not hide what y implies. \widetilde{x}_i=x_i+\sum_{j>i}m_{ij}-\sum_{j