Secure Multiparty Computation Basic Technology + Past, Present, Future Jesper Buus Nielsen Associate Professor Aarhus University Send comments and input

Secure Multiparty Computation

Basic Technology+

Past, Present, Future

Jesper Buus NielsenAssociate ProfessorAarhus University

Send comments and input to: [email protected]

Agenda

• A Brief History of MPC– Including basic techniques and

methodologies• Grand Challenges• Methodologies for the Future

A Brief History of MPC

• 1980s: Birth of a Research Field

• 1990s: Basic Feasibility Questions

• 2000s: Asymptotic Complexity

• 2010s: Towards Practice• The Next Frontier:

Practical Scalability

The Dark Ages(Before 1982)

• Cryptography concerned with protecting:– Data in transport– Data at rest

• Example: Encryption– A secret key: K– A plaintext: M– A ciphertext: C = EK(M) – The ciphertext does not reveal any information about the

plaintext if you do not know the key

• 1982, Andrew Yao: “Protocols for Secure Computation”

1980s: Birth of a Research Field

Whatever two parties can compute together, they can also compute

together in such a way that none of them learn more than the desired

outputTuring

Award

• 1982 Garbled Circuits– Andrew Yao, “Protocols for Secure Computation”

• 1987-89 (Unconditionally) Multiparty Computation– Goldreich, Micali, Wigderson– Chaum, Crépeau, Damgård– Ben-Or, Goldwasser, Wigderson– Rabin, Ben-OR

• 1988 Founding Cryptography on Oblivious Transfer– Joe Kilian


Are we Ready?a=1 : Army A is readya=0 : Army A is not ready

b=1 : Army B is readyb=0 : Army B is not ready

r = a✕br=1 : Both are readyr=0 : One or both not ready

r=0 r=0

a?

Are we Ready?a=1 : Army A is readya=0 : Army A is not ready


r = a✕br=1 : Both are readyr=0 : One or both not ready

r=0 r=0

a?

Garblinga=1 : Army A is readya=0 : Army A is not ready


r=0 r=0

C11,C01,C00,C10

A1 B0

C11,C01,C00, 0

A0 A1

B0 B1

C00=EA0(EB0(0))C01=EA0(EB1(0))C10=EA1(EB0(0))C11=EA1(EB1(1)) a?Oblivious

Transfer


• 1987-89 (Unconditional) Multiparty Computation– Goldreich, Micali, Wigderson– Chaum, Crépeau, Damgård– Ben-Or, Goldwasser, Wigderson– Rabin, Ben-OR



• Now there are any n parties• Each has its own private input• They compute a function of all inputs, for instance, Are we

all ready?• The protocol can tolerate that any minority of the parties

collude, pool their view of the protocol run and even deviate from the protocol and still guarantee:– Correctness: The output is correct– Privacy: The colluding parties learn no information extra to the

output– Termination: The corrupted parties cannot prevent the

computation from completing

Multiparty Computation

• We have a secret M to share between two parties P1 and P2

• Assume that M=0 or M=1 • Pick a random integer S2 between 0 to

1,000,000,000,000• Let S1 = M-S2

• Give S1 to P1 and give S2 to P2

• No party gets information on M• Together they can compute M = S1 + S2

Secret SharingS1 S2

• Given a ciphertext C=EK(M) one can in principle always find M– Exhaustive search for K– Insecurity of E?

• From any secret share no information can be deduced about the secret even with unlimited computing power– There is no information present at any individual party– According to the laws of physics

Secret Sharingvs.

Encryption

S1 S2

• We have a secret M to share between three parties P1, P2, P3

• Assume that M=0 or M=1 • Pick a random integers S2 and S3 between 0 to

1,000,000,000,000• Let S3 = M-S1-S2

• Give Si to Pi • No two parties get information on M even if they pool their

shares• Together they can compute M = S1 + S2 + S3

S1

Secret Sharing

S3

S2


a1

a2

a3

ab

a = a1 + a2 + a3

a2

a3

b1

b2

b3

b = b1 + b2 + b3

a+b = (a1+b1) + (a2+b2) + (a3+b3)

c3=a3+b3

a+b = c1 + c2 + c3

c = c1 + c2 + c3

c1=a1+b1

c2=a2+b2

a+b = c


a1

a = a1 + a2 + a3

a2

a3

b1

b2

b3

b = b1 + b2 + b3

ab = a1b1 + a1b2 + a1b3 + a2b1 + a2b2 + a2b3 + a3b1 + a3b2 + a3b3

c = c1 + c2 + c3

a1b1

a2b2

a3b3

a1

a1b2

a2

a3

b1

b2

b3


• 1987-89 (Unconditionally) Multiparty Computation– Goldreich, Micali, Wigderson– Chaum, Crépeau, Damgård– Ben-Or, Goldwasser, Wigderson– Rabin, Ben-OR



• Garbling and OT-Based MPC – Can tolerate 1 corrupted party out of 2– In general n-1 corruptions out of n– Only computational security

• Unconditional Multiparty Computation– Can only tolerate 1 out of 3 corrupted parties– In general any <n/2 corruptions out of n– Has unconditional security– Generally faster

Multiparty Computationvs.

Garbled Circuits and OT-Based MPC

S1 S2


• 1980s: Birth of a research field



• 2010s: Towards Practice

• The Next Frontier:


What is Possible?(ignore efficiency)

• Now followed a period of investigating basic feasibility results:

• Which functions can in principle be computed securely in a given context?

• Which functions:– All versus low depth

• How securely:– Correctness, Privacy, Termination, Fairness, …– n-1 , n/2, n/3, … corruptions out of n

• General adversary structures, asymmetric trust, …

– Computational versus unconditional security– Mobile versus stationary adversaries– Active versus adaptive corruptions– Malicious security, fail-stop security, semi-honest security

• Given context:– Synchronous versus asynchronous communication– Secure channels versus open channels– Stand-alone versus concurrent composition– Complete network versus sparse networks


• The main structures of feasibility is by today fairly well understood

• Many important open problems:• Cryptographic Program Obfuscation??? • Constant-round unconditional MPC• Non-interactive client-server computation• Individual privacy preserving data mining• …• ...









• At some point the main quest became asymptotic complexity analysis

• Define: C(s, n) = Number of bits you need to communicate to securely evaluate a function f of size s among n parties tolerating t<n/3 active corruptions using the best possible protocol

• Task: Compute the function C(s, n)

So it is possible but

What does it Cost?

• Don’t compute C(n) exactly, just find out the general behaviour

• Is it like C(n)=2n or C(n)=n2 or C(n)=2n

• Ignore all constants• Upper bounds: Give a better protocol• Lower bounds: Prove that no better protocol

exists


What does it Cost?

• Methodology from algorithmics• Rational: 1000000 n >> 1000 n2 >> 2n

– Constants do not matter because linear will always eventually beat polynomial will always eventually beat exponential when the input size grows

– Constants will be eaten by Moore’s law– Ignoring irrelevant details facilitate thinking freely out of the

box • Has been tremendously successful in coming up with

fundamentally new techniques which also fly in practice

What is the Asymptotic Methodology About?

n=10 n=100 n=1000

2n 20 200 2000

n2 100 10,000 1,000,000

2n ~1000 ~1,000,000,000,000,000,000,000,000,000,000

INFINITY

• Example line of work: – by the speaker a co-authors Ivan Damgård, Martin Hirt, Yuval

Ishai, Mikkel Krøigaard, Adam Smith

• C(s, n): size(f)=s, n parties, t<n/3 corruptions, bits communicated

• 2001: s✕n3 • 2005: s✕n2 • 2006: s✕n • 2008: s


What does it Cost?

Along the way we developed many new tools and tricks

being used in todays practical protocols!

• Big constant do not always amortize away • In algorithmics input size does seem to keep

growing but• Some important parameters in MPC do not seem

to grow fast enough to justify asymptotics:– Security parameter k: • Do we ever want 1000-bit statistical security?

– Number of parties n: • Will we ever run MPC between a 1000 servers• Often a fixed number of parties is given by the constant

Problems with the Asymptotic Methodology in MPC

• Data and systems will always grow to exhaust the available resources– Large constants will not eventually be swallowed by

advances in technology– Even a factor 100 overhead makes general secure

encryption impractical• Example study: >10% overhead and users turn off

security• Constants matter!

Problems with the Asymptotic Methodology in MPC

• C(f, n): size(f)=s, n parties, t<n/3 corruptions, bits communicated

• Educated guesses at order of magnitudes: • 2001: 100 × s × n3

• 2005: 104 × s × n2

• 2006: 106 × s × n• 2008: 108 × s

What does it really Cost?

• Another example for: Two parties + malicious security• Security parameter k: Size of encryption keys• Security parameter b: Bad stuff can happen with

probability 2-b

• In theory we know how to do: size(f) k• In practice the best protocols are:• Practice:

– Forge-and-Loose Garbling: size(f) k s• Lindell

– TinyOT: size(f) k s / log(size(f))• Speaker, Nordholt, Orlandi, Burra

Asymptotics vs. Practice

• Many important open questions:– Constant overhead with n-1 corruptions? – Constant overhead with any constant honesty?– Oblivious Transfer extension with constant

overhead for bit-OT?– Lower bounds!!

• What is not possible?

– Better measures• Will keep producing many fundamentally new

techniques which also fly in practice

Future of Asymptotics








Are we Ready?

• 2004 Fairplay– Malkhi, Nisan, Pinkas, Sella– First prototype implementation of Yao Garbling– Two parties, semi-honest security

• 2008 FairplayMultiParty– As above + multiple parties– Ben-David, Nisan, Pinkas

• 2008 Not Named!– Lindell, Pinkas, Smart– Prototype implementation of Yao Garbling– Two parties, active security

• 2008 ShareMind• Ran on toy examples, but we now had actual running prototypes!

2009: We are Ready!

• “Secure Two-Party Computation is Practical”– Garbling, two parties, malicious security, moderately complicated

functions, “fast”– Pinkas, Schneider, Smart, Williams

• The VIFF Framework– Framework in Python for programming multiparty computation with

malicious security– Speaker, Damgård, Geisler, Krøigaard

• The Commodity Contract Auction– Report on implementation of three-party MPC solution used to

clear the Danish market for contracts on an agricultural commodity market

– First commercial application of MPC– The speaker and eleven collaborators

2009: We are Ready!

• And implementations for special domains:

• Medical Applications– Barni, Failla, Kolesnikov, Lazzeretti, Paus, Sadeghi,

Schneider, Kolesnikov • Face Recognition– Sadeghi, Schneider, Wehrenberg

2010s: The Practical Explosion

• 2010: TASTY– Compiler, Garbling, Homomorphic Encryption– Henecka, Kögl, Sadeghi, Schneider, Wehrenberg

• 2011: Sharemind used for Financial Data Analysis– Three parties, semi-honest, MPC– Bogdanov, Talviste, Willemson

• 2011: MightBeEvil– Framework, Garbling, Two parties, Malicious– Huang, Evans, Katz, Malka

• 2012: TinyOT– OT-based, two parties, malicious security, gigasized functions– Speaker, Nordholt, Orlandi, Burra

• By 2012 all the main pillars (Garbling, Unconditional MPC, OT-Based MPC and Homomorphic encryption) had been implemented in practice and there are now innumerable prototypes and frameworks out there

First Spin Offs

• 2008 Partisia (Market Design)– Still runs the MPC solution for clearing contracts on the commodity market– Speaker and 11 other co-funders

• 2008 Sharemind– A three-party, semi-honest secure MPC solution of privacy-preserving data

mining– Splitting up sensitive data on three servers using secret sharing and compute

with MPC– Cybernetica

• 2015 Dyadic Security– Splitting sensitive data using MPC to for instance protect against server breaches– Yehuda Lindell, Nigel Smart

• 2015 Sepior– Uses MPC to implement SaaS solution for key management in the cloud – Speaker and finite set of other co-founders

• ...

State of Practice

• Either small data– E.g. Partisia Market, Dyadic

• or small number of parties– E.g. Partisia Market, Dyadic, Sharemind

• or simple, special case function– E.g. Partisia Market, Sepior, Dyadic

• or only semi-honest security– E.g. Partisia Market, Sharemind

Grand Challenge:Practical Scalability

• Big Data– Petabyte data with 1-out-of-3 active security and a moderately complex general

function?• Complex Functions

– How do we evalute a terasized function (two parties, active security say)? • Many Parties

– We have good solutions for two and three parties, but what about 10, 20, 30? • Many Technologies and Models

– Data encrypted at collection time and stays encrypted throughout the life-time of the data / system

– Move between best technologies for the given sub-problem– Should integrate also with existing technology with different trust models and

possibly lower security

Grand Challenge:Practical Scalability

• The scalability problems we face mean that we do not just have to improve running time by a small or medium factor by better implementation/engineering of existing techniques– We need many orders of magnitude!

• We need to develop fundamentally new techniques

• This means: More fundamental research

Grand Challenge:Tradeoffs

• Understand and exploit tradeoffs – For instance by leaking some non-sensitive data, can

we handle bigger data, functions, …– Can we automatically identify non-sensitive data– Can we make tools that help us reason about sensitive

versus non-sensitive– Other trade offs...

Grand Challenge:Compiler and

Friends

• High-Level Language and Compiler Support– We are decades behind general purpose compilers

• Static Analysis to Support Development– Understanding security of a COED program– Optimization, Map parts to right technology, What is not sensitive, …

• Linker– Diverse tools– Diverse technologies– Diverse trust models– What are the right interfaces between modules?– Models and tools for reasoning at a module level

A Methodology for the Future

Prototype-SteeredFundamental Research

• Feasibility and asymptotic analysis have been tremendously successful– Has produced many fundamentally new techniques that also fly in practice – Can inspire practical techniques– If not guided it often runs into the woods to never be seen again

• Use prototyping to mitigate the cons – Does not mean every new idea must be demoed, but having

demoability of the best ideas as a goal keeps a healthy direction – Product development cannot act as the same guiding principle

• Focus on too low level details or completely irrelevant details• Details re market readiness and good system development are very important in other

contexts, but a straight jacket for producing fundamentally new techniques

• Prototyping helps develop better measures for theory

• Let us take some of the things we have been prototyping and turn them into actual products with industrial partners– Even better: Go make some companies!

• Feedback to fundamental research line:– If we can do this, why can’t we then do that?– Realize which bottlenecks matter in practice– Find practical but restricted problem settings

Another Methodology for the Future

Industry-Driven Problem Formulation

Oh, I Forgot:Models

• All our current security models have one or more of the following two properties:

• Proving security in the model does guarantee that the protocol is secure in real-life!!– In particular if the protocol is adversarially

chosen• Natural protocols which we think are secure

cannot be proven secure in the model!?• Someone should do something about that,

but not really a COED problem

Future of MPC• All stages in the supply line are still active

and important– Birth– Basic Feasibility Questions– Asymptotic Complexity– Prototyping– Scalability in Practice

• Areas in Biggest Need of a Boost:– Practical Scalability– Compiler and Language Support

• Methodologies for the Future:– Prototype-Steered Asymptotic Analysis– Industry-Driven Problem Formulation

Documents

Secure Multiparty Computation Basic Technology + Past, Present, Future Jesper Buus Nielsen Associate Professor Aarhus University Send comments and input