Tore Frederiksen Thomas Jakobsen Jesper Nielsen Peter Nordholt Claudio Orlandi 27082016 The LEGO Approach for Maliciously Secure TwoParty Computation 1 What we will present ID: 699384
Download Presentation The PPT/PDF document "MiniLEGO : Efficient Secure Two-Party Co..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
MiniLEGO:Efficient Secure Two-Party Computation From General Assumptions
Tore Frederiksen, Thomas Jakobsen, Jesper Nielsen, Peter Nordholt, Claudio Orlandi
27-08-2016
The LEGO Approach forMaliciously Secure Two-Party Computation
1Slide2
What we will present
A protocol for maliciously secure two-party computation based on cut-and-choose of Yao garbled circuits.
27-08-2016The LEGO Approach for
Maliciously Secure Two-Party Computation
2Slide3
OutlineIntroduction
What is the setting?Garbled circuitsWhy should we look at this?Preliminaries
Free XORXOR-
homomorphic commitments
The LEGO approachOverall idea
New problemsConclusion
Practical efficiency
Future work
27-08-2016
The LEGO Approach for
Maliciously Secure Two-Party Computation
3Slide4
What is the problem?
27-08-2016The LEGO Approach for
Maliciously Secure Two-Party Computation
Secure two-party computation
x
y
f
A
(x, y)
f
B
(x, y)
f(x, y)=(
f
A
(x, y),
f
B
(x, y))
4Slide5
Why is it worth solving?27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationSet intersection
Patients:
Alice Cooper
Cher
David Bowie
Gary Moore
Otep
Customers:
Alice Cooper
Chibi
La Roux
Madonna
5Slide6
How can it be solved?27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationSecure computation zoo
6Slide7
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
7Introduction
What
is the
setting?
Approach:
Yao’s garbled circuits
(Gate level) Cut-and-choose approach for malicious security
Using XOR-
homomorphic
commitment
UC secure
OT-hybrid securitySlide8
Yao’s garbled circuits are passively secure.Active security can be achieved with compilers [IPS08] or cut-and-choose [LP07, LP11, sS11, sS13, FN13, …].
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation8
Introduction
Passive to
active
securitySlide9
Introduction
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
Constructing a garbled circuit
9Slide10
Introduction27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationYao’s garbled circuit with passive security
10Slide11
Introduction27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationThe cut-and-choose approach to get malicious security
11
Commit
Challenge:
Challenge
OpenSlide12
IntroductionThe LEGO Approach for
Maliciously Secure Two-Party ComputationThe cut-and-choose approach to get active security
12
Challenge:
Open
27-08-2016Slide13
SimpleInformation theoretical securityFast (limited use of public key operations)
Asymptotic increase in complexity of O(s)27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
13
Introduction
The cut-and-choose approach to get active security
LEGO reduces the overhead to O(s/log(|C|)
Original LEGO [NO09] needs public key operations for each gateSlide14
Efficiency depends on many things:Rounds (amount of batches of messages)ComplexityConstants
Types of operations27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
14
Introduction
Comparison
to general cut-and-chooseSlide15
Outline
IntroductionWhat is the setting?Garbled circuitsWhy should we look at this?Preliminaries
Free XORXOR-homomorphic
commitments
The LEGO approachOverall ideaNew problems
ConclusionPractical efficiency
Future work
27-08-2016
The LEGO Approach for
Maliciously Secure Two-Party Computation
15Slide16
Free XOR27-08-2016
The LEGO Approach forMaliciously Secure Two-Party Computation
16
Each 0-key is chosen randomlyEach 1-key is the 0-key XOR’ed with a random value, common for the entire garbled circuit
1-keys for
i
and i+1:
0-output key for XOR gate:
1-output key for XOR gate:
Computing XOR gate:
Truth table:
[KS08]Slide17
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
17XOR-homomorphic commitments
M
1
M
2
Commit
Open
M
1
M
1
M
2Slide18
Outline
IntroductionWhat is the setting?Garbled circuitsWhy should we look at this?Preliminaries
Free XOR
XOR-homomorphic commitments
The LEGO approachOverall idea
New problemsConclusion
Practical efficiency
Future work
27-08-2016
The LEGO Approach for
Maliciously Secure Two-Party Computation
18Slide19
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
19The LEGO approach
The Overall idea
Commit
Cut-and-choose
OpenSlide20
27-08-2016
The LEGO Approach for
Maliciously Secure Two-Party Computation
20
The LEGO approach
Horizontal solderingSlide21
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
21The LEGO approach
Vertical solderingSlide22
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
22The LEGO approach
Vertical solderingSlide23
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
23The LEGO approach
Input solderingSlide24
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
24The LEGO approach
Input soldering
Send inputsSlide25
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
25The LEGO approach
Evaluation
Send output keysSlide26
Soldering:HorizontalVertical
Input27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
The LEGO approach
New problems
26Slide27
27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationThe LEGO approach
Horizontal soldering
27
headSlide28
27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationThe LEGO approach
Horizontal soldering
28
head
MajoritySlide29
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
The LEGO approachVertical soldering
29
Majority
Bucket jSlide30
27-08-2016
The LEGO Approach forMaliciously Secure Two-Party ComputationThe LEGO approach
Input soldering
30
head
OT
Horizontal solderingSlide31
Outline
IntroductionWhat is the setting?Garbled circuitsWhy should we look at this?Preliminaries
Free XORXOR-
homomorphic commitments
The LEGO approachOverall idea
New problemsConclusionPractical efficiency
Future work
27-08-2016
The LEGO Approach for
Maliciously Secure Two-Party Computation
31Slide32
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
ConclusionPractical efficiency
32
Better asymptotic complexities
Practical efficiency depends directly on XOR-
homomorphic commitmentsOr the size of the garbled circuit, because of asymptotic increase in efficiency
O(s/log(|C|)) replication factorSlide33
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
ConclusionPractical efficiency
33
In [NO09] Pedersen Commitments were used
3 public-key operations on each gate per party
In [FJNNO13] XOR-homomorphic commitments constructed from error correcting codes+OTBased on symmetric primitives when using OT extension, but codes leads to constants of around 40Slide34
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
ConclusionFuture work
34
The Aarhus Crypto-group is working on making cheaper XOR-
homomorphic
commitments and thus a more efficient LEGO protocol.Hopefully more efficient than normal cut-and-choose even for smaller circuitsSlide35
Conclusion27-08-2016
The LEGO Approach forMaliciously Secure Two-Party Computation
Thanks you!
Questions?
35
Free XOR
Symmetric
Asymmetric
Rounds
MiniLEGO
Yes
O(
s|C
|/log(|C|))
O(s)
O(1)
LEGO
No
O(
s|C
|/log(|C|))
O(
s|C
|/log(|C|))
O(1)
[LP11, sS11, sS13, L13, FN13,
…
]
Yes
O(
s|C
|)
O(
sn
)
O(1)
[NNOB12]
Yes
O(
s|C
|/log(|C|))O(s)O(d)
[DPSZ12]Yes
O(|C|)O(|C|)
O(d)
s is statistical security parameter, |C| is circuit size, d is circuit depth, n is input/output bitsSlide36
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
36
XOR-homomorphic commitments
The error correcting codeSlide37
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
37
XOR-
homomorphic
commitments
The protocol - SetupSlide38
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
38
XOR-homomorphic commitments
The protocol - SetupSlide39
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
39
XOR-homomorphic commitments
The error correcting codeSlide40
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
40
XOR-homomorphic commitments
The protocol - SetupSlide41
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
41
XOR-homomorphic commitments
The protocol - SetupSlide42
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
42
XOR-homomorphic commitments
The protocol - SetupSlide43
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
43
XOR-homomorphic commitments
The protocol – Committing and openingSlide44
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
44
XOR-homomorphic commitments
The protocol - SecuritySlide45
27-08-2016The LEGO Approach forMaliciously Secure Two-Party Computation
XOR-homomorphic commitmentsWhich code?
45
In [FJNNO13] we find a code that works due to Chen and Cramer based on algebraic geometry.
However, recent work shows that we can use a random matrix instead:
Binary linear by construction
Messages will be keys, so extra randomness not needed in our context
Secret sharing comes from randomness of the
codewords
Efficient decoding does not seem to be needed