SPAR-MPC Day 1 Breakout Sessions Emily Shen 29 May 2014

1. SPAR-MPC Day 1Breakout Sessions Emily Shen 29 May 2014

2. A High-Level SPAR-MPC Architecture End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

3. A High-Level SPAR-MPC Architecture End User What to compute, what to protect and prevent Implications Tool 1 Requirements • Some developer and cryptographer tasks may be automatable Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

4. User Input End User What to compute, what to protect and prevent Implications Tool 1 Requirements • User describes: • Who are the participants in the protocol? • What needs to be shared, and what needs to be kept private • Likely answers: • “I want X to remain secret” • “I will go 10x faster if you betray only a little information” • “Keep X secret from A; Y secret from B” • “I’m ok with you revealing a set of possible results but not a specific” • “I’m ok with revealing the size of the result” • “After a week, then the data can be leaked” Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

5. Motivating Use Cases End User What to compute, what to protect and prevent Implications Tool 1 Requirements • Queries on phone call metadata • Parties: caller, callees, phone company (storage), Gov’t (querier) • Permit: Query for all records up to two “hops” from suspect # • Protect suspect and result #s from phone company, other phone numbers from govt • Query for average income of students at a US school • Parties: students, schools, Dept. of Ed (storage), analyst (querier) • Permit: Aggregate statistical queries, e.g., average income of grads • Protect SSNs, individual salaries from analyst, Dept. of Ed Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

6. Motivating Use Cases End User What to compute, what to protect and prevent Implications Tool 1 Requirements • Outsourced computation in the cloud • Social benchmarking • Health care information sharing, monitoring • Mobile sensor data analysis Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

7. User Specification of Leakage End User What to compute, what to protect and prevent Implications Tool 1 Requirements • Obvious leakage measures (e.g., bits) are nearly impossible to ask a user • Hard for user to specify • Hard to understand semantic meaning • Leakage implications changes over time • e.g., genetic information • Leakage expressed as alternatives in trust and efficiency might be usable, enumerable • Two party, slower protocol • Trusted third party, faster protocol Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

8. Translation Between Application Requirements and Crypto Requirements • Four types of communication • User → Cryptographer: conveying security requirements • Cryptographer → cryptographer: describing a protocol • Cryptographer → developer: explaining what to implement • Cryptographer → end user: articulating privacy guarantees achieved • All of these communications are important • But, there can be an impedance mismatch at each one

9. User → Cryptographer Conveying security requirements • User challenges • Need list of options to choose from • Don’t understand requirements • Can’t convey them • Cryptographer challenges • Capturing reqs • Converting informal reqs into formal ones • Interdisciplinary problem • Legal/policy • NLP • Usability End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

10. Cryptographer → Cryptographer Describing a protocol’s security guarantees • Leakage inherently incomparable in general • Semantic vs. number of bits leaked • Depends on details of protocols • Leakage hierarchy for specific domains may be feasible • Access patterns to data structures • Non-interactive primitives: deterministic encryption, OPE, FE, … • Don’t want to rule out good ideas by restricting leakage language • Leakage driven by desired performance End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

11. Cryptographer → Cryptographer Describing a protocol’s security guarantees • Real / ideal model lets you specify leakage, but does not give ways to compare • Compare based on what must not leak instead • What can adversary learn from leakage? • Quantitative Information flow • Statistical inference • Caveat: No good lower bounds on learning • Differential privacy-style approach • What prior knowledge would adversary need to learn the specific sensitive data? End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

12. Cryptographer → Cryptographer Describing a protocol’s security guarantees • We should have examples for why a given leakage is bad • If can’t find an example, it might be okay (e.g., Tor) • Describe relative tradeoffs of leakage choices, not just absolute leakage • Value of proofs? • Challenging to absorb • Tedious to verify/understand • Statistical modeling can provide a measure of “goodness” for privacy End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

13. Cryptographer → Developer Explaining what to implement • Coders good at designing + implementing, need help with security • Standardized language from the crypto community would help developers know what to implement End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

14. Cryptographer → End User Articulating privacy guarantees achieved End User What to compute, what to protect and prevent Implications • Two security notions to convey at once • How data is hidden (example: encryption) • How an interactive protocol constantly protects privacy against attack (this is harder) • Public grasps security better than experts think • Must explain nuances of security tradeoffs • Balance: can’t show too much or too little • Must disabuse end user of notion that “computer knows sensitive data, just not showing it to me” Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

15. Cryptographer → End User Explaining real-world impact of leakage End User What to compute, what to protect and prevent Implications • Impact depends on application, users’ goals, attackers’ goals • Compare quality of adversary models through attacker impact • HBC/covert/local/access patterns/equality • Requires a system to be of interest to attackers • Needs to be done without allowing real privacy breaches • Arguing that leakage is not an attack is tricky: • Difficult to argue what can/cannot be learned from leakage • Sensitivity of information changes over time • Want research on “cryptanalysis” of privacy Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

16. Cryptographer → End User Understanding Leakage vs. Damage End User What to compute, what to protect and prevent Implications • Leakage: • Learnable information given transcript • Can be chained/combined with auxiliary information to gain additional leakage • Application/stakeholder independent • Damage • Information considered harmful • Damage can be compared with benefit of running application • Application/stakeholder dependent • Create database of known attacks/ways of combining leakage • Counter-balances toolchain of known MPC protocols • Using attack trees to chain together leakage • User knowledge needed to say what constitutes damage Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

17. Cryptographer → End User Understanding Leakage vs. Damage End User What to compute, what to protect and prevent Implications • Leakage and corresponding damage evolve over time • Complexity-based crypto is uncomfortable with patch/fix cycle • We think of privacy breaches as forever • Symmetric cryptography dealt with this cycle for years • Understanding and preventing known attacks • Current ciphers/hashes are believed to be quite strong Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

18. A High-Level SPAR-MPC Architecture End User What to compute, what to protect and prevent Implications Tool 1 Requirements Developer Cryptographer Leakage, adversary model Design Tool 2 Tradeoffs Implementations Proofs

19. Structure of MPC Tool • First, want a library of MPC tools, mechanism for choosing proper building blocks • Could we build a new library subsuming existing libraries? • Then, want a compiler that takes specification, selects proper protocols, produces implementations • General consensus –common API for all performers and tools will be challenging, though some interoperability may be encouraged • Program specification should be written in a language that is amenable to analysis, e.g., FairPlay

20. Layers of MPC Tools • Analogy: network stack model • Basic tools • Garbled Circuits • OT extensions • ORAM • Linear secret sharing • Common operations • Sorting • Comparisons • Higher Level Techniques • 2 PC vs. 3 PC • Preprocessing

21. Composability • Components should come with specifications of functionality and security • Need a composition framework • Especially for components with imperfect security • Might be worth considering more realistic adversary models • Given different situations, there are different applicable proofs • Limited composability may be possible • Not full interoperability