Making Secure Computation Practical IBM: Craig Gentry, Shai Halevi, Charanjit Jutla, Hugo Krawczyk, Tal Rabin, NYU: Victor Shoup SRI: Mariana Raykova Stanford: Dan Boneh UC Irvine: Stanislaw Jarecki

Time for Secure Computation The time has come for secure-MPC to enter computing mainstream Like public-key cryptography in the 1990’s The problems are here So are the solutions At least in principle, need to push it to practice SPAR-MPC should be about technical tools to help make it happen Performance is just one aspect, and not always the main one. Tool support for design, analysis, and implementation is as important.

This Presentation Useful directions Musings about automation Protocols for huge crowds Semantic leakage Computation with RAM complexity SWHE-based protocols Comparing MPC technologies Musings about automation Computer-aided design/implementation/proofs

Protocols for Huge Crowds Need for private computing with a huge number of (loosely-connected?) parties Cars on highway collect road-hazard info, smart phones report nearby friends, etc. Most secure-MPC protocols are not designed for these settings Assume full connectivity, require broadcast, … Some existing work in these directions, but much work remains Boyle et al. TCC’13, Zamani et al. 2014, Boyle et al. 2014 Halevi et al. CRYPTO’11, Gordon et al. EC 2013

Semantic Leakage Crypto modeling captures formal leakage Whatever we need to leak to the simulator so that it can simulate But not “semantic” leakage What is actually given away by this leakage This is inherent to some extent Semantic leakage depends on application Same leakage can be harmless in one application, devastating in another

Semantic Leakage Identify useful patterns Composition? What: access-pattern, access-frequency, timing, … How much: Signal-to-noise ratio, … Identify cases where certain what/how-much combinations are acceptable and useful Composition? Connections to differential privacy?

Secure MPC with RAM Complexity When are ORAM-based protocols useful? Asymptotically faster than circuit-based ones But in practice, often much slower Combinations that perform well in practice ORAM for multiple clients Reduce interaction Faster Garbled RAM? Practical RAM-based MPC with little interaction?

SWHE-Based MPC Protocols FHE/SWHE perceived as slow Save on interaction, pay with more processing But low-degree SWHE is a handy tool for designing secure-computation protocols Contemporary SWHE provides: A few multiplications Ciphertext packing Variable plaintext space Parallelism Potential for practical efficiency Very little work so far exploiting it

Comparing MPC Technologies Several low-level technologies Binary (Yao, GMW) Algebraic black-box (using additive HE) SWHE-based protocols and ways of combining them MPC-in-the-head SPDZ MPC-over-ORAM, Garbled-ORAM How to decide what to use where?

Comparing MPC Technologies Develop a comparative corpus of data points Start from a few useful low-level tasks Comparison, Sorting, Regular expressions, … Parameterized by: number of parties, input size, security parameter, adversary model, … Organize a shoot-out, compare different implementations Time, bandwidth, rounds, trust model, … Also need fast methods of converting data between the different representations that are needed for the different technologies

Automation Automation, tool-support, is crucial for practical MPC protocols But our expectations should be modest In general, we cannot expect non-experts to design their own crypto protocols Even without crypto, work-flows design is typically left for domain experts Progress on tool-support for crypto proofs has been slow

Automation Tool support for implementation promises better bang-for-buck than for design Implementing secure-MPC is laborious APIs, development environments, languages, would help Example: integrating libraries is hard E.g., using HElib as a primitive inside SCAPI Without losing the low-level optimizations that HElib supports The HElib/SCAPI example, integration would require joint effort of crypto experts with languages experts, maybe develop crypto-specific design patterns

Automation A good development environment can be “scaled up” to support design, proofs Without limiting the developer Example: Use interface/implementation paradigm to specify security guarantees Put hooks for proofs Add tool support for proof-checking if/when it becomes available Use UC-security, relaxation thereof But allow opt-out of UC as needed

Summary Goal: bring secure-MPC to practice Useful directions Protocols for huge crowds Semantic leakage Computation with RAM complexity SWHE-based protocols Comparing MPC technologies Automation Start small, make extensible