SPAR-MPC Day 2 Breakout Sessions Mayank Varia 29 May 2014

Day 2 Breakout Sessions- 2 MV 5/29/2014 Lettered Breakout Session Topics A. Crypto research risks/rewards B. User language/interface design risk/rewards C. Potential SPAR-MPC program structures D. Use cases and likely impact E. Metrics for success and progress

Day 2 Breakout Sessions- 3 MV 5/29/2014 Session A: Crypto Research Risks/Rewards Goal: Determine which crypto research paths are important, which are feasible, and conclude which have the best risk/reward tradeoff Low-riskMedium-riskHigh-risk toolbox having a common API garbled circuits OT extension algebraic MPC ORAM Scaling to large networks MPC for non-standard connectivity threshold proactive adversary MPC formal proofs garbled RAM FHE FE leakage data access oblivious algorithms Understanding leakage for limited leakage types: e.g. Access patterns understanding semantic leakage Comparing general leakage graceful degradation of leakage mapping from info-theoretic to semantic leakage

Day 2 Breakout Sessions- 4 MV 5/29/2014 Best Risk/Reward Tradeoffs Compiling general programs into MPC with no leakage –Support rich code variety: loops, recursion, etc –Cryptographic proof of compiler correctness –No formal proof verification Data access pattern oblivious algorithms Implementing more MPC applications –Large networks, large data Restrict high-risk use-cases to more specific models

Day 2 Breakout Sessions- 5 MV 5/29/2014 Low-Hanging Fruit: Filling Out Our Toolbox Implementing common graph algorithms securely –Dijkstra in linear time –Matching Delegating smart phone computation to the cloud Implementing other specific applications of MPC

Day 2 Breakout Sessions- 6 MV 5/29/2014 Session B: User language/interface design risk/rewards Goal: Identify user-facing aspects of a potential SPAR-MPC tool that can be built in a 3-5 year research project Potential target users –Cryptographers: make a tool they can use first –Systems designers –Software developers –Lawyers: difficult in a 3-5 year project Build multiple interfaces for different users –Designer provides software description –Developer iteratively supplies application requirements –Display security/performance tradeoffs so lawyers can understand

Day 2 Breakout Sessions- 7 MV 5/29/2014 Session B: User language/interface design risk/rewards Incorporate crypto into the software development lifecycle –Design, Consult, Generate, Prove, Profile, and Visualize –Immediate response to the developer (not silent failure) while developing, compiling, profiling –Build framework of virtual functions: “don’t call us, we’ll call you” Learn from the distributed computing world –Literal: Learn how they handle variability & programming constructs –Figurative: Find proper level of abstraction to display to developers Domain-specific languages –Simple languages make proving easier (e.g., Unity) –Tweaks to mainstream languages (JVM,.Net) reduce learning time Evaluate through user studies: can an undergrad build what you want in < 100 lines of code? Metric for success: adoption

Day 2 Breakout Sessions- 8 MV 5/29/2014 Session C: Potential SPAR-MPC program structures Goal: Potential SPAR-MPC Program Structure Approach: Decompose the structure –Spatially: What would be addressed in parallel? –Temporally: What would we address over time?

Day 2 Breakout Sessions- 9 MV 5/29/2014 System Model (Spatial) Discussion SPAR-MPC Architectural diagram –Consensus: Human-interface tool is harder than crypto implementation/proof tool Layered model of toolkit Crypto+Proof Toolbox Middleware: Protocol Assembly Use case and evaluation

Day 2 Breakout Sessions- 10 MV 5/29/2014 Program Plan Phase I: Establish Baseline Capabilities Phase II: Expand capabilities, layered architecture Select use cases, develop data sets, micro-benchmarks and target architecture Add use cases, system benchmarks Baselining and Mature Adolescent Tech: ORAM-based computation, Compiling to HE Improve performance, add (multi-linear maps) and layer functionality Formalization: Select adversary model, proofs of correctness Formalization: Add adversary model, proofs of security and leakage User interactions: Requirement solicitation tool and initial implications User Interactions II: Connection to lower- level systems 1.Comparisons of known and adolescent technology 2.Proofs of correctness for primitives 1.Initial API Design 2.Improved performance of baseline 3.Broader set of applicable use cases and proofs

Day 2 Breakout Sessions- 11 MV 5/29/2014 Session D: Use Cases Goal: Understand likely use cases and benefit of secure multi- party computation to applications Driving factors: –Regulation Start with organizations: better understanding of privacy and potential tradeoffs than individuals –Organic adoption Technology must exist prior to adoption Build use cases from ground up –Start by making common operations very efficient –Instead of trying to optimize large computational all at once –Demonstrate common operations can be combined into larger system Wow factor: motivate the public –Killer application –Large scale compromises “Snowden”

Day 2 Breakout Sessions- 12 MV 5/29/2014 Mix of commercial/government applications Medical: –Pharmogenetics –Cloud patient data Trusted third parties Social networking –Location privacy/graph connections Insider information mitigation –Limit availability of all data Discrepancy between efficient MPC and application incentives for adoption –Potential to incentivize security: Pay users for privacy Regulate General Data Mining

Day 2 Breakout Sessions- 13 MV 5/29/2014 Session E: Metrics Goal: Identify metrics for success and progress of MPC protocol generation tools (not just MPC protocols themselves) and for SPAR-MPC research program Also identify program structures and their pros and cons in terms of amenability to testing/metrics

Day 2 Breakout Sessions- 14 MV 5/29/2014 Metrics, a partial list Efficiency – Both the compiler and the protocol –But runtime may be more valuable than compile time Usability – How sophisticated must the user be? Flexibility – How many options you give the user – e.g., 2PC and multiparty, malicious and semi-honest? Expressivity – How extensive is the specification capability? Adaptability/Extensibility - If some requirement changes, do we need to start over from scratch or can we modify the tool incrementally? Security – Many things could be measured here, needs to be well defined Use and adoption?

Day 2 Breakout Sessions- 15 MV 5/29/2014 Other discussions Multi-dimensional metrics vs. fixing parameters –User specifies efficiency constraints; tool determines relaxations and protocol to get that efficiency –User specifies privacy constraints; tool determines most efficient protocol satisfying the constraints Lack of clarity on end user and overarching motivations –Why is security being sacrificed? –Does the user know enough to make the right choices? What is leakage? Bits? Internal data structure information? Specific information? –Semantic meaning of leakage is hard to understand