Google Rejects Generic MPC Over Data Center Bandwidth Constraints
Real World Crypto
Enterprise multi-party computation requires abandoning academic generic compilers for custom primitives because network bandwidth contention and mobile client churn create prohibitive bottlenecks that theoretical models ignore.
AI-assisted summary of Ben Kreuter RWC 2017 — original source. Check the original for full context.
Source published:
Key ideas
- Academic MPC research prioritizes generic compilers and extreme threat models, but industrial deployments at Google favor custom primitives due to massive network bandwidth contention in data centers and cellular networks. (0:00)
- For enterprise B2B settings, covert and auditable semi-honest security models are often sufficient because legal contracts provide enforceable dispute mechanisms, while consumer mobile settings strictly require malicious security. (3:40)
- Google runs a production Private Set Intersection system for ads attribution that uses Diffie-Hellman intersection and Paillier additive homomorphic encryption rather than garbled circuits, which become inefficient on sparse sets. (10:01)
- To aggregate keyboard prediction models across mobile devices without leaking raw keystrokes, Google developed a double-masked secure aggregation protocol using PRG seeds and threshold secret sharing to handle unexpected client dropouts. (16:15)
Detailed notes
## Background Published on YouTube by the Real World Crypto channel on February 2, 2017, this video captures a technical presentation delivered by Ben Kreuter. According to the show notes, the talk is part of the Real World Crypto conference series showcasing practical and applied cryptography.
## TL;DR Ben Kreuter addresses the persistent disconnect between academic multi-party computation (MPC) research and production realities at companies like Google. He outlines why generic compilers and extreme threat models are often ill-suited for industry, showing instead how pragmatic models like covert security and bandwidth-conscious designs enable real-world deployments. Kreuter presents two practical case studies: a private set intersection protocol combining Diffie-Hellman operations with Paillier homomorphic encryption for advertising attribution, and a double-masked secure aggregation scheme paired with differential privacy for predictive keyboard training across mobile devices.
## Atmosphere & style The talk has a candid, pragmatic, and wryly humorous tone that strips away theoretical idealism in favor of engineering reality. Kreuter speaks with an engaging, direct narrative style, drawing knowing laughs from the technical audience when recounting how software engineers assume MPC is impossible and corporate lawyers treat basic arithmetic as negotiable. Listening to the session feels like receiving an unvarnished dispatch from the cryptographic engineering trenches, grounding theoretical rigor in the hard physical limits of data center network uplinks and flaky smartphone battery life.
## Bulletin - [00:00](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=0s) Academic MPC research prioritizes generic compilers and extreme threat models, but industrial deployments at Google favor custom primitives due to massive network bandwidth contention in data centers and cellular networks. - [03:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=220s) For enterprise B2B settings, covert and auditable semi-honest security models are often sufficient because legal contracts provide enforceable dispute mechanisms, while consumer mobile settings strictly require malicious security. - [10:01](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=601s) Google runs a production Private Set Intersection system for ads attribution that uses Diffie-Hellman intersection and Paillier additive homomorphic encryption rather than garbled circuits, which become inefficient on sparse sets. - [16:15](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=975s) To aggregate keyboard prediction models across mobile devices without leaking raw keystrokes, Google developed a double-masked secure aggregation protocol using PRG seeds and threshold secret sharing to handle unexpected client dropouts.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=0s) Google relies on theoretical cryptographic frameworks, using impossibility results to avoid unachievable designs and the simulation paradigm to catch subtle flaws in production systems. - [03:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=220s) In B2B deployments, data privacy is prioritized far above output correctness, and the threat of litigation makes covert or auditable semi-honest security commercially viable. - [05:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=340s) Network bandwidth contention, rather than raw computation time, is the primary deployment bottleneck in Google data centers and mobile networks. - [05:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=340s) Mobile MPC must handle unique operational barriers including carrier-grade NATs, zero consumer PKI, battery constraints, and uncontrolled mid-protocol dropouts. - [10:01](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=601s) Google implemented ads attribution via Diffie-Hellman Private Set Intersection and Paillier homomorphic encryption to compute aggregate spend without exposing customer identities. - [13:16](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=796s) Garbled circuits fail for sparse real-world set intersection because vector representations scale with the entire universe size rather than the actual number of elements. - [16:15](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=975s) Applying local differential privacy directly on individual mobile devices requires excessive noise that destroys model utility, necessitating MPC-based aggregate privacy. - [18:09](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1089s) A double-masking scheme combining pairwise PRG masks and individual secret seeds prevents mobile server compromise when slow clients submit data after dead dropouts are reconstructed. - [20:14](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1214s) Distributed differential privacy noise generation remains an open challenge for malicious consumer settings with thousands of participants. - [21:28](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1288s) Production adoption of MPC across the wider industry hinges on generic protocols that reduce bandwidth overheads without high fixed constant factors. - [25:48](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1548s) Data poisoning in federated secure aggregation remains an open research problem, though unstructured malicious inputs often degrade the aggregate into easily detectable random noise. - [26:32](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1592s) Multi-round privacy degradation from repeated linear queries over overlapping mobile cohorts can be mitigated by scaling cohort sizes and injecting additional calibrated noise.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=0s) The Divide Between Academic MPC and Industry Reality
Ben Kreuter opens his talk by addressing a recurring interaction he experiences whenever he mentions multi-party computation (MPC) to colleagues in the cryptographic research community. Researchers immediately ask whether Google is running garbled circuits or the Goldreich-Micali-Wigderson (GMW) protocol, forcing him to disappoint them with a blunt “nope.” This disconnect forms the core theme of his presentation: an exploration of why academic cryptography and industrial deployments at companies like Google have diverged in methodology, followed by two real-world case studies illustrating MPC in business-to-business (B2B) settings and on consumer smartphones.
In academic literature, MPC research has overwhelmingly prioritized generic protocols capable of taking any arbitrary polynomial-time functionality and compiling it down into an executable distributed protocol. From a developer's perspective, this promise is theoretically ideal because software engineers would only need to define inputs, target functions, and output recipients without ever having to design custom cryptographic primitives. Furthermore, theory has leaned heavily toward the strongest security guarantees—such as full malicious security and complex concurrent composition frameworks—proving fundamental feasibility theorems that allow computations to proceed securely even when every other party in the world is adversarial.
Despite not adopting generic compilers directly, Kreuter emphasizes that Google relies heavily on theoretical cryptography. Formal security definitions provide the necessary framework for reasoning about protocols, while feasibility and impossibility results keep engineering teams from wasting time pursuing mathematically unachievable designs. Kreuter notes that the academic simulation paradigm is an essential engineering tool, explaining: “On more than one occasion I have actually found a security problem in one of our designs by trying to write the simulator for it.”
- Academic MPC focuses primarily on generic compilers for arbitrary functions and extreme threat models (malicious security, concurrent composition). - Theoretical feasibility proofs establish what is possible, while impossibility results prevent engineering teams from pursuing dead ends. - The simulation paradigm (demonstrating that an ideal-world simulator can produce an execution transcript indistinguishable from real protocol runs) directly catches design flaws in production systems.
---
[03:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=220s) Pragmatic Security Models: Semi-Honest, Covert, and Malicious
When evaluating security models for actual deployments, theoretical rankings do not always reflect commercial requirements. Kreuter explains that the semi-honest (honest-but-curious) model provides far more practical value than academics often credit. He likens it to forward secrecy: as long as a party has not cheated yet, historical interactions remain protected. In corporate environments, protocols that achieve covert security or lie just beneath it—where cheating attempts risk detection—are frequently sufficient. Because enterprise participants enter into binding legal agreements, formal dispute mechanisms alter the risk landscape: “That's actually good enough in a lot of cases especially in business-to-business settings where contracts can be used; you can sue people.”
Industrial applications also separate privacy from correctness in ways standard models do not fully capture. While malicious security guarantees both privacy and exact correctness, commercial applications often care substantially more about preventing data leakage than preventing subtle output manipulation. Kreuter specifically praises the authors of the covert security model, recalling that it was deliberately designed for realistic applications, and calls it arguably the most practical model for B2B deployments. Conversely, consumer environments break these assumptions: when protocols interact with anonymous mobile phone users who cannot be taken to court, malicious security and non-malleability become mandatory, despite being significantly more expensive to compute and communicate.
- Semi-honest guarantees act like forward secrecy, protecting prior computations provided no breach of protocol has yet occurred. - In B2B ecosystems, the risk of auditability and litigation makes covert or auditable semi-honest security commercially viable. - In business deployments, data privacy is prioritized far higher than output correctness, whereas theoretical models typically bind both together. - Consumer-facing deployments cannot rely on legal recourse, making malicious security and robust non-malleability necessary.
---
[05:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=340s) Deployment Bottlenecks and Mobile Device Constraints
The fundamental tension between academic benchmarks and enterprise systems lies in how resource consumption is measured. Cryptographic papers routinely evaluate protocols based on total end-to-end execution time or peak transaction throughput without dissecting the underlying resource costs. In reality, computation is rarely the limiting factor. In a Google data center, thousands of high-performance servers share network uplinks; running heavy MPC protocols on an ongoing basis creates severe network contention both with internal workloads and across external connections. Network bandwidth is almost always the most constrained and expensive resource, a constraint that applies equally to mobile networks sharing limited wireless spectrum. Consequently, Google only deploys a protocol if its concrete business value clearly exceeds this networking overhead.
Deploying MPC to consumer devices introduces severe operational hurdles that generic academic frameworks rarely handle:
```mermaid flowchart TD accTitle: Mobile MPC Constraints accDescr: Flow diagram illustrating consumer smartphone constraints including NAT routing, churn, and Sybil vulnerabilities.
subgraph MobileEnvironment["Mobile Network Constraints"] A["Carrier-Grade NAT / Firewall"] -->|"No direct P2P"| B["Cloud Relay Service"] C["Battery / Energy Limits"] -->|"Restricts heavy crypto"| B end
subgraph FailureModes["Device Reliability & Attacks"] D["High Churn & Random Dropout"] -->|"Device dies mid-message"| E["Privacy Leakage / Stalled Protocol"] F["Sybil Entities"] -->|"Simulated devices"| G["Collusion & Re-identification"] end
B -.-> D ```
Smartphones sit behind carrier-grade NATs, preventing direct peer-to-peer connections and forcing all traffic through intermediate cloud relays. There is no reliable public key infrastructure (PKI) across consumer endpoints. Furthermore, cost on mobile cannot be measured like a desktop or data center; battery draw and energy consumption dictate whether an algorithm is viable. Mobile phones experience constant churn and drop offline at arbitrary steps. If a phone dies after transmitting only half a cryptographic payload, poorly designed protocols can permanently compromise the user's privacy or stall entirely. While theory states that a protocol can either survive arbitrary participant dropout or maintain security against universal collusion, real systems must prioritize completion, forcing engineers to actively prevent large-scale Sybil attacks and colluding device coalitions.
Kreuter remarks on the operational risk of multi-party architectures that rely on external infrastructure: “If you're trying to deploy a system it's not really a good thing if some third party can stop playing and then your system stops working.”
- Academic evaluations frequently overlook network uplink contention, which represents the most expensive resource both in data centers and over cellular networks. - Mobile phones lack direct peer-to-peer addressability due to carrier NATs and possess no standardized global PKI. - Energy and battery consumption are primary operational constraints on mobile clients. - Uncontrolled device failure mid-protocol can leak private inputs or break systems like oblivious RAMs (ORAMs) that require complete runs. - Commercial designs favor guaranteed completion over universal collusion resilience, requiring robust mitigation against simulated Sybil phones.
---
[10:01](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=601s) Business Applications: Private Set Intersection for Ads Attribution
To demonstrate how these principles translate into production, Kreuter presents an advertising attribution architecture based on Private Set Intersection (PSI). He invokes the classic retail dilemma—often attributed to a merchant or tractor salesman—who invests substantial capital in advertising campaigns but cannot verify which sales were generated by ad impressions. Advertisers demand rigorous attribution metrics to justify marketing spend, yet direct data sharing between the ad platform and the merchant is impossible.
Google maintains sensitive internal records detailing which accounts were served advertisements, while the retail merchant retains proprietary purchase records detailing exactly who bought merchandise and how much money they spent. Neither entity can disclose raw customer identifiers to the other due to strict user privacy obligations and commercial confidentiality.
To resolve this impasse, Google employs an augmented private set intersection protocol:
```mermaid flowchart LR accTitle: PSI Ads Attribution Flow accDescr: Flow of Diffie-Hellman PSI with Paillier homomorphic summation between Google and an advertiser.
subgraph Parties["Joint Computation"] G["Google Data<br/>(Ad Impression Keys)"] A["Advertiser Data<br/>(Customer Keys + Purchase Values)"] end
subgraph MPC["DH-PSI + Homomorphic Sum"] P["Compute Intersection Size"] H["Paillier Homomorphic Sum<br/>(Total Spend)"] end
G --> P A --> P A --> H P & H --> OUT["Final Aggregate Metrics<br/>(No Individual Identity Revealed)"] ```
Rather than revealing the raw identities of the users who overlap, the protocol intersects on a common pseudonymized key and computes the cardinality of the match. Furthermore, the protocol binds the transaction values to these keys and applies an additively homomorphic encryption scheme (such as Paillier) to aggregate the total dollars spent by matched buyers. This yields the exact aggregate conversion revenue and conversion volume of the ad campaign without disclosing whether any specific individual viewed an advertisement or bought a tractor. Kreuter notes that using a custom Diffie-Hellman style intersection paired with additive homomorphic encryption allows the entire sum operation to complete rapidly without resorting to complex, high-overhead generic circuits.
- Advertising attribution calculates campaign effectiveness by linking ad impression logs with merchant sales records. - Raw customer datasets cannot be shared between Google and advertisers due to privacy guarantees and regulatory obligations. - The deployed protocol leverages a Diffie-Hellman-based Private Set Intersection paired with additively homomorphic encryption (such as Paillier). - The protocol outputs only aggregate statistics—intersection size and total spending sum—preventing both parties from learning which individual users converted.
[12:08](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=728s) Convincing Stakeholders: Lawyers, Managers, and Engineers
Ben Kreuter reflects on the practical, human challenge of bringing cryptography into production. The simplicity of a protocol is not merely an engineering convenience; it is a critical organizational tool. To ship a system, one must persuade non-technical managers, legal counsel, and the software engineers responsible for writing the code. Kreuter notes that opinions vary widely on which group is the hardest to win over. Talking to legal teams can be surreal because standard mathematical facts do not always carry final weight:
> “The lawyers are interesting because you can show them a proof and you know two plus two equals four is a negotiable statement here so it's interesting talking to them.”
In contrast, engineering managers tend to trust technical expertise, a dynamic Kreuter notes was established before he joined his team. The most stubborn pushback often comes from software engineers themselves:
> “Software engineers I think are the worst because they already assume this is impossible so you first have to go and undo everything they've learned about crypto and then rewrite all of it.”
[13:16](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=796s) Why Garbled Circuits Fail for Sparse Set Intersection
Kreuter addresses an obvious theoretical alternative: why not simply use garbled circuits? Work from fellow graduate students at the University of Virginia suggested garbled circuits could match or beat custom protocols for private set intersection (PSI). On paper, if elements are expressed as bit vectors, one needs only two garbled circuit blocks per bit, with adders costing roughly one AND gate per bit. For 16-bit values, the performance appears competitive.
However, Kreuter explains that in real-world deployment, every underlying assumption collapses: - 16 bits is far too small for practical identifiers, and adders become prohibitively expensive at scale. - Vector representations are impractical because real-world datasets are extremely sparse within the universe of possible elements. - Custom elliptic-curve protocols scale linearly with the actual number of elements in the set, sending one curve element per item. A bit-vector garbled circuit, by contrast, must transmit a bit for every potential element across the entire universe. - If one tries to avoid bit vectors and instead performs the set intersection dynamically inside the circuit, the online computational and communication costs explode.
Consequently, garbled circuits fail to remain competitive for this specific workload.
[15:02](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=902s) Practical Considerations and Future Directions
Reflecting on remaining operational challenges, Kreuter highlights the difficulty of establishing common identifiers between internal user data and disparate third-party datasets. The system relies on a post-facto audit mechanism to verify that neither party cheated during the exchange, which proves vital in production environments. He also laments the friction introduced by compliance mandates, defining arbitrary legal requirements as:
> “Arbitrary lawyer imposed things are things that have no relevance to computing the results correctly and no relevance to real security but are required for reasons we don't fully comprehend.”
Looking ahead, Kreuter identifies several active areas for future improvements: - Achieving malicious-model security without introducing massive computational overhead. - Adding non-malleable security properties for downstream applications. - Expanding computation beyond simple additions into cumulative functions over the intersection, where specialized garbled circuits might eventually find practical utility.
[16:15](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=975s) Consumer Applications: Privacy-Preserving Keyboard Model Aggregation
Moving from enterprise data matching to consumer mobile devices, Kreuter examines federated machine learning, focusing specifically on predictive text keyboards on smartphones. While local models train on an individual's typing behavior, predictive accuracy improves dramatically when models across millions of phones are combined into a global model via linear combinations or weighted averages.
Uploading raw model updates directly to Google servers would constitute a massive privacy violation:
> “The downside here is that your local model reveals what you type so you'd be sending a transcript of everything you've ever typed at least over some period to us and we don't want that data from you and you don't want to give it to us.”
Applying differential privacy directly on individual phones prior to upload proves impractical. Because each device represents an effective dataset of size one, the magnitude of local noise required to guarantee differential privacy would destroy the utility of the model update. Instead, the system aims to apply differential privacy to the aggregated output across the entire population using multi-party computation (MPC).
[18:09](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1089s) Scalable Masking and Handling Dropped Connections
To securely compute a linear combination across thousands or millions of untrusted consumer phones, the design adopts a pairwise linear secret sharing approach. Pairs of participating devices agree on a shared random mask; one party adds the mask to its vector while the other party subtracts it, ensuring all masks cancel out when the server sums the aggregate.
```mermaid flowchart LR accTitle: Double-Masked Secure Aggregation Architecture accDescr: Shows how device inputs are protected with PRG pairwise masks and individual masks to tolerate dropouts.
subgraph Inputs["Participating Devices"] D1["Device 1: x₁ + PRG(s₁₂) + PRG(b₁)"] D2["Device 2: x₂ - PRG(s₁₂) + PRG(b₂)"] end
subgraph Aggregator["Google Server"] Sum["Sum Received Vectors<br/>(Pairwise PRG seeds cancel)"] end
subgraph Reconstruction["Threshold Share Reconstruction"] Unmask["Server unmasks surviving bᵢ<br/>or reconstructs sᵢⱼ for dropouts"] end
Inputs --> Aggregator Aggregator --> Reconstruction ```
Transmitting full random vectors between every pair would cause communication to scale quadratically. Instead, devices exchange cryptographic keys using a Diffie-Hellman style key exchange and expand them locally via a pseudorandom generator (PRG) stream cipher.
A critical engineering obstacle is handling client dropouts and high network latency on mobile devices. If a phone disconnects mid-protocol, its pairwise masks will not cancel out. While sharing Shamir secret shares of the pairwise PRG keys would allow the server to reconstruct missing masks, a subtle failure mode emerges: if a client is merely slow rather than offline, it might submit its masked input after its secret keys have already been reconstructed, completely exposing its raw data to the server.
To resolve this, the protocol implements a double-masking scheme. Each client applies both a pairwise PRG mask and an individual private PRG seed ($b_i$). Devices distribute threshold secret shares for both keys. When the aggregation deadline passes, the server announces which clients dropped offline and which completed: - For dropped clients, surviving devices reveal shares of the pairwise seed ($s_{ij}$), allowing the server to strip the incomplete pairwise mask from the sum. - For surviving clients, peers reveal shares of the individual seed ($b_i$), allowing the server to unmask the final combined total without exposing individual updates.
[20:14](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1214s) Differential Privacy and Distributed Noise Generation
For final output privacy, the aggregate must be protected with differential privacy. Kreuter outlines two approaches: 1. **Server-side noise injection:** The central server computes the raw aggregate and adds noise before releasing the model. This allows the server to see the non-differentially private aggregate. While this might be tolerable given that Google already provides the mobile operating system and enforces internal data controls, it is not ideal from a zero-trust perspective. 2. **Distributed noise injection:** Clients add tiny amounts of noise locally. When thousands of local noise contributions are summed during aggregation, they combine to form the exact distribution required for differential privacy at the aggregate level.
Kreuter leaves an open challenge for the research community: developing an efficient distributed noise generation protocol that scales to thousands of participants and remains strictly secure against malicious adversaries, who face fewer accountability constraints on consumer hardware than in enterprise settings.
[21:28](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1288s) Audience Q&A: MPC Research Desiderata and Production Debugging
Following the presentation, Kreuter answers questions regarding industry needs, production timelines, and data leakage:
- **Wishes for academic research:** An audience member asks what Google and the broader engineering community need from MPC researchers. For Google's internal deployments, Kreuter requests generic protocols with drastically lower bandwidth consumption, such as fully homomorphic encryption (FHE) without prohibitive constant factors, or garbled circuit protocols offering sublinear communication without high fixed overheads. For the broader industry, he emphasizes practical, developer-friendly frameworks: > “Once we have these generic protocols that are really practical enough for more problems that will lead to this sort of MPC Renaissance because I think there's a lot of problems out there that people need to solve and I think people are aware of that it just hasn't you know the cost so far seems to be outweighing the benefits for a lot of people.” - **Deployment timelines and debugging:** In response to a question about running systems in production, Kreuter confirms that the mobile keyboard aggregation system will be deployed soon, while the enterprise PSI system is already live in production. On maintaining MPC pipelines without violating privacy constraints, he delivers a blunt assessment: “Debugging is hard.” - **Preventing memorization and reconstruction attacks:** An attendee raises the 2006 AOL search data disaster, asking how Google prevents federated predictive keyboard models from inadvertently memorizing and leaking rare, sensitive strings such as user passwords. Kreuter begins addressing this challenge as the segment concludes.
[24:12](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1452s) Differential Privacy and Output Protections in Model Merging
Ben Kreuter explains how differential privacy provides a mathematical guarantee when merging distributed machine learning models. Assuming one already has the merged model, adding carefully calibrated noise drawn from the appropriate distribution ensures that no individual user's input exerts an outsized influence on the final result. In high-level terms, excluding any small subset of the training data leaves the output distribution identical or computationally indistinguishable, making it possible to extract broad population aggregates without exposing specific individual records. This property aligns well with practical mobile phone applications, such as predicting text via Markov chains, where the system only needs to learn frequent transitions and high-probability contacts rather than rare individual occurrences.
```mermaid flowchart LR accTitle: Differential Privacy Noise Pipeline accDescr: Raw model updates are merged into an aggregate and combined with calibrated noise to produce a differentially private output. subgraph ClientData["Client Updates"] C1["Client 1 Update"] C2["Client 2 Update"] C3["Client 3 Update"] end subgraph Merging["Secure Aggregation"] AGG["Merged Model"] end subgraph DPNoise["Privacy Mechanism"] NOISE["Calibrated Noise"] OUT["Differentially Private Aggregate"] end ClientData --> AGG AGG --> OUT NOISE --> OUT ```
An audience member asks whether differential privacy is genuinely the ideal notion for these applications, or if researchers should explore alternative formulations—such as computing the maximum over set sums or enforcing strict threshold cutoffs to suppress anything beneath a certain frequency. Kreuter acknowledges the current state of the art while welcoming broader theoretical exploration:
> “So I think the differential privacy property is the best one that we have right now I would love to see research on new ways to think about that as I said theoretical results have a lot of value for that very reason.”
He encourages the audience to pursue alternative models and publish new theoretical frameworks for the wider community.
[25:48](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1548s) Handling Malicious Inputs and Poisoned Secret Shares
The discussion turns to active adversaries and data poisoning during federated aggregation. An audience member asks what prevents a client from submitting outright garbage inside their secret shares: because the shares are blinded, the server cannot inspect individual contributions to verify their validity, yet summing malicious garbage with genuine inputs could poison the entire aggregated model.
Kreuter explains that this challenge is approached from two angles: it remains an active open research problem, but practical deployments benefit from the fact that corrupted model updates typically degrade the entire output into recognizable noise. In practice, genuine machine learning parameters look markedly different from random vectors. If system constraints force cheating participants to generate nothing more structured than random noise, the resulting output becomes readily distinguishable from a functional model and can be rejected or filtered accordingly.
[26:32](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=1592s) Non-Affine Functions on Intersections and Multi-Round Privacy Leakage
The session concludes with questions regarding computation on set intersections and recurring multi-round queries. When asked whether there are compelling non-trivial functions to compute over private set intersections, Kreuter observes that standard paired private intersection protocols readily support affine functions. Any workload requiring non-affine operations presents a clear challenge where new cryptographic primitives would be required, though he notes that he cannot provide specific proprietary examples on the spot.
Another audience member raises the issue of privacy degradation across multiple rounds: if the server computes averages over changing, overlapping subsets of users over time, the combined outputs could allow an observer to reconstruct private participant data through linear algebra. Kreuter confirms the risk and points back to differential privacy as the standard tool to bound this leakage. By scaling up the participant cohort sizes, systems can inject enough noise across successive queries to offset multi-round composition without degrading overall model utility:
> “By taking a large enough sample you can get away with actually adding more noise than would be needed for just one round of the of the application and I think I'm being told that we are done we do either sorry you can come chat with me in the back if you have more questions.”
With the session time expiring, Kreuter invites attendees with remaining questions to continue the discussion off-stage.
## Notable quotes > [05:40](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=340s) If you're trying to deploy a system it's not really a good thing if some third party can stop playing and then your system stops working. — Ben Kreuter
> [00:00](https://www.youtube.com/watch?v=ee7oRsDnNNc&t=0s) On more than one occasion I have actually found a security problem in one of our designs by trying to write the simulator for it. — Ben Kreuter
## Mentioned Ben Kreuter, Google, Goldreich-Micali-Wigderson, Diffie-Hellman, Paillier, University of Virginia, AOL
## Video description Technical talks from the Real World Crypto conference series.
[Source](https://www.youtube.com/watch?v=ee7oRsDnNNc)