1 / 14

Making Secure Computation Practical

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.

cwen
Download Presentation

Making Secure Computation Practical

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Time for Secure Computation • The time has come for secure-MPCto 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

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

  4. 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

  5. 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

  6. Semantic Leakage • Identify useful patterns 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?

  7. 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?

  8. 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

  9. 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?

  10. 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, …

  11. 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

  12. 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

  13. 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

  14. 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

More Related