Crash Course on Cryptography Jesper Buus Nielsen SSoRC 2008.
Secure Multiparty Computation Basic Technology + Past, Present, Future Jesper Buus Nielsen Associate...
-
Upload
horace-webster -
Category
Documents
-
view
214 -
download
0
Transcript of Secure Multiparty Computation Basic Technology + Past, Present, Future Jesper Buus Nielsen Associate...
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
1980s: Birth of a Research Field
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
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?
Garblinga=1 : Army A is readya=0 : Army A is not ready
b=1 : Army B is readyb=0 : Army B 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
• 1982 Garbled Circuits– Andrew Yao, “Protocols for Secure Computation”
• 1987-89 (Unconditional) 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
1980s: Birth of a Research Field
• 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
Multiparty Computation
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
Multiparty Computation
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
• 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
1980s: Birth of a Research Field
• 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
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
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
What is Possible?(ignore efficiency)
• 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• …• ...
What is Possible?(ignore efficiency)
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
• 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
So it is possible but
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
So it is possible but
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
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
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