Challenges and directions for optimizing the automated solution of the general MPC problem

1. Challenges and directions for optimizing the automated solution of the general MPC problem 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)

2. Outline • 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

3. General MPC • 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

4. (Automatic) Subroutine Selection & Protocol composition • 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

5. (Automatic) Subroutine Selection & Protocol composition (cont.) • 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

6. Leakage • 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

7. Research directions – MPC improvements & Benchmarking • 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.)

8. Research directions – Composition • 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

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

10. Research directions – Understanding (Composed) Leakage • 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

11. Research directions – Understanding (Composed) Leakage • 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?”

12. Heilmeier’sCatechism (1) • 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.

13. Heilmeier’sCatechism (2) • 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

14. Heilmeier’s Catechism (3) • 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

15. Bibliography [ALSZ13] GiladAsharov, 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, ImmoWehrenberg. 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.