1. Vladimir Kolesnikov (Bell Labs) Tal Malkin (Columbia U), Payman Mohassel (U Calgary), Mike Rosulek (Oregon State), Yehuda Lindell (Bar-Ilan U) Kedar Namjoshi, Alan Jeffrey, Steve Fortune (Bell Labs) Challenges and directions for optimizing the automated solution of the general MPC problem

2. 2 Problem description Protocol composition for performance improvement Leakage for insane performance improvement ­But what guarantees do we have? Research directions in cryptography, compilers and program analysis Heilmeier’s Catechism Outline

3. 3 One button to generate the best protocol High-level language? Program may specify (partial list) ­Number of players ­Trust assumptions ­Communication channel assumptions ­Player computational abilities ­Leakage allowance ­Automatically or manually select: ­The “right” subroutine ­E.g. Array implementation via GC or ORAM General MPC

4. 4 Crypto primitives for variety of general and special cases ­GC, Info-theoretic GC, GMW, ­ORAM, ORAM-based MPC ­Server-aided computation ­OBDD, FSA ­Homomorpic ­… Each is best in some setting (Automatic) Subroutine Selection & Protocol composition

5. 5 Crypto primitives for variety of special cases Idea: compose (automatically or manually) the “right” subroutines. ­Few first attempts ­[KSS13] (GC + homomorphic, manual), TASTY [HSSW10] ­[LHSHK14] (GC+ORAM, compiler), “order of magnitude” improvement GC can serve as secure “glue” for many compositions ­In the semi-honest model. Much harder in malicious model. Systematize the approaches Amend/design protocols to enable easy composition (Automatic) Subroutine Selection & Protocol composition (cont.)

6. 6 Much of the cost of MPC comes from “the last mile” ­Selective abort allows to learn one bit at the cost of being caught ­Cost: complex Cut-and-choose with s^2 commitments ­Dual execution [MF06] leaks one bit at the cost of being caught ­Cost: 20x performance overhead via [Lin13] ­Leaking execution path in large-input computation (e.g. [PKVKMCGKB14]) ­Cost: insane (vs GC), orders of magnitude (vs ORAM-MPC) In deadline-driven applications, the choice is between ­no privacy / imperfect privacy ­Imperfect privacy can be more dangerous if not clearly understood Leakage

7. 7 ­Research in improving standalone protocols, with a view of composition ­General ­Specific functions ­Implementations ­Profiling frequently-used primitives a-la OT Extension[ALSZ13] ­Specific to settings (high/low power devices, battery considerations, etc.) Research directions – MPC improvements & Benchmarking

8. 8 Systematize the many approaches Amend/design protocols to enable easy composition at compile-time Malicious model composition Compiler work to automate primitive selection and gluing Research directions – Composition

9. 9 Design faster and less-leaking protocols ­Improve bounds and guarantees on ­Covert protocols ­Dual execution protocols ­Other Research directions – Leakage

10. 10 Needed even in “proper” non-leaky protocols ­Multiple execution leaks a complex object that is often hard to understand ­E.g. What is learned from a sequence of DB queries ­If running time is also revealed Design concepts, language, and tools for leakage analysis New leaky definitions Research directions – Understanding (Composed) Leakage

11. 11 Consider a high-level program which calls subroutines (e.g. DB queries) Use automated program analysis and verification techniques: ­Trace possible/probable program states and subroutine call sequences ­Bound the knowledge gained from leakage, malicious gains and legal outputs ­Answer questions of the type “Is information x leaked?” Research directions – Understanding (Composed) Leakage

12. 12 What are you trying to do? ­Understandable security for deadline-oriented applications How is it done today, and what are the limits of current practice? ­Not done* What's new in your approach and why do you think it will be successful? ­Combination of crypto, compilers, and automated leakage analysis Who cares? ­Agencies who may not share their data; industry if it’s simple and fast enough If you're successful, what difference will it make? ­More PII privacy, ability to securely share data, technological enforcement of data laws. Heilmeier’s Catechism (1)

13. 13 What are the risks and the payoffs? ­MPC improvements are low- to medium- risk, depending on expectation ­Leakage analysis is high-risk as a new field ­Pay off – up to eliminating overhead of MPC (with leakage, in ideal world, in some settings) How much will it cost? ­7-10 people working ½ time How long will it take? ­3-4 years to see noticeable results Heilmeier’s Catechism (2)

14. 14 What are the midterm and final "exams" to check for success? ­Foundations (1.5 yrs) ­MPC crypto work in systematization etc. ­Design of leakage specification language and analysis tools ­Demo Implementation of (1.5 yrs) ­Improve foundations and deliver an implementation ­Deliverable ­A push-button system Heilmeier’s Catechism (3)

15. 15 [ALSZ13] Gilad Asharov, Yehuda Lindell, Thomas Schneider, Michael Zohner. More efficient oblivious transfer and extensions for faster secure computation. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. [HSSW10] Wilko Henecka, Ahmad-Reza Sadeghi, Thomas Schneider, Immo Wehrenberg. TASTY: tool for automating secure two-party computations. CCS 2010 [KSS13] Vladimir Kolesnikov, Ahmad-Reza Sadeghi, Thomas Schneider: A systematic approach to practically efficient general two-party secure function evaluation protocols and their modular design. Journal of Computer Security 21(2): 283-315 (2013) [LHSHK14] Chang Liu, Yan Huang, Elaine Shi, Michael Hicks, and Jonathan Katz. Automating Efficient RAM-Model Secure Computation. In S&P (Oakland) 2014 [MF06] Payman Mohassel, Matthew K. Franklin: Efficiency Tradeoffs for Malicious Two- Party Computation. In PKC 2006 [Lin13] Yehuda Lindell: Fast Cut-and-Choose Based Protocols for Malicious and Covert Adversaries. CRYPTO (2) 2013 [PKVKMCGKB14] Vasilis Pappas, Fernando Krell, Binh Vo, Vladimir Kolesnikov, Tal Malkin, Seung Geol Choi, Wesley George, Angelos Keromytis, Steve Bellovin. Blind Seer: A Scalable Private DBMS. In Oakland 2014. Bibliography