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

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

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

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
Boyle et al. TCC’13, Zamani et al. 2014, Boyle et al. 2014
Halevi et al. CRYPTO’11, Gordon et al. EC 2013

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

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, …
Also need fast methods of converting data between the different representations that are needed for the different technologies

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
The HElib/SCAPI example, integration would require joint effort of crypto experts with languages experts, maybe develop crypto-specific design patterns

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