Secure Multi-Party
Computation on Integers
Master’s Thesis
Strange L. From
Thomas Jakobsen
Advisor: Ivan Damgård
April 1, 2006
D EPARTMENT OF C OMPUTER S CIENCE
U NIVERSITY OF A ARHUS
Resumé
Begrebet secure multi-party computation dækker over teknikker, som tillader
forskellige parter forbundet via et netværk at udføre beregninger på data
fra alle parter og som samtidig sikrer, at de data, som den enkelte part
kender, ikke afsløres under beregningen.
I dette speciale gennemgås en række af disse teknikker særligt designet
til at udføre sikre beregninger på heltal. Det indebærer kendte protokoller
for sikker addition og multiplikation samt en protokol for sammenligning
af heltal udviklet i SCET-projektet [7]. Vi beskriver desuden vores egen
protokol for heltalsdivision, som er baseret på teknikkerne fra SCET samt
en protokol udviklet af Algesheimer, Camenish og Shoup [1] for beregning af en approksimation til den reciprokke værdi 1/b for et heltal b. Protokollerne bygger på forskellige former for secret sharing samt teknikker for
pseudo-random secret sharing som stammer fra Cramer, Damgård og Ishai
[13]. Protokollerne vises sikre i en model med passiv og statisk adversary
samt honest majority.
Protokollerne suppleres med eksperimenter baseret på en implementering af en prototype. Eksperimenterne viser, at protokollerne er tilstrækkeligt effektive til i hvert fald visse praktiske formål. I den sidste del af specialet kommer vi kort ind på, hvilke praktiske formål det kunne være.
Abstract
Secure multi-party computation is concerned with techniques that allow
multiple parties on a network to jointly carry out computations that depend
on data from each of the parties while the data held by each party remains
private to that party.
This thesis contains a survey of various techniques for secure multiparty computation on integers. This includes known protocols for secure
addition and multiplication as well as a protocol for comparing integers developed in the SCET research project [7]. Also, we present our own protocols for integer division based on the techniques from SCET and a protocol
by Algesheimer, Camenish, and Shoup [1] for computing an approximation
of the reciprocal 1/b of an integer b. The protocols are based on various secret sharing schemes and the notion of pseudo-random secret sharing developed by Cramer, Damgård, and Ishai [13], and they are proved secure
in a passive and static adversary model with honest majority.
The protocols are accompanied by performance benchmarks based on
a prototype implementation showing that they are efficient enough for at
least some practical purposes. The last part of our thesis briefly discusses
some applications of secure multi-party computation on integers.
Contents
Resumé
iii
Abstract
v
Contents
vii
1
Introduction
1.1 Focus of this Thesis . . . . . .
1.2 Results . . . . . . . . . . . . .
1.3 Overview . . . . . . . . . . . .
1.4 Contributions . . . . . . . . .
1.5 Requirements and Notation .
1.5.1 A Note on Complexity
1.6 Responsibilities . . . . . . . .
1.7 Acknowledgments . . . . . .
.
.
.
.
.
.
.
.
1
1
2
3
3
4
4
5
6
2
Secure Multi-Party Computation
2.1 Introduction . . . . . . . . . . . . . . . . . .
2.2 The Model of Security . . . . . . . . . . . .
2.2.1 A Definitional Approach to Security
2.2.2 Modular Composition of Protocols .
2.2.3 Extending the Security Model . . . .
2.2.4 General Results . . . . . . . . . . . .
2.3 Secret Sharing . . . . . . . . . . . . . . . . .
2.3.1 Shamir’s Scheme . . . . . . . . . . .
2.3.2 Additive Sharing Schemes . . . . . .
2.4 Homomorphic Threshold Encryption . . .
2.5 Pseudo-Random Secret Sharing . . . . . . .
2.5.1 Protocols Based on PRSS . . . . . . .
2.5.2 Binary Sharings . . . . . . . . . . . .
2.5.3 Security . . . . . . . . . . . . . . . .
2.6 Summary . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
8
13
14
16
16
17
18
19
20
22
24
24
27
3
Basic Protocols
3.1 Sharing Elements . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
viii
3.2
3.3
3.4
3.5
3.6
Contents
3.1.1 Polynomial Sharing . . . . . . . . . . . . . . . .
3.1.2 Additive Sharing . . . . . . . . . . . . . . . . .
3.1.3 Joint Random Polynomial Sharing . . . . . . .
Arithmetic Computation . . . . . . . . . . . . . . . . .
3.2.1 Addition . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Multiplication . . . . . . . . . . . . . . . . . . .
3.2.3 Integer Arithmetics . . . . . . . . . . . . . . . .
Conversion of Sharing Schemes . . . . . . . . . . . . .
3.3.1 Converting Polynomial and Additive Sharings
3.3.2 Converting Additive Sharings over Z and Z p
Concurrent Basic Protocols . . . . . . . . . . . . . . . .
Complexity . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Rounds and Communication . . . . . . . . . .
3.5.2 Computational Complexity . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
31
31
31
33
34
35
35
36
37
37
37
38
4
Bit Representation
4.1 Logical Bit Operations . . . . . . . . . . . .
4.1.1 Bits as Elements in Z p . . . . . . . .
4.1.2 Bits as Elements in GF(28 ) . . . . . .
4.1.3 Complexity . . . . . . . . . . . . . .
4.2 A Generic Approach to Bit Representation .
4.3 Basic Binary Protocols . . . . . . . . . . . .
4.3.1 Generating Random Bits . . . . . . .
4.3.2 Xoring Multiple Bits . . . . . . . . .
4.3.3 Converting Bits . . . . . . . . . . . .
4.3.4 Security . . . . . . . . . . . . . . . .
4.3.5 Complexity . . . . . . . . . . . . . .
4.4 Summary . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
40
41
41
42
42
43
43
44
45
46
5
Binary Addition
5.1 Ripple-Carry Addition . . . . . . . . . . . . .
5.2 Addition Using Parallel Prefix Computation
5.2.1 Computing a Single Bit in a Sum . . .
5.2.2 Parallel Prefix Computation . . . . . .
5.3 Security . . . . . . . . . . . . . . . . . . . . . .
5.4 Summary . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
48
49
50
52
52
6
Splitting an Integer Into Bits
6.1 A First Approach (I2QBIT) . . . . . .
6.1.1 Parallelizing the Protocol . .
6.1.2 Security . . . . . . . . . . . .
6.2 An Alternative Approach (P2QBIT) .
6.2.1 Preprocessing . . . . . . . . .
.
.
.
.
.
55
55
56
57
58
58
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
60
61
62
62
7
Integer Computation
7.1 Extracting a Bit from an Integer . . . . . . . . . . .
7.2 Comparison . . . . . . . . . . . . . . . . . . . . . .
7.3 Shifting . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Exact Shifting . . . . . . . . . . . . . . . . .
7.3.2 Approximate Shifting . . . . . . . . . . . .
7.3.3 Shifting Up Integers Into a Certain Interval
7.3.4 Complexity . . . . . . . . . . . . . . . . . .
7.4 A First Approach Towards Division . . . . . . . .
7.4.1 Binary Search . . . . . . . . . . . . . . . . .
7.4.2 Division Based on Binary Search . . . . . .
7.5 Efficient Division . . . . . . . . . . . . . . . . . . .
7.5.1 Newton Iteration . . . . . . . . . . . . . . .
7.5.2 Computing an Approximation of 1/b . . .
7.5.3 The Division Protocol . . . . . . . . . . . .
7.5.4 Public Divisor . . . . . . . . . . . . . . . . .
7.6 Modular Reduction . . . . . . . . . . . . . . . . . .
7.6.1 Protocols Based on Modular Reduction . .
7.7 PRSS and Computational Security . . . . . . . . .
7.8 Summary . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
66
66
66
67
68
69
70
70
72
78
79
80
85
90
91
92
92
96
8
Implementation
8.1 Implementing SMPC . . . . . .
8.1.1 The SCET Framework .
8.1.2 Benchmarking Protocols
8.2 Performance Results . . . . . .
8.2.1 Basic Protocols . . . . .
8.2.2 Binary Addition . . . . .
8.2.3 Splitting Bits . . . . . . .
8.2.4 Integer Protocols . . . .
8.3 Summary . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
97
97
100
101
102
104
105
106
111
9
Concluding Remarks
9.1 Process Overview . . .
9.2 Future Work . . . . . .
9.3 Applications . . . . . .
9.3.1 Secure Auctions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
113
114
115
115
6.3
6.4
6.2.2 Reduction . . . . . .
6.2.3 Addition . . . . . . .
6.2.4 Security . . . . . . .
6.2.5 Complexity . . . . .
A Constant Round Solution
Summary . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
x
Contents
9.3.2
9.3.3
Privacy-Preserving Distributed Datamining . . . . . 116
Games . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
A Further Experimental Results
119
B The Code
123
B.1 Field Arithmetics . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.2 A Simple Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 124
B.3 Prefix Addition . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Bibliography
133
Chapter 1
Introduction
The age of communication and in particular the invention of the Internet has resulted in increased needs for controlling information. During
the years, several techniques originating from mathematics and cryptology
have found their usage as means to prevent crime while still maintaining
the potential of the new technologies. Our thesis is concerned with one
such technique called Secure Multi-Party Computation. Suppose, that several parties connected by a network each holds some private information.
Secure Multi-Party Computation makes it possible for the parties to jointly
carry out computations that depend on all this information while the information held by a specific party remains private to that party.
The first articles on this topic were published by Yao [39] and Goldreich
et al [19]. They proved that it indeed is possible for a collection of parties
to carry out such computations. Later, in 1988, important improvements
to these general results were made independently by Ben-Or, Goldwasser,
and Widgerson [6] as well as Chaum, Crépeau, and Damgård [11]. They
proved that it is possible to achieve a stronger notion of security in a scenario where secure channels between the parties are assumed.
Secure Multi-Party Computation (SMPC) has many applications, for instance electronic voting, privacy-preserving distributed datamining, and
secure auctions to name a few, but the techniques of [6, 11] are generally
regarded as being too inefficient for most practical purposes. Several refinements have been developed since then. These are aimed at improving
efficiency for certain specific problems and thereby increase the practical
applicability.
1.1 Focus of this Thesis
The SCET (Secure Computation, Economy, and Trust) research project [7]
accounts for one such refinement. The goal of this project is to combine
research in the area of SMPC with knowledge from economics in order to
2
Introduction
Chapter 1
pave the way for concrete solutions. This has recently resulted in prototype
implementations for certain real-life scenarios involving concrete companies. More specifically, the part of the SCET research that is related to SMPC
has focused on development and implementation of efficient protocols for
secure computation on integers. Known techniques for secure representation and protocols for addition and multiplication of integers have been
implemented and a new efficient protocol for comparison of integers has
been developed.
This thesis documents the SMPC techniques from SCET, including integer comparison, as well as our own development and implementation of
additional protocols for secure division of integers. The division protocols
build on the integer comparison from SCET and a protocol developed by
Algesheimer, Camenish, and Shoup [1] which is basically an SMPC version
of Newton-Raphson iteration for approximating the roots of a function. In
order to reach as efficient protocols as possible, we analyze, implement,
benchmark, and compare several alternative strategies.
Put together, this thesis thus documents a collection of SMPC protocols for secure computation on integers, including addition, multiplication,
comparison, and division. The main effort, though, has been put on developing, analyzing, implementing, and benchmarking efficient and secure
protocols for division.
1.2 Results
We have succeeded in developing secure protocols for division. Table 1.1
lists some average execution times obtained from our benchmarks for various integer sizes and number of parties. These and other benchmarks are
further described in chapter 8. The execution time is split into preprocessinteger
bit size
8
16
32
64
3 parties
pre proc
5 parties
pre proc
0.83
1.23
2.29
5.07
1.12
1.98
3.63
8.90
4.84
5.90
7.16
9.06
5.87
7.26
9.15
12.28
7 parties
pre proc
3.46
6.05
11.94
28.43
8.68
10.95
14.77
21.74
Table 1.1: Average execution time for integer division (seconds).
ing (pre) and processing (proc). The preprocessing consists of computation
which is independent of the integers to divide and which can therefore be
carried out in advance. By processing we mean the part of the computation
that depends on the input integers. Whether our division protocols are effi-
Section 1.4
Overview
3
cient enough for practical usage of course depends on which kind of usage.
In some applications only a few comparisons or divisions are needed. The
timings also reflect a certain model of security which might be either too
strict or too loose, again depending on the application.
1.3 Overview
In chapter 2 we introduce the notion of SMPC and the model of security in
which our protocols will be proved secure. The remaining part of chapter
2 describes some general concepts which are fundamental to the construction of our protocols, e.g. schemes for secret sharing. Chapter 3 treats a
collection of basic protocols for SMPC such as protocols for creating secret
sharings. Chapters 4 through 6 are concerned with protocols for manipulating the individual bits of integers. Such protocols are necessary for both
integer comparison and division. In chapter 7 we then deal with integer
protocols. Chapters 2 through 7 have main focus on describing, analyzing
and proving secure those protocols. In chapter 8 the focus is on our implementation and performance benchmarks of the implemented protocols.
In the cases where more than one protocol for the same job have been proposed, we will compare these solutions based on our experiments. Finally,
chapter 9 contains concluding remarks and briefly describes some potential
applications.
1.4 Contributions
Our main contribution is the development and implementation of protocols for secure integer division. This includes the protocol for secure binary
search which is found in section 7.4, the protocol for shifting up integers
into a certain interval in section 7.3.3, the exact truncation in section 7.3.1,
as well as the final division protocols in section 7.5.3.
The protocol for computing a single bit in a sum (section 5.2.1) is part of
the integer comparison protocol from the SCET research project [7, 36, 31].
We have combined this protocol with the prefix sum algorithm [27] in order
protocol in 5.2 for binary addition in logarithto create the
mic rounds. The preprocessing and reduction steps of the
protocol
(described in sections 6.2.1 and 6.2.2) are also part of the comparison proto
col from SCET. However, while the SCET comparison then uses the protocol (section 7.1) we instead use our own
protocol for
splitting all bits of the input integer
Prefix computation is also used for binary addition and splitting bits of
an integer in [16] but in a different context: In [16] constant round protocols are developed which do not seem to be as efficient in practice as our
protocols. See section 6.3 for a further discussion of this.
4
Introduction
Chapter 1
The remaining protocols in chapters 4, 5, 6, and 7 as well as all protocols
in chapter 3 are adopted from elsewhere, mainly SCET and [1]. We provide
appropriate references to the origins in each section.
As mentioned, our implementation relies on a prototype from the SCET
project that already contained protocols for addition, multiplication, and
comparison of integers as well as code for pseudo-random secret sharing
(see section 2.5). Unless otherwise stated, we have implemented all remaining protocols in this report.
1.5 Requirements and Notation
The reader is assumed to have basic knowledge of computer science, including algorithmics and complexity analysis. We also presume some basic
knowledge of algebra such as for instance knowledge of the Galois fields
GF( pn ) for primes p and n ∈ N. Also, some knowledge of probability
theory, including e.g. the notion of distribution ensembles is assumed.
The usual ceiling and floor functions are denoted by d x e and b x c. Also,
d x c will denote the largest integer y such that y ≤ x + 1/2. By log x we
mean the logarithm of x with base 2. Logarithms with the natural base e
is written as ln x. Throughout this report, p denotes a prime integer. By
Z p we mean the finite field of integers {0, 1, . . . , p − 1} where addition and
multiplication are done modulo p. The symbol (ba ) will denote the binomial
coefficient unless something else is mentioned. The binary representation
of an n-bit integer a is written ( a n , an−1 , . . . , a1 )2 with an being the most
significant bit.
1.5.1 A Note on Complexity
The efficiency of protocols for distributed systems is typically measured
through computational complexity and communication complexity. The first
measures the standard computational complexity in bit operations, i.e. the
number of primitive operations needed by the Turing machines involved.
Communication complexity captures the number of bits that are sent between the parties on the network. If the network is synchronous, as is the
case in our thesis, a third measure, round complexity, is also relevant.
We define communication complexity as the average number of bits
that is sent from a party. Hence, a protocol where only one out of k parties
sends, say, k bits will have communication complexity Θ(1) in our model.
If a bit is broadcast by a party, we count this as that party sending the bit to
each party, i.e. also having complexity Θ(1). Note, that on some networks,
broadcast may be more efficient than this model suggests.
The main part of the local computation done by each party in our protocols consists of computations in the finite fields Z p and GF(28 ). To simplify
Responsibilities 5
Section 1.7
the analysis we will therefore only measure computational complexity as
the number of operations in these fields, ignoring any computation outside
the fields such as storing elements in hash tables, creating objects, etc. For
simplicity we will assume that one multiplication in Z p takes O(log2 p) bit
operations while only Θ(1) in GF(28 ). We will also assume that modular
reduction and addition in Z p are O(1) and that modular exponentiation,
computing the inverse, and generation of a random element in Z p each
require a constant number of multiplications.
A more detailed picture is obtained by looking at how many bit operations the operations in Z p actually require. Table 1.2 adapted from [2]
shows the bit complexity of various operations in Z p . We refer to [2, 29]
for justification of these complexities. Counting modular exponentiation
operation
reduction
addition
multiplication
inversion
exponentiation
input
output
running time
a, p
p; a, b ∈ Z p
p; a, b ∈ Z p
p; a ∈ Z p
p, n; a ∈ Z p
a mod p
( a + b) mod p
ab mod p
b ∈ Z p , ab ≡ 1 mod p
an mod p
O(log a log p)
O(log p)
O(log2 p)
O(log2 p)
O(log n log2 p)
Table 1.2: Bit complexity for field operations.
as a constant number of multiplications is reasonable since the exponents
in our case are constants. Also, addition and modular reduction are almost always carried out in connection with multiplications in our context,
so counting these operations as taking a constant number of bit operations
does not distort the picture too much.
1.6 Responsibilities
It is difficult to strictly divide responsibilities for specific parts of this thesis
between the authors. Our work process has resulted in both authors being
involved in the development and writing of all chapters as well as in the
implementation.
However, since responsibility for some parts of the thesis must be divided, it would be reasonable to say that Thomas Jakobsen is mainly responsible for chapters 5 and 6, whereas Strange L. From is responsible for
chapter 3 and section 7.3. We consider the responsibility of the remaining
parts of the thesis to be equally shared between the authors.
6
Introduction
Chapter 1
1.7 Acknowledgments
We would like to thank our advisor Ivan Damgård for his invaluable help,
ideas, and fruitful discussions during the writing of this thesis. Also, we
owe a great thanks to Rune Thorbek for his assistance with the proof in
section 7.5.2 and Tomas Toft for useful ideas including reminding us of
the prefix algorithm in section 5.2.2. At last we would like to thank Jeppe
Brønsted, Lars Hesel, Rasmus W. Larsen, and Jacob Pagter for useful suggestions during the final stage of writing.
Chapter 2
Secure Multi-Party
Computation
In this chapter we introduce the concept of secure multi-party computation
as well as the associated model of security in which the protocols in this
thesis will be proved secure. We also describe basic concepts related to
secure multi-party computation such as e.g. secret sharing schemes and
homomorphic threshold encryption.
Finally, we present the notion of Pseudo-Random Secret Sharing (PRSS)
from [13]; this is a technique which enables us to construct protocols for efficiently creating various secret sharings with the players doing only broadcast of public information or even without communicating at all.
2.1 Introduction
Let f be any computable function that takes k input elements and produces
k output elements. Secure multi-party computation (SMPC) is generally
concerned with techniques that allow k parties, P 1 , P2 , . . . , Pk , where party
Pi knows the input value x i , to jointly compute
f ( x1 , x2 , . . . , x k ) = ( y1 , y2 , . . . , y k )
in such a way that party P i only learns y i . This should be the case even
in a scenario where an adversary has the power to corrupt some subset of
the parties. At first sight, the security of such a protocol can be separated
into correctness, i.e. that the honest parties end up with output that actually
is as defined by the function f on which they initially agreed, and privacy,
meaning that the adversary learns only the input and the output of the corrupted parties and nothing more. In the rest of this thesis, we will denote
the parties as players.
8
Secure Multi-Party Computation
Chapter 2
2.2 The Model of Security
This section contains a more precise definition that captures what we mean
by secure multi-party computation. A precise definition allows us to prove
that certain protocols are secure.
2.2.1 A Definitional Approach to Security
The security definition that we introduce here is a specialized version of
the more general definition found in [9]; our approach corresponds to the
approach of [1]. We will later briefly describe the general definition.
The security definition is motivated by the fact that the above requirements of correctness and privacy do not seem to capture completely the notion of secure computation. In fact, several more subtle requirements have
been recognized1 and there is no reason to believe that the list of requirements is yet complete. So, instead of defining security as the fulfillment of a
specific set of requirements, a definitional approach is taken based on two abstractions: First, a “real world” is defined in which the protocol in question
is actually being executed by the players. Also, an “ideal world” is defined
in such a way that we believe any reasonable security requirements to be
automatically satisfied. Secondly, the protocol is defined to be secure if it
makes the real world equivalent to the ideal world in some well-defined
sense.
In the following we seek to give a more formalized description of this.
First, set B = {0, 1} ∗ and let f : N × B k × Bk × B → Bk × B be the – possibly
probabilistic – function that the k players wish to compute. The first input
is a global security parameter ρ, the meaning of which will later become
evident. The second and third input denote the private input and random
coins of each player, and the last is some public input. The first output is
the private output of the players and the second is some public output. We
will call f an ideal functionality in that it captures exactly what the players
intend to compute. Also, we will for simplicity sometimes ignore both ρ,
the random coins, and the public values and just talk about an ideal functionality f : B k → Bk .
The Real World
The real world is modeled by a k-player protocol π, which consist of k interactive, probabilistic Turing machines that are connected in a way that
captures a fully connected, synchronous network. The Turing machines
represent the k players, P1 , P2 , . . . , Pk and the programs of these machines
1 Some of those are concerned with the cases where the function f is probabilistic and
others where the adversary is adaptive, see [9].
The Model of Security 9
Section 2.2
thus, constitute a precise definition of the real protocol that is intended to
compute f .
This world also contains a τ-limited real-world adversary defined by a
tuple A = ( A, C ) where C ⊂ {P1 , P2 , . . . , Pk } is the set of corrupt players
satisfying |C | ≤ τ. A is an interactive, probabilistic Turing machine programmed to capture the behaviour of the adversary. The players Pi ∈
/ C
will in the following be referred to as honest players.
Before execution of π begins, each player P i gets some private input denoted by x i and some random coins r i . In addition, each player starts off
with some public input X and a global security parameter ρ, the significance of which will later become evident. The adversary machine A also
gets public input X and ρ. Furthermore, A gets random coins r A and both
xi and ri if player Pi is corrupt. Finally, the adversary receives some auxiliary input z, representing information that might be available from previous
protocol executions, etc2 .
Now, the computation proceeds as specified by the protocol π. In each
round the adversary receives the messages that are sent to and from the
corrupted players. This models a situation where the adversary “looks
over the shoulder” of the corrupted players during the protocol execution. When execution of π has finished, the machines of the honest players
compute their private output as specified by π while the corrupted players
output a special symbol, ⊥. The adversary machine finally computes and
outputs a result that is a function of everything that it has seen during the
computation.
We now introduce some notation in order to capture this. Let ~r =
(r A , r1 , r2 , . . . , rk ) denote the random coins of the adversary and all players,
and let ~x = ( x1 , x2 , . . . , xk ) be the private input of the respective players.
x ,~r ) the output of the adversary machine A
We denote by
π,A ( ρ, z, X, ~
when run in interaction with the protocol π as described above. Further,
we denote by
x ,~r ) i the output of the i-th player machine after
π ( ρ, X, ~
execution of π, remembering that
x ,~r ) i = ⊥ if Pi ∈ C. Now, we
π ( ρ, X, ~
define
x ,~r )
π,A ( ρ, z, X, ~
=
x ,~r ),
π,A ( ρ, z, X, ~
x ,~r )1 , . . . ,
π ( ρ, X, ~
x ,~r ) k
π ( ρ, X, ~
x ) denote the corresponding random variable when
and let
π,A ( ρ, z, X, ~
~r is chosen uniformly random. Finally, we let
π,A denote the distribu tion ensemble {
x )} ρ∈N; z,X,~x∈{0,1} ∗ .
π,A ( ρ, z, X, ~
2 The auxiliary input might seem peculiar, but it turns out necessary in order to make the
later composition theorem work.
10
Secure Multi-Party Computation
Chapter 2
The Ideal World
In the ideal world there is no actual protocol execution. Instead, yet another
interactive Turing machine, the so-called trusted third party T is introduced;
the aim of this is to model an incorruptible entity. Also, the real-world
adversary is replaced by a τ-limited ideal-world adversary S = (S, C ), again
with C ⊂ {P1 , P2 , . . . , Pk } and |C | ≤ τ. This C does not have to equal the C
in the real world, but for secure protocols this will be the case, as we shall
see. In the following we will often not distinguish between the adversary
S and the Turing machine S.
The ideal-world adversary still receives as input the private input of the
corrupted players as well as the public and auxiliary information. However, instead of executing the protocol as in the real world, the honest players send their private input to the trusted third party T. Apart from this, T
gets as input ρ and also receives the private input of the corrupted players.
Then it tosses the random coins r f ∈ Bs that are needed for computation
of the ideal functionality. Here s might depend on ρ. T then computes the
output values
f (ρ, ~x , r f , X )1 , f (ρ, ~x , r f , X )2 , . . . , f (ρ, ~x , r f , X )k
possibly together with some public output Y which are then handed back
to the respective player machines. These results are, in turn, output by
the players except those who are corrupted, which still only output ⊥. The
ideal-world adversary outputs some function of all that it has seen, i.e. auxiliary input and public input, together with the input and output, including
the final results, of the corrupted players.
Now, let ~r = (r f , rS ) where rS is the random coins of the ideal-world
x ,~r ) as the output of S in the
adversary. We can then define
f ,S ( ρ, z, X, ~
ideal world with private player input ~x, and randomness~r. Here,~r includes
both the random input coins for S and the random coins that T uses when
computing f . Similarly, we define
x ,~r ) i as the output of the
f ( ρ, X, ~
i-th player. Finally, we set
x ,~r ) =
f ,S ( ρ, z, X, ~
(
ρ,
z,
X,
~
x
,
~
r
)
,
(
ρ,
X,
~
x
,
~
r
)
,
.
.
.
,
(
ρ,
X,
~
x
,
~
r
)
1
f ,S
f
f
k
x ) be the corresponding random variable when ~r is
and let
f ,S ( ρ, z, X, ~
uniformly distributed. Finally,
f ,S denotes the distribution ensemble
(
ρ,
z,
X,
~
x
)}
.
{
∗
π,A
ρ ∈N; z,X,~x ∈{0,1} This concludes the description of the
ideal world. Figure 2.1 summarizes the basics of the two worlds: In the real
world the players are connected by pairwise channels whereas they in the
ideal world are only connected to the trusted third party which computes
the ideal functionality. Corrupted players are placed inside the adversary
to stress that he has access to all their private information.
The Model of Security 11
Section 2.2
(a) The real world.
(b) The ideal world.
Figure 2.1: Models of the real and ideal worlds.
The Security Definition
The notation introduced above now enables us to more precisely define the
notion of security. However, first we need the following definition.
Definition 2.1. Let X = {X n }n∈N and Y = {Yn }n∈N be two distribution
ensembles of random variables X n and Yn such that these variables range over the
strings of length n. We say that X and Y are perfectly indistinguishable if for
all n ∈ N, Xn and Yn are identically distributed. We also say that X and Y are
statistically indistinguishable if for every polynomial p and for all sufficiently
large n ∈ N it holds that
1
∑ Prob(Xn = α) − Prob(Yn = α) < p(n) ,
α∈ B
and finally X and Y are defined to be computationally indistinguishable if
for every polynomial p, every probabilistic polynomial Turing machine D and all
sufficiently large n ∈ N it holds that
Prob( D (n, X n ) = 1) − Prob( D (n, Y n ) = 1) < 1 .
p(n)
12
Secure Multi-Party Computation
Chapter 2
The statistical and computational notions of indistinguishability are two
different ways of relaxing the notion of perfect indistinguishability. Intuitively, statistical indistinguishability allows the probability masses to differ
as long as the difference is exponentially small in the parameter n. Computational indistinguishability only requires that no polynomial time algorithm can tell the difference.
Definition 2.2. Let π be a protocol for k players and let f be the ideal functionality
that this protocol is intended to compute. We say that π τ-securely realizes f
if for any real-world τ-limited adversary A there exists an ideal-world τ-limited
adversary S such that
π,A
f ,S =
where the equality means either perfectly, statistically, or computationally indistinguishable according to definition 2.1. In the first case we talk about perfect
security, the second, statistical security and the third, computational security.
In the two first cases we allow both adversaries to be computationally unbounded,
whereas they in the case of computational security are polynomial time Turing
machines.
In other words, we define a protocol to be secure, if we – no matter how the
protocol is attacked – can come up with a “pseudo”-attacker, that learns the
same information as the attacker, but where the protocol execution itself is
replaced by an incorruptible third party that computes the desired ideal
functionality.
From this definition both correctness and privacy in the above sense follow immediately: By definition, T computes f correctly. If π does not result
in the same correct output, there will surely exist some real-world adversary with output depending on the deviating output from π that an idealworld adversary will never, no matter its computing power, know. Also,
since by definition the ideal-world adversary cannot corrupt T, it never
learns the private output of the honest players. Consequently, if π leaks
private information from more than τ players, there will exist a real-world
adversary with output depending on this information. The strength of our
definition is, as mentioned before, that other reasonable security requirements that we are not even aware of, will be automatically fulfilled likewise.
In the case of statistical security our demand is weakened in that we allow some information to leak as long as the probability for this to happen is
exponentially small in the size of the security parameter ρ. Computational
security is another way of weakening the definition; here, information leakage is allowed as long as this cannot be detected by any polynomial time
algorithm.
When the nature of the ideal functionality is clear from the context, we
will sometimes just talk about secure protocols, i.e. meaning that the protocols securely realize their respective implicit ideal functionalities.
The Model of Security 13
Section 2.2
Security by Correctness and Simulation
In our model, proving that a certain protocol securely realizes some ideal
functionality is often done by proving correctness of the protocol followed
by an argument for privacy.
By privacy we here mean that we, given an arbitrary real-world adversary A, can construct a corresponding ideal-world adversary S as a simulator of A, i.e. where S as a part of its program runs the real-world adversary
A making it “believe” that it runs in the real world. During the simulation
the task of S is to emulate the information that would otherwise have been
sent from the honest players to the corrupt players in the real world. The
challenge for the simulator is, of course, to do this without knowledge of
the secrets of the honest players. The simulation finishes with A outputting
something which is then also output by S . If S succeeds in its task, its output will be indistinguishable from the output of A in the real world. Figure
2.2 illustrates the simulation of the real-world adversary.
Figure 2.2: Simulation of the real-world adversary.
2.2.2 Modular Composition of Protocols
One benefit of our model of security is that it preserves security under modular, non-concurrent composition of protocols. This essentially means that if
a protocol π securely realizes f provided that it is allowed to make direct
calls to another ideal functionality g during execution, and if another protocol σ securely realizes g, then π will securely realize f if the direct calls to
g are replaced by the execution of σ. We will not present the proof of this;
the reader is instead referred to Canetti [9].
The notion of modular composability greatly simplify the construction
of many secure protocols. One can essentially “plug-and-play” protocols
14
Secure Multi-Party Computation
Chapter 2
that are already proved secure in order to build more complicated protocols
which are then automatically secure.
However, regarding execution time for protocols, it turns out in practice that rounds of communication are relatively expensive compared to the
amount of bits that are communicated (see chapter 8). We will therefore in
the following chapters focus on building protocols where independent subprotocols are executed in parallel, thus reducing the overall number of required communication rounds. It is important to note that the composition
theorem does not apply to such concurrent composition; instead, security
must be proved from the security definition itself 3 .
The composition theorem allows composition of protocols that each realize some ideal functionality. However, the protocols that we present are
generally divided into such small parts (subprotocols) that it does not make
sense to talk about ideal functionalities for each of them. For instance, an
ideal functionality makes little sense if the players do not send or receive
anything from the trusted third party.
Hence, our overall strategy will be to divide the subprotocols that are
presented in the following chapters into sequential parts which are each
accompanied by proofs of correctness combined with partial simulation arguments. In chapter 7 we will then prove security of our final protocols by
giving complete simulation arguments that are essentially compositions of
the partial simulations according to the involved subprotocols.
We will therefore in the following talk about a τ-secure subprotocol if
it is correct and τ-private where correctness means that the players end up
with the intended results after execution of the subprotocol and where τprivacy means that for any τ-limited real-world adversary, there exists a
simulator as described in the previous section. The simulation is partial in
the sense that if the execution of the subprotocol relies on information that
is the result of earlier subprotocols, then the players and the trusted third
party are assumed to already have this information at their disposal.
2.2.3 Extending the Security Model
It is possible to strengthen our model of security in several directions, many
of which concern the specific capabilities of the adversary. In our thesis we
have chosen a model involving a relatively weak adversary. This makes
analysis as well as implementation easier. This approach is further motivated by the fact that there exist standard techniques to apply in order to
make our protocols secure in the presence of more powerful adversaries.
Unfortunately, these techniques tend to decrease performance. In this section we give a brief overview of some of the possible extensions.
3 Our
model is based on [9], but Canetti has later developed a more comprehensive
model of security [10] in which also concurrent composition is possible; we will, however,
not deal further with this here.
Section 2.2
The Model of Security 15
Active adversary From the definition in section 2.2.1 it follows that our
adversary is passive in the sense that the players that he corrupts do not
behave maliciously. Corruption done by a passive adversary only means
that the adversary gains insight into the private information held by the
corrupted players. In contrast, an active adversary has the power to modify
the behavior of the corrupted players and may also cause them to crash before the protocol has finished. Our security model can easily be extended to
capture also the case of an active adversary, see [9]. Accordingly, there exist
techniques by which we can extend our protocols to also provide security
against an active adversary. This is done, generally speaking, by having
the players commit to their input, jointly generate their randomness, and
prove in zero-knowledge4 that they indeed follow the protocol. Moreover,
protocols that require all players to take part can by the share-backup techniques described by Rabin [33] be converted into protocols that only require
the majority of players to behave honestly.
With an active adversary, the model must also address the notion of
rushing, that is, whether the adversary gets to see the messages that corrupt players receive from the honest players in a round before he decides
what the corrupt players should send to the honest players.
General Access Structures. Our adversary is allowed to corrupt a certain
number, i.e. τ, of the players. However, there are even more general models where the adversary structure, i.e. the structure of the possible subsets of
players to corrupt, is not defined by a certain threshold, but rather depends
on the number of subsets that is needed in order to cover the whole set of
players [23]. There exist techniques which allow our solutions to work with
general adversary structures, cf. [13, 24].
Adaptive adversary. We only work with a static adversary. This means that
the subset of players that is corrupted must be determined before execution
of the protocol begins. A more powerful adversary might be able to choose
whom to corrupt based on information gained during protocol execution.
Such an adversary is called adaptive. The model can be extended to capture
this, see [9], but this adds to the complexity of the definition and the proof
of the composition theorem.
Non-secure channels. In our model, we assume that the adversary has no
access to information sent between honest players. This is sometimes called
the secure channels model. However, a real adversary will typically be able
to tap the communication channels even between honest players. These
4 For more on commitment schemes and zero knowledge protocols, including a proof of
the fact that all problems in NP have corresponding zero-knowledge protocols, see [15].
16
Secure Multi-Party Computation
Chapter 2
channels will then most likely be protected by standard cryptographic techniques such as public key cryptography and digital signatures. Consequently, security in this model will rest on some cryptographic assumptions and we therefore cannot hope for more than computational security.
Broadcast. In a model with passive adversary as ours, broadcast is easily obtained; a player simply broadcasts a value by sending it to each of
the other players. However, with an active adversary, broadcast requires
execution of an additional protocol that prevents a corrupted player from
sending different values to the other players instead of broadcasting. We
will, however, not deal any further with this issue here.
2.2.4 General Results
The question now remains which functionalities can possibly be securely
realized in our security model and in models with extensions such as those
described above. It was shown in [6] and [11] that every computable function can be securely realized in a model with an adaptive and passive adversary if he corrupts less than k/2 players, i.e. with honest majority. Security can also be obtained against an active adversary if less than k/3 players
are corrupted5. The fastest general protocols for this are those of Gennaro,
Rabin, and Rabin [18]. This easily reduces to our model, say, if the adaptive
adversary chooses to corrupt all players before the computation starts.
These results are generally believed to be too inefficient for practical
computation of general functions. Later effort have been concerned with
the design of more efficient and thus practical protocols for specific functionalities. Examples of this include [8, 1] for securely computing an RSA
modulus as well as the SCET project [7] and our thesis which focus on efficient computation on integers.
2.3 Secret Sharing
We now introduce the concept of secret sharing along with some specific
sharing schemes. In particular, we describe the polynomial sharing scheme
invented by Shamir [34] followed by schemes for additively sharing elements of finite fields as well as elements within a finite interval of the integers. Concrete protocols for creating such sharings will be treated in the
next chapter. The SCET prototype and our implementation of protocols for
integer division are based on these schemes for secret sharing.
In general, a secret sharing scheme gives a dealer the possibility to distribute a secret among k players such that only certain predefined sub5 This can again be relaxed to k/2 if a broadcast channel is available; however this only
gives statistical security.
Section 2.3
Secret Sharing
17
sets of the players can restore the secret while others not included in these
subsets learn nothing at all about the secret. These predefined subsets are
called the access structure. One type of secret sharing schemes that are
widely used are threshold schemes, where the access structure includes all
sets of more than τ players for a threshold τ ∈ N.
2.3.1 Shamir’s Scheme
One of the best known threshold schemes for secret sharing is Shamir’s
sharing scheme [34]. The threshold used in our thesis is τ = b k−2 1 c which
means that once a sharing has been established then nobody will learn the
secret value if at least half the players do not reveal their shares.
Let F be a finite field and suppose also that the players are indexed
as P1 , P2 , . . . , Pk with the indices 1, 2, . . . , k being distinct non-zero elements
of F. A Shamir (or, polynomial) sharing of an element s ∈ F consists of
the k points f (1), f (2), . . . , f (k) on a τ-degree polynomial f ∈ F[ X ] of the
following form
τ
f ( x ) = s + ∑ si x i ,
i =1
with f (0) = s being the secret and the coefficients s i chosen at random.
The elements f (i ) are distributed among the players such that player Pi
holds f (i ) which is then called his share of the secret. Figure 2.3 illustrates
a Shamir sharing for 5 players and τ = 2.
Figure 2.3: A Shamir sharing of an element s ∈ F.
In this way τ or less collaborating players will have no idea of what the
secret is since for each s 0 ∈ F there exist a polynomial with f (0) = s 0 and
f (i ) = si for those players’ shares s i . Now, if τ + 1 or more players collaborate, they may reconstruct the secret by means of polynomial interpolation
in the field F. That is, they could apply the Lagrange interpolation 6 for6 Other
interpolation techniques exist such as monomial or Newton interpolation (see
18
Secure Multi-Party Computation
Chapter 2
mula [20] which allows one to obtain the unique polynomial f of degree at
most τ from τ + 1 points of it: Let C = { Pi1 , . . . , Piτ +1 } be any subset of size
τ + 1 of the k players; then the secret may be efficiently reconstructed as
f (0) =
where
λi j =
τ +1
∑
j =1
f (i j ) λ i j
ik
∈ F.
i − ij
1≤ k ≤ τ,k 6 = j k
∏
Since the Lagrange interpolation coefficients λ i j only depend on the field
and τ and not the polynomial to interpolate, they may be computed in
advance and do not need to be kept secret.
2.3.2 Additive Sharing Schemes
As will become clear later, we will also need to work with additive sharings, i.e. sharings where the secret is defined by the sum of the players’
shares. Such schemes naturally lead to a threshold τ = k − 1 meaning that
all players must reveal their shares to reconstruct the secret. We will need
both additive sharings over finite fields and over the integers. An additive
sharing of a secret s ∈ F simply consists of k random shares s 1 , s2 , . . . , sk
distributed among the players such that
s=
k
∑ si .
i =1
Additive Sharing over the Integers
The scheme for additive sharing over the integers resembles that of an additive sharing over a finite field. However, here the secret is supposed to
be in some finite interval of the integers, i.e. s ∈ [− A; A] for some fixed
A ∈ Z. The distributed shares is chosen from some larger range, say,
si ∈ [− A2ρ ; A2ρ ] for i = 1, 2, . . . , k where ρ is the security parameter. Also,
in this scheme there must be a public integer S such that
k
s = S − ∑ si .
i =1
In this way, the secret can only be reconstructed by having all players reveal
their shares. The reason for requiring each share to be chosen randomly in
a larger range than the secret has to do with security and the fact that a sum
e.g. [20] chapter 7.2.1-7.2.3). However, Lagrange interpolation is optimal w.r.t. the work
needed to interpolate from given points, i.e. the shares held by the players.
Section 2.4
Homomorphic Threshold Encryption 19
of random shares ∑ si with each s i ∈ [− A; A] is not uniformly distributed.
E.g. the sum of integers chosen uniformly within [− A; A] will be zero with
larger probability than, say, ± A. With the larger range it is, however, possible to construct protocols that are statistically secure [2].
2.4 Homomorphic Threshold Encryption
Secret sharing schemes are not the only means by which SMPC-protocols
can be build. Another approach is based on the existence of homomorphic threshold cryptosystems7. We here give a brief overview of this approach. For details, the reader is referred to the work presented by Cramer,
Damgård, and Nielsen [14].
A homomorphic threshold encryption scheme is a semantically secure
threshold public-key cryptosystem, i.e. there is a public encryption key p k
known by all players and a matching private decryption key that has been
shared among the players. The message space should be a ring, e.g. Z n for
some n ∈ N. Furthermore, we require certain homomorphic properties:
Given encryptions E( a) and E(b) under the public key p k , where a ∈ Zn
and b ∈ Zn are the plain-text messages, an operator should exists such
that anyone can easily compute an encryption E( a + b) as E( a) E(b). We
also require that it is easy to compute an encryption of α · a given an encryption E( a) and a constant α ∈ Z n .
Finally, we need that the following three secure subprotocols are available: A protocol by which a player can prove that he knows a certain plaintext, a protocol for proving that multiplications are correct, i.e. proving that
E(α · a) indeed holds the product of the values in E(α) and E( a), and at
last a threshold decryption protocol that – given the encrypted message,
the public key, and the private key shares – securely computes the original
message as output to every player.
Given a threshold cryptosystem satisfying these properties, it is shown
in [14] how to build protocols for general SMPC with security against an active adversary and with honest majority. As an example of a homomorphic
threshold encryption scheme with these properties, [14] mentions Paillier’s
public-key system.
The SCET prototype and our protocols for division are build on the notion of secret sharing rather than homomorphic threshold encryption. As
pointed out in [36], the main reason for this is the size of the individual
shares of an integer. Using homomorphic threshold encryption, the individual shares are encryptions of secrets and therefore have size Ω(ρn)
where ρ is the security parameter and n is the size of the integers on which
to compute. Using Shamir sharings, the individual shares generally have
7 This
approach is quite effective even when the adversary is active, but currently the
solution relies on computational assumptions and only works for a static adversary.
20
Secure Multi-Party Computation
Chapter 2
size only Ω(n). Shamir sharings where chosen due to storage considerations since the SCET project is concerned with protocols involving a large
amount of sharings.
2.5 Pseudo-Random Secret Sharing
Before we turn to concrete implementation of protocols for secret sharing,
we introduce the notion of Pseudo-Random Secret Sharing (PRSS). For a thorough treatment we refer to the article of Cramer, Damgård, and Ishai [13].
The motivation is that, in order to make our advanced protocols efficient, we would – in the case of Shamir and additive sharings over a finite
field – like the players to be able to create sharings of random elements noninteractively, i.e. by doing only local computation without communicating
with other players.
The first thing to notice is that, contrary to shares of the Shamir scheme,
the individual shares of the additive sharing scheme for finite fields presented section 2.3.1 are completely independent. Thus, a random sharing
in such a scheme may easily be established non-interactively by simply
having each player choose a random share from the field. This is, however,
not possible in the Shamir scheme, since shares chosen independently at
random may in this case lead to inconsistent sharings, i.e. Shamir shares
that do not define any polynomial of degree τ.
To remedy this, we introduce the notion of replicated sharing schemes [13].
Consider an arbitrary access structure 8 A and let S be a subset of the players. We will denote S as qualified if S ∈ A and unqualified if S ∈
/ A. By
a maximal unqualified set of the players we mean an unqualified set S such
that for any unqualified set T it holds that | T | ≤ |S|. Thus, for a threshold
structure with threshold τ, a maximal unqualified set is a subset S of the
players with |S| = τ.
Let T ⊆ A denote all maximal unqualified subsets of the players. In
the replicated secret sharing scheme R A of A, a dealer shares a secret s by
first locally generating an additive sharing of s over the number of subsets
in T , i.e. by choosing random elements r T such that
s=
∑
T ∈T
rT .
An element r T is subsequently distributed to all players Pj where j ∈
/ T;
the replicated share of player Pj will thus consist of a collection of those
r T for which Pj ∈
/ T. Consequently, any unqualified set of the players will
always miss at least one share and hence be unable to reconstruct the secret
whereas any qualified set will collaboratively know all shares.
8 We only consider monotone access structures, i.e. where qualified sets cannot be contained within an unqualified set.
Section 2.5
Pseudo-Random Secret Sharing
21
The important feature of the replicated scheme is that the elements r T
for T ∈ T are now independent of each other. Thus, similar to the additive
scheme for finite fields, random sharings in this scheme may be generated
non-interactively if the players have access to randomness. However, since
each element r T must now exist in several replicates held by different players, these players must somehow agree on the random choices of r T . This
is handled by predistributing (τk ) pseudo-random functions ψ T among the
players, one assigned to each maximal unqualified subset T ∈ T , such that
player Pj gets a copy of ψT if he originally would have had a copy of r T . In
this way, each player will hold (k−τ 1) functions. Each time a random sharing
in the replicated scheme is needed, the players non-interactively generate
a new set of random elements r T using their respective functions ψ T .
Now, the main point is that [13] describes a technique by which the
players may non-interactively convert a replicated sharing into e.g. a Shamir
sharing of the same element. Consider, sharings over some finite field F
and suppose that the players are indexed with distinct non-zero elements
from F, e.g. denote w.l.o.g. the players by Pi for i ∈ {1, 2, . . . , k} ⊂ F. Consider also, a secret s ∈ F and the according replicated sharing over a τ
threshold access structure
s=
∑
T ⊆ P: | T |= τ
rT ,
with P being the set of all players and where T denotes the maximal unqualified subsets. For each set T, let f T ∈ F[ X ] denote the unique polynomial of degree τ that satisfies
f T (0) = 1
f T (i ) = 0,
for all i ∈ T.
Each player Pj can now locally compute
sj =
∑
T ∈T : j/
∈T
r T f T ( j ),
which will result in a consistent Shamir sharing of s. This comes from the
fact that the polynomial
f ( x) =
∑
T ∈T
rT f T ( x)
obviously has degree τ and satisfies f (0) = s and f (i ) = s i for i ∈ P.
Observe, that the polynomials are fixed and public and thus can be precomputed.
As a small example, consider sharings over F = Z 7 with 5 players and
τ = 2, i.e. Z7 ⊇ P = {1, 2, 3, 4, 5}. A replicated sharing will then consist of
22
Secure Multi-Party Computation
Chapter 2
(52) = 10 elements replicated among the 5 players such that each player’s
replicated share consists of 6 elements. We will need 10 polynomials f T for
locally converting such a sharing to a Shamir sharing, namely one for each
T ⊂ P with | T | = 2. For instance, we have
f {3,5} ( x ) =
( x − 3)( x − 5)
.
(−3)(−5)
In our implementation (see chapter 8), each Shamir sharing that is created
during the computation is given a unique id-number. This allows us to implement the pseudo-random functions ψ T as AES encryptions. The AES is
widely regarded as a good quality pseudo-random function, see e.g. [21].
More specifically, during the initialization phase, (τk ) 128-bit AES encryption keys κ T are generated and distributed as the pseudo-random functions
ψT above. When the players wish to generate a fresh replicated sharing of
a random element with, say, id x, the relevant players compute
r T = ψT ( x ) = F ( E(κ T , x ))
where E(κ T , x ) denotes the AES encryption of x using encryption key κ T
and F denotes some function to transform the obtained cipher bits into an
element r T ∈ F.
We finally note, that the PRSS solution described here does not scale
well when the number of players increase. This is due to the initial management of the (τk ) replicated field elements. However, most applications of
SMPC only involve a relatively small number of players. Furthermore, the
SCET project [7] includes a technique that allows auxiliary parties, i.e. parties that do not participate in the computation, to submit data to the computation in form of secret sharings. In this way, computation on data held
by many parties can still be carried out even though the trust is only distributed among a few players.
2.5.1 Protocols Based on PRSS
From the above discussion we immediately have protocols for creating
(pseudo) random Shamir and additive sharings that none of the players
and
, respectively.
know. We will call those protocols
Sharing Specific Elements
We now describe how the
and
protocols are extended in or
der to create protocols
and
by which a random sharing
can be non-interactively generated such that only a certain player knows
and
that allow a partithe secret. This will then lead to protocols
cular player to secretly share an element that only he knows. This will only
Section 2.5
Pseudo-Random Secret Sharing
23
require broadcast of a public element of F or, in case of
, no communi
cation. The
is part of the SCET project. We have extended this with
an implementation of the
protocol.
Consider first the
protocol. Assume that, instead of one set of
pseudo-random functions Ψ = {ψ T } T ∈T , we initially generate k such sets
Ψ1 , Ψ2 , . . . , Ψk independently and distribute each of them just as the original set would have been distributed. Suppose, furthermore that Pj is given
9
the complete set Ψ j . The protocol
( j) works just as the original
, but the players now use the functions Ψ j which results in a sharing
of a random element r ∈ F with id x. Player Pj , who as the only player
knows the complete set Ψ j , can now locally compute the element r as
r=
∑
ψT ( x ).
(2.1)
ψT ∈ Ψ j
A similar extension is possible for the additive scheme over F. However,
this requires that the shares are generated from predistributed pseudo protocol. As explained, this
random functions as is the case in the
is straightforward since the additive shares are independent and also, security is easily seen to be maintained. We will denote these functions by
Φi .
Now, suppose that Pj wishes to create a Shamir sharing of an element
( j) which results in
s ∈ F that only he knows. The players first run
a sharing of a random element r ∈ F. Player Pj computes r as indicated by
equation 2.1 and broadcasts b = s − r to all players which, in turn, adds b
to their respective shares, resulting in a share of s. We will call this protocol
( j, s).
Again, a similar protocol is possible for creating an additive sharing
over F of a secret known by one player Pj . The players first run
( j)
resulting in a sharing of a random r ∈ F with id x. However, since the sharing is additive, no communication is needed. Player Pj simply computes
r=
∑
φ∈Φ j
φ ( x ),
where Φ j as mentioned denotes the complete key set for
that player Pj
has initially been given, and adds s − r to his own share.
A protocol
for creating an additive sharing over Z of an integer s
known only by Pj is also possible using only a broadcasts. Each player Pi
generates from Φ j a random integer r i ∈ [− A2ρ ; A2ρ ] and player Pj computes and broadcasts s − ∑ki=1 ri .
does not indicate that the players
the misuse of notation. The protocol
should use the key set Ψ i . The index of the key set to use is given in parenthesis, e.g. Ψ j for
( j ).
9 Note
24
Secure Multi-Party Computation
Chapter 2
2.5.2 Binary Sharings
As will become clear later, we will need a protocol for creating a Shamir
sharing of a random element r that is either the additive or the multiplicative identity, i.e. r ∈ {0, 1} ⊆ F. We will call this a binary sharing. Here, we
describe a protocol,
, based on PRSS for generating such a sharing
if F has characteristic 2. The protocol works as the general protocol
for generating random elements. However, we now use the predistributed
pseudo-random functions ψ T (·) from the predistributed set Ψ to generate
random elements from the subset {0, 1} ⊆ F instead of, as previously, just
any random elements from the field. Suppose that we wish to generate a
random bit sharing with id x and let h : F → {0, 1} ⊆ F be a function that
based on any element from F produces a random 0 or 1 from F. Then a
random bit sharing is generated by having each player Pj locally compute
his replicated shares r T as
rT =
∑
h(ψT ( x )).
ψT ∈ Ψ i
This results in a replicated sharing of r ∈ {0, 1} as desired since addition is
this is then locally
equivalent to in such fields. As in the case of
converted to a Shamir sharing.
Using the sets Ψ j instead of Ψ (again, see section 2.5), this immediately
yields a protocol
( j) similar to
( j) except that a bit rather
than just any random element known by Pj is generated. Also, similar to
we can construct a protocol
for creating a binary sharing of a secret
s ∈ {0, 1} that one of the players chooses.
Our implementation contains all of the above protocols; that is, in the
initialization phase, k sets each consisting of (τk ) keys are distributed among
the players for the
protocol and one set for the
. Similarly,
k sets of k keys are distributed for the
and
protocols and an
additional set of k keys for the
protocol.
2.5.3 Security
protocol
It is important to note that even though one could expect the
and its variations to be computationally secure, we cannot prove this since
PRSS does not directly fit into our security model. The reason for this is
that the ideal functionality FPRSS , which simply creates a random Shamir
sharing and distributes the shares among the players, is too “low-level”
dealing with individual shares rather than shared elements ∈ F. To see
this, suppose we are given a real-world adversary A that simply outputs
the resulting shares of the corrupted players. This would (with our passive
adversary) result in EXECPRSS,A ranging over only Shamir sharings consistent with the keys used in PRSS. We will not be able to simulate this with
Section 2.5
Pseudo-Random Secret Sharing
25
any ideal-world adversary S since the view of S does not include the keys
of the honest players. Hence, the distributions in IDEAL FPRSS ,S will inevitably
include inconsistent Shamir sharings with substantial probability no matter
how large ρ gets.
It is however possible to build protocols based on PRSS that are computationally secure in our model as long as those protocols work at a higher
level, i.e. realizing functionalities that are not concerned with individual
shares. As a small example we consider the 3-player ideal functionality
FSUM ( a, b, ⊥) = (s, s, s) in which P1 and P2 submit values a and b to the ideal
functionality and where every player then learns the sum s = a + b. Let
be the protocol where the players execute
(1, a) and
(2, b), respectively. This means that player P1 secretly shares a and player P2 secretly
shares b. This is followed by each player Pi computing and broadcasting
s i = a i + bi .
securely realizes FSUM we will need to formalize
Before we prove that
what is meant by a secure pseudo-random function.
Definition 2.3. A pseudo-random function ψ, the quality of which depends on
some parameter n (e.g. the encryption key length in case of AES), is said to be
secure if for any computationally bounded probabilistic Turing machine M, the
output distribution ensemble { X n }n∈N of M given truly random coins is computationally indistinguishable from the output ensemble {Yn }n∈N of M if M is
instead given pseudo-random coins as generated by ψ.
This leads us to the following property.
Property 2.4. Assume that the predistributed pseudo-random functions ψ T used
by the players (see previous section) are secure. Then the protocol 1-securely
realizes the ideal functionality FSUM in the computational sense.
Proof. Let A be any 1-limited real-world adversary and suppose for simplicity that P1 is corrupted. Our goal is to construct an ideal-world adversary S with output computationally indistinguishable from that of A. In
our case, S will simulate the real-world protocol with A. That is, S will
create a pseudo-random function ψ10 for the corrupt player and give ψ10 to
A. In the real-world protocol A would receive r b = b − r (Ψ2 ) from P2
where r (Ψ2 ) denotes the pseudo-randomness that P2 uses to hide b as described in the section above. As r b is unknown to S it instead feeds A with
a truly random r and finally outputs whatever A outputs.
We now argue that the above construction of S works. Suppose, that
is not computationally secure when we use S . This means, that there
exists some real-world adversary A 0 (and values a0 and b0 ) such that the
real-world output distribution ensemble EXECSUM,A0 is computationally distinguishable from the ideal-world output distribution IDEAL FSUM ,S . We will
in the following show how to use the existence of A 0 (and a0 , b0 ) to con-
26
Secure Multi-Party Computation
Chapter 2
struct a polynomial time Turing machine D which is able to distinguish between an oracle that delivers either true randomness or values generated
from a secure pseudo-random function, i.e. a contradiction by definition
2.3.
Suppose, for simplicity that A 0 corrupts P1 and that the oracle O contains either the pseudo-random functions ψ2 , ψ3 of the honest players or
true random sources. The distinguisher D will now, using its knowledge of
a0 and b0 and the oracle, simulate the real-world protocol with A 0 . That is,
D will first (using its own randomness) generate a pseudo-random function ψ1 for the corrupt player and feed this to A 0 . Now, D emulates the
honest players during the protocol by calling O whenever the honest players would have used their pseudo-random functions. From this simulation, output identical to EXECSUM,A0 will be generated if O contains pseudorandom functions and output equal to IDEAL FSUM ,S will be produced if the
oracle contains true randomness. Since these outputs by assumption can be
distinguished, D finally outputs 1 or 0 depending on which case it sees.
Remark 1 It should be clear from the proof that it could easily be generalized to functionalities and protocols involving more than three players.
Note the correspondence between the Shamir scheme with threshold 1 and
the fact that the protocol 1-securely realizes its ideal functionality. If the adversary were allowed to corrupt more than one player, the Shamir scheme
would break and the real-world adversary would learn all shared secrets
contrary to the ideal-world adversary, thus making simulation of the protocol output impossible. Generally, we will τ-securely realize ideal functionalities by protocols based on Shamir schemes with threshold τ. In the
rest of this thesis, we will talk about secure protocols meaning protocols
that τ-securely realizes their ideal functionalities for any such τ ≤ b k−2 1 c.
Remark 2 Note that an ideal functionality involving true randomness can
never be realized with perfect or statistical security by a protocol relying
on pseudo-random functions such as PRSS. This is, intuitively speaking,
because a pseudo-random distribution based on a key of finite length will
always be only computationally close to a true uniform distribution.
PRSS is a technique by which communication between the players can be
either eliminated or reduced to broadcast of public information. This comes
at the cost of the initial distribution of pseudo-random functions and – as
we have now seen – a less strict (i.e. computational) definition of security.
As we have seen, the PRSS protocols do not fit well into our security
model as a stand-alone protocol. In order to provide as clear a presentation
as possible, we will therefore in the following chapters momentarily forget about PRSS and build protocols without PRSS which then require more
(and private) communication between the players, but where arguing for
Section 2.6
Summary
27
(statistical) security is somewhat simpler. We will then in chapter 7, where
our final protocols are presented, return to PRSS and prove that those protocols are still computationally secure when the more efficient PRSS technique is applied.
2.6 Summary
In this chapter we have introduced the concept of secure multi-party computation as well as the model of security in which our SMPC protocols will
be proved secure. This model has the nice property of maintaining security
under modular composition of protocols as long as this is done sequentially. Next, we have discussed the notion of homomorphic threshold cryptography and, more important in our case, various secret sharing schemes,
which are both means by which SMPC can be realized. Finally, we have
discussed how certain basic protocols can be efficiently implemented w.r.t.
communication using Pseudo-Random Secret Sharing, and we have by an
example shown how to prove such protocols computationally secure.
Chapter 3
Basic Protocols
In this chapter we present a collection of basic protocols for managing the
sharings that were introduced in chapter 2. First, we will present protocols
for a player to create a polynomial or additive sharing of an element in a
finite field F. Following this, we discuss a protocol allowing the players
to jointly create a sharing of a random element which is unknown to all
players.
Secondly, we present protocols for arithmetic computations on polynomial sharings over F. This includes protocols for adding and multiplying
a constant to a polynomially shared secret as well as protocols for adding
and multiplying two polynomially shared secrets.
Finally, we present some protocols for converting secrets between different sharing schemes. We will cover conversion between additive and
polynomial (Shamir) sharings over a finite field and conversion between
additive sharings over a finite field and the integers.
All protocols presented in this chapter also appear in [1, 2] from which
some of our notation is also adopted. We will here only give the main ideas
behind the protocols; for exact proofs we refer the reader to [2].
3.1 Sharing Elements
In order to work with sharings of secrets the players need a way to create
these sharings. Here, we will give a short introduction to protocols for
creating polynomial and additive sharings. We also describe a protocol for
creating a polynomial sharing of a random element unknown to all parties.
3.1.1 Polynomial Sharing
Let k be the number of players and τ the threshold, then we can construct
a polynomial sharing in the following way: Let F be a finite field and suppose that the players are indexed as P1 , P2 , . . . , Pk with 1, 2, . . . , k being dis-
30
Basic Protocols
Chapter 3
tinct non-zero elements of F. When a player Pj wants to create a Shamir
sharing of a element s ∈ F, he adopts the role of a dealer and randomly
chooses τ coefficients s i ∈ F, thus defining the following τ-degree polynomial
τ
f ( x ) = s + ∑ si x i
i =1
with f (0) being the secret. Then, for i 6= j, Pj sends the values f (i ) to Pi ; that
is, f (i ) becomes Pi ’s share of the value s. The player thus sends out k − 1
elements, one share for each of the other players. If the shared value is to
be known only by Pj (or by τ + 1 collaborating players) the values must be
sent using private communication channels. The protocol for generating a
. To restore a secret,
polynomial sharing will in the following be called
all players simply broadcast their shares; this protocol will be called
.
A polynomial sharing of a secret s ∈ F will be written as [s] F . Also, the
individual share s i held by player Pi will be denoted by [s]Fi .
Regarding security of this protocol, we note that since the elements sent
by the dealing player to the other players are chosen uniformly at random
in the field F, simulation is easy: Simulation is simply done by supplying
the real-world adversary with elements chosen at random from F. He will
have no chance of knowing in which world he is, and his output distribution will be identical to the output distribution of the real world. In case the
sharing player is itself corrupted, simulation is trivial since the adversary
does not expect to see any input from the honest players.
3.1.2 Additive Sharing
All that a player Pj has to do to share a secret s ∈ F is to choose k − 1
random elements s i ∈ F for i 6= j and send s i to player Pi . Finally, he
computes his own share s j ∈ F as
sj = s −
k
∑
i =1,i 6 = j
si .
. In order to reconstruct the secret, the playThis protocol will be called
ers simply all broadcast their shares. The secret is then found by summing
up all the shares.
Again simulation is easy, as the shares are chosen as random elements in
the field F. In the following an additive sharing of a secret s ∈ F will be denoted by hsiF and we write the individual shares as hsi Fi for i = 1, 2, . . . , k.
3.1.3 Joint Random Polynomial Sharing
In [1, 2] a protocol called
is described for creating a polynomial sharing
[r ]F of a random value r unknown to all players. The protocol consists of
Section 3.2
Arithmetic Computation
31
each player Pj choosing a random value r j and creating polynomial shares
of this using
. Finally, each player adds up all the shares obtained from
the other players.
For this protocol to be secure, we have to be able to simulate the sharing
of an element and also how to add two shares. It should however be clear
by now from section 3.1.1 that the
protocol is easy to simulate. Simulation of the addition step is trivial since this involves no communication
between players.
3.2 Arithmetic Computation
In this section we will give a brief description of some protocols for doing basic arithmetic computations on polynomially shared secrets. These
basic computations include adding and multiplying a shared secret with a
constant as well as adding and multiplying two shared secrets.
3.2.1 Addition
Suppose that c ∈ F is a public constant, and that a ∈ F is secretly shared
via the τ-degree polynomial f a ( x ), i.e. that player Pi has share f a (i ). Then,
by basic properties of polynomials, the shares f a (i ) + c for i = 1, 2, . . . , k
will be shares of a τ-degree polynomial g with g(0) = a + c and random
coefficients. Therefore, a sharing of a + c is obtained by having each player
.
locally add c to his share of a. The protocol for this will be called
Similarly, if two secrets a and b are shared by the polynomials f a and
f b , each player can compute a share of a + b by locally computing f a (i ) +
f b (i ), which will produce sharings of a τ-degree polynomial g with random
coefficients and g(0) = a + b. We will call this protocol
.
As these protocols require only local operations on the players’ individual shares, simulation is trivial.
3.2.2 Multiplication
Again, as with adding a public constant c and a polynomially shared secret, multiplying a shared secret and a known constant is easy. The players
each multiply the constant to their respective shares of the secret which will
yield a new polynomial with the desired properties. We call this protocol
. Note, that subtraction of, say, [ a] F − [b]F , is then simply computed
as
([ a]F ,
([b]F , −1)). We will sometimes just write c[ a] F instead of
F
(c, [ a] ) and [ a]F + [b]F instead of
([ a]F , [b]F ) to simplify the notation.
Multiplication of two polynomial sharings is more involved and solutions seem to require communication. Suppose again, that we have two
32
Basic Protocols
Chapter 3
secrets a and b which are shared by polynomials f a and f b , respectively. Locally multiplying shares will result in a polynomial g with g(0) = ab, but
the problem is that g will have degree 2τ. Another multiplication would
result in a 4τ-degree polynomial, etc., and soon the degree is too high for
interpolation. Moreover, after multiplication the coefficients will no longer
be uniformly distributed, e.g. g is not irreducible.
To overcome this, we use a protocol due to Genaro, Rabin, and Rabin
[18] which we will denote
·, · . In this protocol, each player Pj first
locally multiplies his shares of a and b thereby obtaining a share c j . Now,
each player creates a new sharing [c j ]F of his share c j using
. After this
resharing, the players can jointly interpolate a 2τ-degree polynomial g̃ with
,
, and the fixed and public
random coefficients and g̃ (0) = ab using
Lagrange coefficients mentioned in section 2.3.1.
Regarding security, we note that simulation of
is trivial as this re
protoquires only local operations. When simulating execution of the
col the first step of multiplying local shares is just as easy to simulate as an
addition. The second step, i.e. resharing a share, simply consists of creating
a polynomial sharing and this can, as in section 3.1.1, easily be simulated
because all the elements that are sent to the other players are chosen at random in F. Thus, all we have to do in order to simulate is to supply the
real-world adversary with elements chosen uniformly random in F.
Multiplying Two Elements and Opening
As we have seen above, the
protocol requires the players to reshare
their individual shares. However, if the players wish to open up the product right after this one multiplication, the resharing step is not needed
[36]. This is due to the fact that the degree of the polynomial before resharing is 2τ. Since τ < b(k − 1)/2c the players therefore still know enough
points to interpolate the secret.
Since the coefficients are then no longer random as mentioned above,
the players must add a random sharing of zero before revealing their shares
of the product. Creating a sharing of zero could be done using the
protocol, but where each player now shares zero using a random 2τ-degree
polynomial instead of, as usual, a τ-degree polynomial. This can be re
protocol the same amount of
garded as an optimization: Due to the
communication is needed, but the communication is then no longer dependent of a and b, i.e. the required random sharing of zero could be generated
in advance.
This solution becomes even more attractive in the light of PRSS since
[13] provides a protocol based on PRSS by which the players can create a
(pseudo) random sharing of zero over a polynomial of degree 2τ without
communication.
Recall the description of PRSS from section 2.5 where T denoted the col
Section 3.2
Arithmetic Computation
33
lection of all maximal unqualified subsets of players. Non-interactive generation of a sharing of zero over a 2τ-degree polynomial assumes the pregeneration of the polynomials FT = { f T1 , f T2 , . . . , f Tτ } satisfying deg( f Ti ) ≤
2τ, f Ti (0) = 0 and j ∈ T ⇒ f Ti ( j) = 0 for all T ∈ T and i = 1, 2, . . . , τ.
For each T ∈ T the polynomials FT should be predistributed to player Pj if
j∈
/ T. The protocol also requires predistribution of τ pseudo-random functions ψ1T , ψ2T , . . . , ψTτ instead of the single pseudo-random function ψ T that
would otherwise have been distributed in the PRSS protocols described in
section 2.5. When the players wish to generate a 2τ-degree zero sharing,
each player Pj now computes his share s j as
sj =
τ
∑ ∑ ψr
T ∈T : j/
∈ T i =1
i
T
( x ) · f Ti ( j)
where x is the id of the element being shared. These shares now define the
polynomial
f0 =
τ
∑ ∑ ψr
T ∈T i =1
i
T
( x ) · f Ti ( j)
which obviously has degree 2τ and satisfies f 0 (0) = 0.
. In our implementation we have
We will call this protocol
(due to the deadline) not included the predistribution of the τ extra pseudorandom functions for each of the maximal unqualified subsets. Currently,
the players simply multiply their shares and interpolate without adding a
random 2τ-degree sharing of zero. We judged that this would not affect the
benchmarks since communication and not local computation would probably be the bottleneck. However, as explained in chapter 8 it turns out
that CPU usage becomes part of the bottleneck for 7 players. One could
therefore suspect that with the full implementation of
, the CPUbottleneck might be reached before 7 players since local computations are
increased by a factor τ. In such a case, an alternative could be to pregenerate the zero-sharings as suggested above.
3.2.3 Integer Arithmetics
Integers in the range 0, 1, . . . , p − 1 are naturally represented in the finite
field Z p . As long as overflow in Z p does not occur, the protocols for secret
sharing, adding, multiplying, etc. presented in this chapter then automatically becomes protocols for sharing integers, adding integers, etc.
As we will see later, several protocols such as e.g.
and
require p to be even larger in order to provide appropriate security.
34
Basic Protocols
Chapter 3
Signed Integers
We will sometimes need to work with signed integers rather than the integers from 0 to p. This will prove useful when we shall later deal with
additive sharings over the integers as well as in our protocols for integer
division. As described by Algesheimer, Camenish, and Shoup [1] this can
be done by viewing Z p as centered around zero, i.e. by using the rem operator defined by
c rem p = c − dc/pc p
instead of the usual mod operator (modular reduction). The isometry between the usual Z p and the signed integers then becomes as shown in table
3.1.
unsigned
signed
0
1
···
b p/2c − 1
b p/2c
0
1
···
b p/2c − 1
b p/2c
b p/2c + 1
b p/2c + 2
b p/2c + 2
···
p−1
−b p/2c
1 − b p/2c
2 − b p/2c
···
−1
Table 3.1: Isometry in Z p between unsigned and signed integers.
In order to convert from unsigned to signed integers we subtract p from
the value x ∈ Z p if x > b p/2c. Conversion the other way around is done
by adding p if x < 0.
3.3 Conversion of Sharing Schemes
We will later see that it is sometimes beneficial to share a secret using one
secret sharing scheme and then later convert the sharing to another sharing
scheme. In this section we describe some protocols for converting between
additive and polynomial sharings over a field F. We will also describe
protocols for conversion between sharings over Z p and sharings over the
integers.
The overall purpose of the conversion protocols is to allow conversion
from polynomial shares over a field Z p to additive shares over the integers
and vice versa.
Section 3.3
Conversion of Sharing Schemes 35
The protocols for conversion between polynomial and additive sharings over a finite field were first introduced by Frankel, Gemmel, MacKenzie, and Young [17], but our notation is adopted from [1, 2]. The protocol
for converting from additive sharings over Z p to additive sharings over
the integers were first introduced by Algesheimer, Camenish, and Shoup
[1]. We will only describe the basic ideas of these protocols. For complete
proofs of security we refer the reader to the above articles.
3.3.1 Converting Polynomial and Additive Sharings
Transforming a polynomial sharing of a secret s ∈ F into an additive sharing of the same secret s over the same finite field F is done by a protocol
. The players first create additive sharings of their polynomial shares
of the secret s using the
protocol. Then each player Pj interpolates the
received additive shares by means of the Lagrange coefficients mentioned
in section 2.3.1 on page 18.
follows trivially from the simulation of the protocol
Simulation of
presented above and the fact that local operations involving no communication are easy to simulate.
Conversion the other way around,
, works in a similar way, but instead of each player creating an additive sharing, he now creates a poly
nomial sharing of his share using
. Next, the players sum up the shares
they have received from the other players instead of interpolating. In this
way they reach a polynomial sharing of the original secret. Again, simula
tion follows easily from the simulation of the
and the fact that no other
information is sent between the players.
3.3.2 Converting Additive Sharings over Z and Z p
We have until now used h ai F to denote an additive sharing over a finite
field F. In the following we will also let h ai Z denote an additive sharing
over the integers as described in section 2.3.2.
The simplest of the protocols is the protocol
for converting an
additive sharing hsiZ over the integers of a secret s to an additive sharing
hsiZ p over Z p . Each player simply computes his share by reducing his
additive share over Z modulo p. Simulation is trivial in this case since the
protocol is non-interactive.
Conversion the other way around,
, i.e. converting from an additive sharing over Z p to an additive sharing over Z is more involved. The
main problem with this kind of conversion is that we cannot simply consider the additive shares over Z p as additive shares over Z: The resulting
secret will be off by an unknown multiple of p, the multiple being the quotient q of the sum of these shares and p.
36
Basic Protocols
Chapter 3
The idea from [1] is the following: Suppose the secret is sufficiently
smaller than p, i.e. ρ bits smaller where ρ is the security parameter: It is
shown in [1] that the players can then reveal the high-order bits of their
shares without compromising secrecy of the element to convert. It is furthermore shown that knowledge of these top bits is enough in order for the
players to compute q and adjust the resulting sharing accordingly.
Z
Concretely, let hvi j p ∈ Z p be the share of v ∈ Z p that player Pj holds
and suppose
−2n −1 < v =
k
∑ hvii
i =1
Zp
rem p < 2n−1
for some n ∈ N. If p > 2ρ+n+log k+4 the players can securely convert their
additive shares over Z p into additive shares over the integers by first com-
puting a j = (hvi j p /2t ), where t = ρ + n + 2, and then revealing a j
to all other parties. Then, the players should each locally compute their
additive share of v over the integers as
Z

h v iZ

j − p if l > 0, j ≤ | l |

h v iZ
h v iZ
j + p if l < 0, j ≤ | l |
j =


Z
hvi j
otherwise
where l = d(2t ∑ j a j )/pc.
In [2, 1] a random sharing h0i Z is added to the result. This is done because the resulting shares of v would otherwise not be random. Thus, without the addition of a random zero-sharing, opening of the sharing would
leak information and cause simulation to fail. In our case, however, we
as a subprotocol and we furthermore know for cerwill only use
tain that the shares will be randomized. Therefore, we do not need to add
the random sharing of zero. As will be seen later, we only use
as
a subprotocol in protocols
and
, described in section
6.1 and 7.3.2, respectively. In both cases we will argue that the converted
sharing will be randomized by other means.
3.4 Concurrent Basic Protocols
As argued in section 2.2.2, rounds are expensive and our solutions involving communication will therefore often benefit from parallel composition
of protocols. For this reason we here introduce protocols which can carry
out several independent basic operations in parallel.
Suppose that a player wishes to create Shamir sharings of n secrets
a1 , a2 , . . . , an that he knows. Instead of running
n times sequentially, he
could send all the necessary information to the other players in the same
Section 3.5
37
Complexity
round. This would still be straightforward to simulate in the ideal world
since the n shares that reach a corrupt player are computed independently.
This idea immediately carries over to other basic operations such as
and we will denote such parallel protocols by e.g.
,
, etc.
Introducing
etc. is done because later protocols will then be se quential compositions of subprotocols, including e.g. the
subprotocol. This makes later arguments for composition of partial simulations
easier to inspect.
3.5 Complexity
Let F be the finite field that we use for our computations. From section 2.3.1
we know that F must contain at least one unique non-zero element for each
player, hence |F| ∈ Ω(k). Also, when using F for representing integers of
bit length n, we have |F| ∈ Ω(2 n ).
3.5.1 Rounds and Communication
Some protocols presented in this chapter such as
and
require no
communication at all. The remaining protocols clearly all have round complexity Θ(1), i.e. a constant number of rounds.
Regarding communication complexity, we note that
and
require
one of the players to send shares to all players. This yields a communication
complexity of Θ(log |F|), remembering that we count the average amount
and
of bits sent from each player during a protocol execution. The
protocols require Θ(k log |F|) bits of communication since each player now
must share an element.
is non-interactive whereas
and
each reThe protocol
quire Θ(k log |F|) bits of communication. The
protocol only works
with F = Z p for some prime p. Since we skip the creation and addition
of a random additive sharing of zero, each player only needs to broadcast
trunc(hci I /2t ), i.e. the top O(log p − t) = O(log p − n − ρ) bits when converting −2n−1 < c < 2n−1 . However, the protocol also imposes log p ∈
Ω(ρ + n + log k). So, if we regard
as a stand-alone protocol and
choose p minimal, it requires Θ(k log k) bits of communication. For fields
of larger size, we can only say that it is Ω(k log k) due to the constraint on
p.
3.5.2 Computational Complexity
The protocols
,
,
, and
consist of a fixed number of addi
tions and multiplications per player. In
one player evaluates k τ-degree
38
Basic Protocols
Chapter 3
polynomials each taking τ multiplications 1 . Since τ ≤ b(k − 1)/2c we have
τ ∈ O(k) and the sharing player therefore carries out O(k 2 ) multiplications
requires O(k) multiplications. This is also the case for
in F. Hence,
where each player interpolates the secret. The
and
protocols consist
of each player sharing a secret via
. This is then followed by k additions
in the case of
and τ additions and multiplications in
. Therefore,
they both require O(k2 ) multiplications in F.
Regarding the conversion protocols, we note that in
each player
runs
followed by joint interpolation; this takes O(k) multiplications.
On the other hand, each player runs
in
which results in O(k 2 )
multiplications.
consists of a single modular reduction while
requires each player to add k integers that are less than the field elements.
This is clearly upper-bounded by O(k) multiplications in F.
,
, etc. where, say, m operaFinally, the parallel protocols
tions is done in parallel of course have same computational complexity as
m times the basic protocols from which they are derived.
3.6 Summary
In this chapter we have introduced various protocols for basic management
of sharings, arithmetic operations on sharings, and for converting between
different sharing schemes.
1 Using Cramer’s Rule e.g. only 4 multiplications are needed in order to evaluate a polynomial of degree 4, such as 5x 4 + 3x3 + 7x2 + 2x + 9 = ((((5x + 3) x + 7) x + 2) x + 9.
Chapter 4
Bit Representation
The aim of this chapter is to describe how single bits are represented in a
secure context as well as to provide some basic protocols for securely manipulating such bits. The ideas and protocols in this chapter are essentially
the current solutions applied in the SCET research project [7, 36, 31]. Such
management of bits turns out to be necessary for some of our integer protocols.
4.1 Logical Bit Operations
The basic observation here is that a bit value can be represented as a polynomial sharing of either the additive or the multiplicative identity in any
finite field F, i.e. as one of the elements 0, 1 ∈ F. This immediately leads
to protocols for performing the basic logical bit operations , , ,
and and
that were previ based on the arithmetical protocols
ously described in section 3.2. That is, the basic logical operations can be
implemented as suggested by table 4.1. Security of such protocols then
follows immediately from the the security of the underlying protocols for
arithmetic operations. E.g. in the case of the simulation will be a com
,
, and
. That is, the protocols
position of partial simulations for
for producing ab, a + b, −2ab, and finally a + b − 2ab.
operation
symbol
arithmetic implementation
a∧b
a∨b
¬a
a⊕b
ab
a + b − ab
1−a
a + b − 2ab
Table 4.1: Implementation of logical operations.
40
Bit Representation
Chapter 4
4.1.1 Bits as Elements in Z p
Based on the above, a solution would be to simply represent the bits as
elements in the same field Z p as the one that will be used for the main
computations on the integers. However, the prime p is supposed to be
chosen large enough to allow for computation on integers of a substantial
size; so this solution will most likely introduce too much overhead due
to the computation on, and the communication with, the large bits in Z p
representation.
The above problem can be remedied by using a field Z q for a much
smaller prime q as long as this field is large enough to allow for each player
to be associated with a unique non-zero element. (Otherwise, the polynomial secret sharing scheme breaks, see section 2.3.1.) As many applications
require only a relatively small number of players, this solution is probably
preferable. This solution is proposed in [1] along with protocols for converting bits between Z p and Zq representations for different primes p and
q.
In general, introducing a bit representation different from the one first
described here, i.e. the Z p representation, also introduces the need for conversion protocols: Most protocols that compute on bit sharings are likely to
finally require the bits in the same representation as the integers, anyway.
As an example, this is the case if bits are to be converted back to an integer
protocol described in section 7.3.1.
sharing such as in the
4.1.2 Bits as Elements in GF(28 )
A different approach is to use the field GF(2 8 ). This field contains only
28 = 256 elements and hence has the same performance benefits as Z q
for small q. Moreover, this size suggests that bits be managed as single
bytes inside the computer. This is likely to yield good performance on most
architectures.
An additional reason for choosing GF(2 8 ) in preference to GF(2m ) for
other values of m is that multiplication in this field – which is normally not
implemented in hardware – can be implemented as table look-up without
demanding too much memory.
Finally, it is noted that GF(28 ) is a field of characteristic 2. The implementation in table 4.1 therefore reduces to a ⊕ b = a + b since 2 = 0
in such a field. Since addition is non-interactive this results in being
non-interactive too, which will certainly prove useful in later protocols. For
these reasons we have chosen GF(28 ) as our primary field for representing
bits.
It is important to keep in mind that with this solution, we cannot deal
with more than 255 players, cf. section 2.3.1. However, this will be enough
for many practical purposes. Furthermore, as have been argued above, our
A Generic Approach to Bit Representation 41
Section 4.3
protocols could be based on Z q for a small prime q, thus allowing more
than 255 players at the price of xor requiring communication.
4.1.3 Complexity
When using Z p to represent bits we have a round complexity of O(1) and
communication complexity of O(k log p) for the protocols
,
and
implementing the , and functionalities mentioned above. The
operation can be implemented without communication.
The choice of GF(28 ) causes our complexity analysis to be slightly inconsistent. That is, since the use of GF(2 8 ) imposes the limit k < 256 we
have k ∈ Θ(1), strictly speaking. Regarding k as a constant will, though,
lead to complexities which are not very expressive. This is due to the fact
that the actual number of players greatly affect the execution time (see
chapter 8). Therefore, we will take the liberty to regard k as a free parameter
in our analysis while still saying that |GF(2 8 )| ∈ Θ(1).
and are
When using GF(28 ) to represent bits, the protocols for and , we have a round
non-interactive. For the remaining protocols,
complexity of O(1) and communication complexity ∈ O(k).
Regarding computational complexity, the logical operations
,
,
etc. are all build on a constant number of calls to the addition and multiplication protocols and are hence bound by O(k 2 ) multiplications in F.
4.2 A Generic Approach to Bit Representation
Resembling the notation of [36] we will in the following sometimes write
[ a] I instead of [ a]Z p to stress that we use Z p for representing integers. Concerning bits, it should be noted that the protocols for bit computation described in this report will also work with other bit representations than
GF(28 ), since each protocol treats the bit sharings in a “black box” manner.
That is, as long as we have secure protocols for basic operations such as
,
, and logical bit operations, another bit representation can easily
be “plugged into” our scenario.
As a consequence, we will sometimes in subsequent chapters refer to
the bit representation in a generic manner by denoting, say, a Shamir bit
8
sharing of a bit b by [b] B meaning e.g. [b]GF(2 ) . Furthermore, protocols are
in subsequent chapters are referred to as e.g.
,
, and
.
Such names then cover the concrete implementations ,
, and
, respectively.
42
Bit Representation
Chapter 4
4.3 Basic Binary Protocols
As mentioned, we have in our implementation chosen GF(2 8 ) as the primary field for management of bits. We will, however, sometimes still need
to represent bits in Z p . In this section we present some basic protocols for
managing bits in these two representations. They will, together with the
logical bit protocols from the previous section, constitute a basic toolkit for
manipulating individual bits. We first describe the protocols with focus on
correctness. Section 4.3.4 and 4.3.5 then covers security and complexity.
4.3.1 Generating Random Bits
We here discuss how to construct a protocol for generating a Shamir sharing of a random bit.
If the underlying field has characteristic 2 the players can each run one
, resulting in sharings of random elements r 1 , r2 , . . . , rk ∈ {0, 1}. They
k − 1 times in order to compute the sum. This works since
can then run
addition is equivalent to in such a field. The result is easily seen to be
random if at least one of the players is honest. This protocol will be named
.
In case the underlying field characteristic differs from 2, as is the case
with Z p , one could still use this technique, but then has to be implemented as suggested in table 4.1 above. The is then no longer for free.
This probably makes the solution too inefficient. Therefore, we present another technique from [36, 16] for generating a random bit in Z p . This pro and requires that p mod 4 = 3. In order
tocol will be called
I
to compute [b] for a random b ∈ {0, 1} ⊆ I the players engage in the
protocol, obtaining a share [r ] I for a uniformly random r ∈ I. Then [r 2 ] I
from section 3.2.2. If r 2 = 0
is computed and opened, e.g. using
the protocol
√ starts over, otherwise each player locally computes the square
root x = r2 . Since p mod 4 = 3 we have that ( p√+ 1)/4 is an integer. This
allows us to implement the square root function · as (·)( p+1)/4 in Z p since
(y2 )( p+1)/4 = y( p+1)/2 = y1+( p−1)/2 = y · y( p−1)/2 = ±y
for any y ∈ Z p . This yields x = ±r without the players knowing which is
the case1 . The players then compute
[b̃ ] I ← x −1 [r ] I
which results in a sharing that is either [−1] I or [1] I . From this they locally
compute [b] I = (1 − [b̃ ] I )2−1 which is a sharing of either 0 or 1.
1 It
can be shown that y ( p−1)/2 = 1 if y is a square in Z p and y = −1 otherwise.
Basic Binary Protocols 43
Section 4.3
4.3.2 Xoring Multiple Bits
Many of our protocols involve ’ing bits. This can be done by the arithmetic implementation in table 4.1. However, for bits in Z p this involves
communication between the players that is linear in the number of bits to
be ’ed.
If the result of the ’ing is immediately to be opened we can apply
an optimized protocol,
[36]. This is actually the case in the
next chapter where protocols for converting bits are described. Suppose
we wish to and thereafter open the bits [b i ] I for i = 1, 2, . . . , n. The idea
is simply to compute the sum
[ s ] I = [ b1 ] I + [ b2 ] I + · · · + [ b n ] I .
The least significant bit of the sum will then contain the answer.
Unfortunately, the rest of the bits in [s] I will contain additional information about the ’ed values – information that must not be leaked. This is
prevented by masking the sum s with a random even integer r, i.e. opening
only r + s. If s < 2l and r is an m-bit integer such that 2 m + 2l < p then overflow in the field is prevented and the probability of information leakage is
less than 2−(m−l ) . We will later describe how this enables simulation.
A random even r can be computed by having each player share an even
and then jointly compute
m-bit value r i using
[r ] I = [r1 ] I + [r2 ] I + · · · + [r k ] I .
This will, however, result in r potentially being an m + blog kc bit integer.
But as long as no overflow in Z p occur, this works since the m least significant bits in r is still uniformly distributed.
4.3.3 Converting Bits
Here follows protocols for conversion between bit representations in Z p
and GF(28 ) where p can be any prime number.
A protocol
that converts a sharing of a bit [b] I to [b] B is obtained as
follows: Each player P j picks a random bit b j and executes both SSP( j, b j )
and
( j, b j ), which are described in section 3.1.1, for both b j ∈ I and
b j ∈ B in order to create [b j ] I and [b j ] B for j = 1, 2, . . . , k. Then the players
jointly compute
[b̃ ] I ← [b] I ⊕ [b1 ] I ⊕ [b2 ] I ⊕ · · · ⊕ [bk ] I
and open the result, thus obtaining the bit b̃. The bit is obviously uniformly
distributed if at least one of the players is behaving honestly which is the
case in our security model. Finally, the result is computed as
[b] B ← b̃ ⊕ [b1 ] B ⊕ [b2 ] B ⊕ · · · ⊕ [bk ] B .
44
Bit Representation
Chapter 4
Correctness of
follows from the commutative and associative properties of ⊕ combined with the fact that b ⊕ b = false for any bit b.
, by simply doing the
We could construct the opposite protocol,
B
same in reverse order, i.e. given [b] , the players first compute and open
[b̃ ] B = [b] B ⊕ [b1 ] B ⊕ [b2 ] B ⊕ · · · ⊕ [bk ] B
and then compute
[b] I ← b̃ ⊕ [b1 ] I ⊕ [b2 ] I ⊕ · · · ⊕ [bk ] I .
protocol
Note, however, that in this case we cannot use the
from the previous section and we thus end up with a protocol requiring k
rounds.
Instead, we construct a constant round protocol as follows: First the
players generate two sharings [r ] I and [r ] B of the same random bit r. This is
followed by
. The players then compute and
done using
B
B
B
open [u] ← [r ] ⊕ [b] such that each player learns u = r ⊕ b. Next, the
players jointly compute
[v] I ← (1 − 2u)[r ] I + u
One can verify correctness by noting that v = (1 − 2(r ⊕ b))r + (r ⊕ b) = b
in both cases r = 0 and r = 1.
Note, that parallel protocols
and
follows immediately in
follows from
.
the same way as e.g.
4.3.4 Security
In this chapter we have described protocols for some basic operations on
secretly shared bits. As explained in chapter 2, we must keep in mind that
we are constructing subprotocols that are intended to securely realize more
complex ideal functionalities that will be introduced later.
Aside from the correctness argued above, we must therefore also ensure
privacy, i.e. that any information revealed by at least b k+2 1 c arbitrary honest
players to the corresponding b k−2 1 c corrupt players during protocol execution can be simulated by an ideal-world adversary without knowledge of
the private information of the honest players. This is the case for the pro tocols in this chapter except
and
since 1) we know from
chapter 3 that the subprotocols used here, such as e.g.
used for imple menting e.g.
, are correct and can be simulated in such a way and 2)
only uniformly distributed elements are revealed.
, 2) above is not completely true. In this case,
In the case of
we will instead aim for statistical security, i.e. arguing that the probability
of information leakage from the honest players (and hence the impossibility
Basic Binary Protocols 45
Section 4.3
to simulate the real-world scenario) is exponentially small in the security
parameter ρ.
More specifically, the problem is the opening of r + s: As r is known to
be, say, an m-bit value, a real-world adversary A will gain some knowledge
of s if the
of r + s results in the corrupt players holding an m + 1
bit integer. That is, an adversary A simply outputting the (m + 1)’th bit
would be impossible to simulate perfectly by an ideal-world adversary S
having no knowledge at all about s. However, by choosing m and l such
that m − l > ρ where ρ is the security parameter, S can simply feed the realworld adversary with a uniformly random m-bit input r 0 instead of r + s.
This works because, in the worst case where s = 2 l − 1 since the (m + 1)’th
bit of r + s will then only be 1 with probability 1/2 ρ . This makes the output
distributions of A receiving r + s in the real world and given r 0 in the ideal
world by the simulator statistically indistinguishable.
is established, security of
follows since
Once security of
its subprotocols are secure and because the only information revealed during execution is the uniformly distributed r ⊕ b which can easily be simulated.
4.3.5 Complexity
Rounds and Communication
with the
protocol, we clearly end up
When implementing
with all protocols presented here having round complexity O(1).
Since |GF(28 )| ∈ O(1),
has a communication complexity
∈ O(k). The most dominant subprotocols of
are
and
resulting in a communication complexity of O(k log p). Strictly speaking,
is probabilistic since it starts over if r = 0.
the complexity of
This only happens with probability 1/p yielding an expected number of
rounds which is Θ( p/( p − 1)). Since p will be large in applications, this
is so close to one that we will regard it as deterministic Θ(1). Something
similar applies to communication complexity.
We now consider communication complexity of
for xor’ing
n bits. The complexity is dominated by the execution of
by which
each player secretly shares a random even integer in Z p and the final
.
Both protocols have complexity Θ(k log p). In order to xor n bits with security parameter ρ we have from the above discussion of security that p >
n + 2ρ must hold and therefore, remembering that p > k is also necessary,
we end up with a communication complexity of Θ(k log (max{k, n + 2 ρ })).
In
each player first secretly shares two bits via the
protocol.
This is followed by a joint execution of the
for xor’ing k + 1 bits.
Therefore, we must ensure that p > (k + 1) + 2 ρ , which gives a communi cation complexity ∈ Θ(k log(k + 2 ρ )). The
protocol consists of gener
46
Bit Representation
Chapter 4
ating a random bit in Z p and converting it to GF(28 ) followed by an
and some addition and multiplication of constants. This is dominated by
and hence
has also communication complexity ∈ Θ(k log (k + 2 ρ )).
Computational Complexity
In
each player shares a bit resulting in O(k 2 ) multiplications
in B, i.e. the field for bits. The
protocol relies on a constant
number of calls to
,
and hence requires O(k 2 ) multiplications in I.
Xor’ing n bits with
requires each player to run
followed by
2
k additions and an
. This yields O(k ) multiplications and Θ(n) addi tions in I. Since only k bits are xor’ed with
in
, this protocol
2
takes O(k ) multiplications in I. The
is dominated by
and
and therefore also takes O(k 2 ) multiplications in I.
4.4 Summary
In this chapter we have discussed how bits are most efficiently represented
in the context of secure multi-party computation, and we have described
protocols for basic management of bits that will later be part of our more
complex protocols.
Chapter 5
Binary Addition
In this chapter we consider different ways of constructing a protocol for
binary addition. That is, protocols taking as input the bit sharings of two
integers and producing as output a bit sharing of their sum. We will refer
. More specifically, suppose that we have bit
to such a protocol as
sharings of two n-bit integers a and b, i.e. sharings [ a n ] B , [ an−1 ] B , . . . , [ a1 ] B
and [bn ] B , [bn−1 ] B , . . . , [ a1 ] B where
a=
n
∑ a i 2i −1
i =1
and
b=
n
∑ bi 2i −1
i =1
and that we wish to compute an n-bit sharing of the sum s = a + b, that is,
sharings [s n ] B , [sn−1 ] B , . . . , [s1 ] B such that
s=
n
∑ s i 2i −1 .
i =1
In subsequent chapters such a protocol will serve as a building block in
more advanced protocols. We will first present two solutions while arguing
for their correctness. Privacy, and thus security, will be treated at the end
of the chapter.
5.1 Ripple-Carry Addition
Here, we present an iterative solution to the above problem of binary addition which requires a linear number of rounds in the bit size n. The idea is
basically to let the players evaluate an arithmetic version of a ripple-carry
addition circuit. Such a circuit consists of a sequential aggregation of small
fixed-size circuits called full-adders (see e.g. [38] section 3.1 or [22] appendix
A.2). Each adder is responsible for the addition of two single bits and produces as output a sum bit and a carry bit which then propagate into the
next adder as illustrated in figure 5.1(b).
48
Binary Addition
Chapter 5
(a) A full-adder.
(b) 4-bit ripple-carry addition.
Figure 5.1: A full-adder and a complete 4-bit ripple circuit.
The full-adder circuit in figure 5.1(a) is a logical circuit. However, it is easily
converted to an arithmetic circuit using the following arithmetic implementation of the full-adder
s = a ⊕ b ⊕ cin ∼ a + b + cin − 2( ab + acin + bcin − abcin )
cout = (( a ⊕ b) ∧ cin ) ⊕ ( a ∧ b) ∼ ab + ac in + bcin − 2abcin
which can be verified to yield the correct truth tables.
Concerning the complexity of this solution, we note that it depends on
the underlying bit representation. Using e.g. Z p , each full-adder requires
4 multiplications and 2 rounds. Since the first adder must finish before
the next is evaluated, this results in the n-bit ripple-carry circuit taking 4n
multiplications and 2n rounds. However, as we are using GF(2 8 ) with characteristic 2 we get that
s ∼ a + b + cin
and
cout ∼ ab + cin ( a + b)
and thus we only need a total of 2n multiplications in n rounds. In both
cases, round complexity is Θ(n) and the communication complexity be ,
, etc. are build on a concomes Θ(kn). Since the logical operations
stant number of calls to
, the computational complexity is easily seen
to be O(nk2 ) multiplications in GF(28 ). Two small optimizations are possible in that the first carry bit is always zero and thus need not be secretly
shared. Also, we are not interested in computing the n-th carry-out. These
optimizations will, however, not affect the asymptotic complexity.
5.2 Addition Using Parallel Prefix Computation
From the design of computer hardware several alternatives to ripple-carry
circuits are known, all providing sub-linear circuit depth at the price of
Section 5.2
Addition Using Parallel Prefix Computation
49
increased circuit size, see e.g. [38, 22]. Such solutions are also interesting
in our context since the experiments in chapter 8 suggest that rounds are
relatively expensive.
We have spend considerable time designing and implementing a protocol for one such solution, namely the carry look-ahead circuit. Our solution was originally based on typical descriptions found in books about
computer arithmetics [38, 22] and took O(log n) rounds and O(n 2 ) multiplications. Unfortunately, these descriptions focused on circuit depth and
and not circuit size. It was not until relatively late in the progress of this
thesis that we became aware of a log-round solution taking only O(n) multiplications. This approach combines parallel prefix computation [27] and
techniques from [16, 36] for computing a single bit in a sum of two binary
sharings. It can be seen as a more efficient (and less obvious) way of doing carry look-ahead and has now been implemented (and the old solution
discarded). This section describes the log-round solution.
5.2.1 Computing a Single Bit in a Sum
We first present a protocol from [16, 36] for computing a single bit in a sum.
More precisely, suppose we are given as input bit sharings of two n-bit
integers a = ( a n , an−1 , . . . , a1 )2 and b = (bn , bn−1 , . . . , b1 )2 and that we want
to compute a sharing of the m’th bit of the sum s = a + b, i.e. s m for some
1 ≤ m ≤ n. From the above discussion of ripple-carry addition we know
that the m’th bit in the sum is given by
s m = a m ⊕ bm ⊕ c m
where c1 = 0 and cm+1 = majority( a m , bm , cm ) for m = 2, 3, . . . , n. So the
problem reduces to computing a sharing of the m-th carry bit followed by
in order to find s m . Now, define d i = ai ⊕ bi and
two executions of
consider the list of pairs
d
d1
d0
··· m
bm
b1
b0
where d0 = b0 = 0 by convention. Observe, that d i = 1 means that a i 6= bi
and hence a potential carry bit in the addition a + b will propagate from the
(i − 1)’th to the i’th position, i.e. c i = ci−1 . On the other hand, when d i = 0,
that is, a i = bi , the carry c i is generated, i.e. either explicitly set or cleared
at the i’th position.
It therefore follows that the m’th carry bit in the addition a + b corresponds to bi where di = 0 and 0 ≤ i ≤ m is maximal. Put in other words,
all carry bits to the left of the leftmost generated carry bit have necessarily been propagated and are therefore identical to that leftmost generated
50
Binary Addition
Chapter 5
carry bit. This allows us to compute the m’th carry bit c m as
d0
d1
dm
←
···
cm
b0
b1
bm
where the -operator is defined by
x
0
0
=
and
X
Y
Y
x
1
x
=
.
X
Y
X
The -operator essentially discards its right or left operand when the right
top bit is 1 or 0, respectively. This corresponds to the propagate and generate situations mentioned above. The actual computation is done with the
logical implementation of the operator given by
x
y
x∧y
=
,
X
Y
(y ∧ ( X ⊕ Y )) ⊕ Y
which is easily converted to arithmetic operations using table 4.1 on page
39. Since a field of characteristic 2 is used for representing the bits, ⊕ requires no communication and one then only costs two parallel multiplications. It can be verified that the -operator is associative, i.e. ( A B) C =
A ( B C ) for all possible pairs A, B, and C. The carry bit and hence the
desired bit of the sum can thus be computed in dlog me ∈ Θ(log m) rounds
using 2m ∈ Θ(m) multiplications; this yields a communication complexity of Θ(km) bits. Computational complexity is Θ(m) multiplications in
GF(28 ).
5.2.2 Parallel Prefix Computation
The next step is a protocol that obtains not just the m-th but all the bits in
a sum of two bit sharings of n-bit integers. One could of course apply the
above protocol n times in parallel which would result in 2 + 4 + 6 + · · · +
2n ∈ Θ(n2 ) multiplications. Here, we show how to improve this. From the
previous section it should be clear that computing all the necessary carry
bits of our sum means computing the prefix “sums” given by
d
m
i =0 i
bi
for m = 0, 1, . . . , n. A second approach could thus be to compute these
prefix sums by successively applying the operator in a linear fashion. In
fact this is just ripple-carry addition in disguise, yielding the same number
of rounds and multiplications.
Now, since the -operator is associative, we can apply the prefix sum
technique from [27], which utilizes the associative property of a binary operator in order to compute prefix sums in fewer rounds. For the sake of clarity we first analyze the PrefixSum Algorithm (see Algorithm 1 on page 52)
Section 5.2
Addition Using Parallel Prefix Computation
51
assuming that the length n of the input vector is a power of 2. This prefix
algorithm is adapted from [35].
Property 5.1. Let A be the original vector of -operands and let A[i ] denote the
i’th component of this vector. Then the PrefixSum Algorithm 1 correctly computes
the prefix vector
B = ( A[0], A[0] A[1], . . . , A[0] A[1] · · · A[n]) .
Proof. The correctness of Algorithm 1 follows from the observation that
when the recursive call returns in line 6, we have
D[ s ] =
2s
∑ A[i ]
i =1
for 1 ≤ s ≤ n/2.
Property 5.2. For a given input n, the PrefixSum Algorithm 1 terminates after
1 + log n recursive calls (including the first call) and requires a total of 2n −
log(n) − 2 -operations.
Proof. The number of recursive calls is easily seen to be given by the recurrence
R (1) = 1
R(n) = 1 + R(n/2)
which has the solution R(n) = 1 + log n. Since a call to PrefixSum with
input n involves n − 1 -operations ignoring the recursive call, we end up
with a total of
(n − 1) + (n/2 − 1) + (n/4 − 1) + · · · + (2 − 1) =
(n + n/2 + n/4 + · · · + 2) − log n =
2n − 2 − log n
-operations.
The algorithm is easily modified to handle cases where n is not a power of 2.
In such a case the algorithm should at each recursive level check whether
2|n. If yes, proceed as normal. Otherwise, compute the prefix sums of
A[1], A[2], . . . , A[n − 1] as usual and finally apply the -operator in order
to obtain the last prefix sum ( A[1] A[2] · · · A[n − 1]) A[n]. This clearly
does not affect the number of diamond operations which is still n − 1 at
each recursive level. The number of recursions is now given by
R (1) = 1
R(n) = 1 + R(bn/2c)
52
Binary Addition
Chapter 5
which is still O(log n).
From the above discussion it follows that the round and communication
complexity of the prefix approach for binary addition is Θ(log n) rounds
and O(kn) bits, respectively. As for the linear ripple-carry approach, the
computational complexity is O(nk 2 ) operations in GF(28 ).
Algorithm 1 PrefixSum(A, n)
Require: n = 2s for some s ∈ N
1: B[1] ← A[1]
2: if n > 1 then
3:
for i = 1 to n/2 do
4:
C[i ] ← A[2i − 1] A[2i ]
5:
end for
6:
D ← PrefixSum(C, n/2)
7:
for i = 1 to n/2 do
8:
B[2i ] ← D[i ]
9:
end for
10:
for i = 2 to n/2 do
11:
B[2i − 1] ← D[i − 1] A[2i − 1]
12:
end for
13: end if
14: return B
5.3 Security
In the discussion above we have argued for correctness of the protocols.
Since we will later use the protocols as subprotocols in other protocols that
is to be proved secure, we must also argue that a simulator will be able to
produce the input that a real-world adversary would expect to see during
protocol execution. Simulation is, however, straightforward in this case,
since the
protocols rely only on sequential calls to protocols from
chapter 3 which we already know how to simulate.
5.4 Summary
In this chapter we have introduced two different protocols for binary ad
dition. We will later refer to those as
and
,
respectively. The difference of these protocols reflects the basic trade off between the number of required rounds and size of communication that often
comes up when designing secure protocols. We have seen a linear round
protocol with only little communication and a logarithmic round protocol
with twice as much communication. For a comparison of ripple-carry and
Section 5.4
Summary
53
prefix addition based on experiments with a prototype, we refer the reader
to chapter 8.
Chapter 6
Splitting an Integer Into Bits
In this chapter we consider two different protocols for splitting a shared
integer into polynomial sharings of its individual bits. Unlike the protocols in the previous chapter, the protocols here start out with sharings of
integers rather than sharings of the individual bits of integers.
6.1 A First Approach (I2QBIT)
Our first solution was originally proposed in [1], where the corresponding
and takes as input an additive sharing h ai Z over
protocol is named
the integers of the integer to split. More precisely, suppose that h ai Z is an
additive sharing of an n-bit integer a = ( a n , an−1 , . . . , a1 )2 to be split. As
this is an additive sharing, each player Pj holds a share a j := h aiZ
j such that
a = ∑ki=1 a j .
protocol is to have each player Pi first produce
The idea of the
polynomial sharings of the individual bits in his private share a i using
.
This will result in a total of kn sharings, namely [ a in ] B , [ ain−1 ] B , . . . , [ a1i ] B for
each player Pi , i = 1, 2, . . . , k. For notational convenience let [[c]] denote
the bit sharing ([c n ] B , [cn−1 ] B , . . . , [c1 ] B ) for an n-bit integer c.
The players subsequently run through an evaluation of k − 1 addition
circuits using one of the protocols for binary addition from the previous
chapter, i.e. they basically execute the following steps in order to compute
the sum of all the bit sharings which results in [[c]] being the desired bit
sharing of a.
[[c]] ← [[ a1 ]]
for i = 2 to k do
[[c]] ←
([[ ai ]], [[c]])
end for
56
Splitting an Integer Into Bits
Chapter 6
We will later use this protocol to split a polynomially shared integer [ a] I
and will in such cases first have to convert [ a] I to h aiZ using first
and
then
. Because of
we then have to make sure that the additive
shares obtained are re-randomized. This is clearly the case here as each bit
of each additive share is reshared.
6.1.1 Parallelizing the Protocol
The above protocol, adding together k binary numbers, one for each player,
. Here,
involves k − 1 sequential calls to, say, the subprotocol
we show how to parallelize the protocol based on a known technique for
reducing addition of k integers to addition of 2 integers, thus obtaining a
protocol which does the same job in fewer rounds. The technique was first
introduced by Wallace [37] and is based on carry save adders circuits that
can reduce addition of three n-bit integers to addition of two n-bit integers.
Consider addition of three n-bit integers
a = ( a n , a n −1 , . . . , a 1 )2
b = ( b n , b n − 1 , . . . , b1 ) 2
c = ( c n , c n −1 , . . . , c 1 )2 .
The idea relies on the observation that
a + b + c = ( a ⊕ b ⊕ c ) + ( d n −1 , d n −2 , . . . , d 1 , 0)2
where ⊕ means bitwise and the bit d i in the last term is the carry bit that
is produced when adding the bits a i , bi , and ci , i.e. di = majority( a i , bi , ci ).
All the bits d i can be produced in one round since d i only depends on a i ,
bi , and ci . Furthermore, we need only the same amount of multiplications,
i.e. 2(n − 1), as when doing sequential binary addition of two integers.
By this we have reduced the problem of adding three integers to the
addition of only two integers in one round and with the same amount of
communication as a usual addition. Applying this to our setting we can
now reduce the needed addition of k integers to the addition of 2 integers.
This can be done in a number of rounds r (k) expressed by the following
recurrence
r (2) = 0
r (3k + c) = 1 + r (2k + c),
c = 0, 1, 2.
with the closed-form solution satisfying r (k) = dlog 3/2 (k/2)e ∈ O(log k),
cf. [38]. This parallel process results in a so called Wallace tree, depicted in
figure 6.1 for a sample addition of 7 binary integers.
To reach the final bit sharing we have to call e.g.
for
adding up the two remaining binary numbers. This discussion leads us to
Section 6.1
A First Approach (I2QBIT)
57
Figure 6.1: A Wallace tree for reducing addition of 7 integers to addition of
2 integers in 4 rounds.
a protocol which involves Θ(log k + log n) rounds: First O(log k) rounds
for reducing binary addition of k numbers to binary addition of 2 numbers,
then O(log n) rounds for binary addition of the remaining two numbers
using the prefix addition protocol from the previous chapter.
The protocol requires each player to secretly share n bits. Reducing
from three to two numbers takes O(n) multiplications and this is done
O(k) times. This yields a communication complexity of O(nk 2 ). From
the previous chapter we know that the final binary addition has communication complexity O(nk), resulting in a total of Θ(nk 2 ) bits. The computational complexity is O(nk 3 ) multiplications in GF(28 ) since each player
invokes the
protocol O(nk) times.
6.1.2 Security
Correctness of the
protocol is argued above. Privacy follows for the
same reasons as in the previous chapters: The execution of
in the
real world can easily be simulated in the ideal world since
relies
solely on sequential invocations of subprotocols which we already know
how to simulate. Therefore, we will later be able to use the
protocol
as a subprotocol in the construction of other secure protocols.
When the protocol is used for splitting a Shamir sharing into bits, we
must as mentioned first run
and
in order to obtain an additive
sharing over the integers. Security in this case is maintained since the non
random output shares from
(where we skipped the addition of a
random sharing of zero) are randomized during the
protocol. The
58
Splitting an Integer Into Bits
Chapter 6
share randomization happens when each player reshares each bit in his
share using the
protocol.
6.2 An Alternative Approach (P2QBIT)
In this section we present another protocol for splitting a secretly shared
integer into sharings of its bits. This protocol is quite different from the
previous protocol,
, and is in the following referred to as
since it takes as input a polynomial sharing rather than an additive sharing
over the integers.
Some steps of this protocol were developed as part of the comparison
protocol in the SCET project [16, 36]. However, the protocol described here
builds on the prefix addition subprotocol described in section 5.2.2 instead
of – as is the case in the SCET project – the subprotocol in section 5.2.1 for
finding a single bit in a sum.
compared to
is that a considerable part of
One benefit of
is independent of the integer that is to be splitted
the work done in
and may therefore be computed in advance. We also expect performance
of
to scale better when the amount of players increase.
The protocol is designed to split the m least significant bits of an n-bit
integer [ a] I , and consists of three steps, the first being independent of the
input integer, hence called preprocessing. Here follows a description of the
three steps, preprocessing, reduction, and addition. In the following we
concentrate on correctness; we will later address the question of security.
6.2.1 Preprocessing
The purpose of the preprocessing step is, for a given M ∈ N where 2 M ≥
2m , to create a sharing [b] I of a random M-bit integer b, i.e. b satisfying
0 ≤ b < 2 M , along with bit sharings [b m ] B , [bm−1 ] B , . . . , [b1 ] B of the m least
significant bits of b. We obtain b by first sharing M uniformly random bits,
b1 , b2 , . . . , b M using the protocol
described in section 4.3.1.
Then [b] I is computed as
[b] I ←
M
∑ 2i −1 [ bi ] I .
i =1
Subsequently, the m least significant bits [b i ] I , i = 1, 2, . . . , m, are converted
to bits in GF(28 ) by means of PARI2B([b1 ] I , [b2 ] I , . . . , [bm ] I ) which is described in section 4.3.3. This takes Θ(1) rounds and Θ( Mk log p) bits of
communication with log p ∈ Ω(k + 2 ρ ) (cf. section 4.3.5).
Section 6.2
An Alternative Approach (P2QBIT)
59
An Optimization
Above, we created M bit sharings [b i ] I and converted the least significant m
of them into our bit field to obtain [b i ] B . However, as noted in [36], it is not
necessary to generate all M bits but only the m bits that are to be converted
to B. Instead, each player Pj may share an M − m integer r j and [b] I can
then be computed as
!
!
[ b ] I = 2m
k
∑ [r j ] I
j =1
m
+
∑ 2i −1 [ bi ] I
i =1
.
Here, the r = ∑ r j is not completely uniformly distributed and may potentially be an M − m + blog kc-bit integer. As long as overflow in Z p does
not occur, this will work since the least M − m significant bits will be uniformly random. This reduces the communication complexity to Θ(mk log p).
6.2.2 Reduction
The next part of the protocol basically reduces the problem of splitting m
bits of an n-bit integer a to a simpler problem. Suppose, we have t such that
2t > 2 M . Now, compute and open T = 2 t − b + a where b is the random
M-bit integer that have been preprocessed. It then holds that 2 t + a = T + b
which implies that
a = ( T mod 2n + b mod 2n ) mod 2n ,
in other words, we have reduced the problem of computing the i’th bit of
a to the problem of finding the i’th bit in the sum of the publicly known T
and the secret but random value b for which we have already computed bit
shares [bm ] B , [bm−1 ] B , . . . , [b1 ] B . This step takes Θ(1) rounds and Θ(k log p)
protocol.
bits of communication due to the
6.2.3 Addition
We can now easily create bit sharings of the m least significant bits in the
publicly known T and then apply, say, the
protocol from
chapter 5 to produce the desired bit sharing of a. From chapter 5 we know
that binary addition can be done in O(log m) rounds and O(km) bits of
communication.
Observe, that – in contrast to the final addition in
– only one
of the two numbers is secretly shared. This allows for some optimizations
in the protocols for binary addition which we will briefly discuss in the
following subsections.
60
Splitting an Integer Into Bits
Chapter 6
Ripple-Carry Addition
When GF(28 ) is used to represent bits, it is possible to implement the logic
for a full-adder using only one multiplication, and thus we can compute
in only m − 2 rounds and m − 2 multiplications. While this
is not asymptotically superior to the
with both addends
secretly shared, it still might be significant in practice.
Parallel Prefix Addition
In [31] some optimizations are described for the situation where one of the
input integers are publicly known and where just one bit from the sum is
needed, i.e. as in section 5.2.1. One of these optimizations immediately carries over to the situation where all bits of the sum are to be computed using
the prefix algorithm from section 5.2.2: Assume that b = (b m , bm−1 , . . . , b1 )2
is given as publicly known bits and a = ( a m , am−1 , . . . , a1 )2 as secret bit
sharings. This leads to a list of pairs
d0
d1
dm
···
b0
b1
bm
with the bottom row consisting of publicly known bits. (The d i ’s are defined by ai ⊕ bi as in section 5.2.2.) Now, observe that when both bottombits are known, the implementation of the -operator from 5.2.2 reduces
to
x∧y
y
x
x∧y
y
x
,
=
,
=
1
1
1
0
0
0
x
y
x∧y
=
,
1
0
y
and
x
y
x∧y
=
.
0
1
y⊕1
Using GF(28 ) this implementation requires only one multiplication (cf. table 4.1) in contrast to the two multiplications needed by the general implementation from section 5.2.2 that works for both secret and public b bits. In
this way, at least the first m − 1 applications of the -operator, i.e. in the top
level of the recursion, require only m − 1 multiplications.
The resulting bit in the bottom row remains public in two of the cases.
Therefore, we expect some public bits to propagate downwards in the recursion, though this does not happen in the worst case. In chapter 8 we
investigate how this improves performance of the protocols.
6.2.4 Security
is argued above. When
is used as a subprotoCorrectness of
col in a secure protocol, we must also argue that it is private, i.e. that we can
Section 6.3
An Alternative Approach (P2QBIT)
61
simulate the output of the real-world adversary in the ideal world. This is
straightforward in most cases since
is build from sequential calls to
subprotocols which we already know how to simulate.
In the reduction step, though, the value T = 2 t − b + a is opened. This
might contain some information about the secret a. However, if we ensure
that b is a uniform random M-bit number and a is an n-bit number such
that 2 M > 2n , we still have statistical security of the protocol. More precisely, we must choose M and n such that M − n > ρ; this ensures that the
probability that parts of a is revealed is less than 1/2 ρ . With the optimization in the preprocessing phase, b is no longer uniformly distributed, but
its least significant n bits still are, which is enough.
In order to avoid overflow during the protocol execution when splitting
integers a < 2n we must hence work with a field Z p with p > 2t , say, by
choosing p as an (n + ρ + 3)-bit prime.
6.2.5 Complexity
Rounds and Communication
Assume still that we split m bits from an n bit integer, i.e. m ≤ n. Combining the complexities for each step of the protocol, we obtain a preprocessing of Θ(1) rounds and Θ(mk log p) bits of communication. The remaining
part of the protocol – the part with execution depending on the input –
takes Θ(log m) rounds and Θ(km + k log p) bits of communication (Θ(km)
for prefix addition and Θ(k log p) due to the opening in the reduction step).
We also have from the preprocessing that log p ∈ Ω(log(m + 2 ρ )), but this
gets swallowed by the requirement log p ∈ Ω(n + ρ) imposed by the se as a
curity of the remaining steps. This means that if we consider
stand-alone protocol (and chooses p minimal) it has communication complexity Θ(mk(n + ρ)) for the preprocessing and Θ(kn + kρ) for the remaining steps. Here n is the bit size of the integer from which to split bits (not to
be confused with m which is the actual number of bits to split). When used
as a subprotocol this might be worse since stricter requirements for the size
of p may then apply.
Computational Complexity
When splitting m bits of an n bit integer and using the optimizations men and
tioned above, preprocessing consists of m calls to
taking O(mk2 ) multiplications in I. Processing involves opening an element in I followed by binary addition of m bits. This results in O(k) multiplications in I and O(mk 2 ) multiplications in B.
The reader is referred to chapter 8 for a comparison of
and
based on experiments with implementations of the protocols.
62
Splitting an Integer Into Bits
Chapter 6
6.3 A Constant Round Solution
Damgård, Fitzi, Nielsen, and Toft [16] present a protocol that goes even further and solves the problem of bit splitting in a constant number of rounds.
This protocol relies on several interesting subprotocols. Among these are
protocols invented by Bar-Ilan and Beaver [4] for inverting elements and
for generating random invertible elements and a protocol by Cramer and
Damgård [12] for doing unbounded fan-in multiplications of arbitrary field
elements. Also, it utilizes the protocols for generating random elements
and random bits that we have previously described in sections 2.5 and 4.3.1,
respectively.
The protocol in [16] provides security in a sense somewhat stricter than
the notion of security adopted elsewhere in this report, see section 2.2. In
[16] perfect privacy is obtained, meaning that no information at all is leaked
no matter how much computing power the adversary might possess. However, with probability 2 −ρ , where ρ is the security parameter, the protocol
fails to compute the desired result.
The constant round solution requires approximately 35n 0.13 ρ2 + 31n1.33 ρ
multiplications. If p is chosen as a Mersenne prime, i.e. as 2 m − 1 for some
m, a total of only 134n2/15 ρ + 54n4/3 multiplications is needed. For typical real-life parameter settings, say, five players, ρ = 30, log p ≈ 65, and
n = 32, our experiments (see chapter 8) show that multiplications in Z p
each take approximately 6.83 ms when done in parallel. Extrapolating from
this, we get that splitting a 32-bit integer into bits using the constant round
solution takes approximately 990 seconds or 80 seconds if p is a Mersenne
prime. These estimates assume that all multiplications are done in one
round. In fact, also the number of rounds needed by the constant round
and
for
solution exceeds the number of rounds required by
all reasonable parameter settings.
For these reasons we have not dealt further with this solution. The
protocol that we have presented in this chapter is, however, based
on some of the same ideas as the constant round solution, e.g. binary addi
tion, prefix computation, etc. The
protocol shows that the amount
of communication can be drastically reduced if one is willing to accept a
number of rounds that is a little more than constant, i.e. logarithmic.
6.4 Summary
In this chapter, we have devised two different protocols for splitting an integer into bits. The first protocol can be seen as resorting to the general technique of [6] for evaluating a small fixed size addition circuit. The second is
build on techniques from the SCET project combined with an algorithm for
computing prefix sums.
Section 6.4
Summary
63
The
involves more fixed overhead, but has performance that is
expected to scale better when the number of players increase and further
benefits from being partly independent from the integer to split. Finally, we
have discussed a constant round solution that, though theoretically interesting, does not seem to be efficient in practice. Again, we refer to chapter
8 for benchmark results.
Chapter 7
Integer Computation
In the previous chapters we have presented several protocols that, as mentioned, will be used as building blocks in the protocols in this chapter.
As described in section 3.2.3, the known basic protocols for addition
and multiplication are directly suited for integer computation as long as no
overflow occurs in the field Z p . In this chapter we extend the collection of
protocols for secure computation on integers.
First, we present protocols for secretly comparing two integers and extracting a specific bit from an integer. Also, protocols for performing certain
shift operations, e.g. shifting an integer up into a certain interval, are presented. These will, in addition to being stand-alone protocols, be used as
subprotocols in our further protocols for secret integer division and modular reduction.
The last two protocols, i.e. for division and modular reduction of integers, come in many variations either where all integers are secretly shared
or where some of them are public. We mainly focus on protocols dealing
with all input being secret. We will also, however, discuss protocols with
some of the input being public.
In this and the previous chapters we prove the protocols statistically secure without the PRSS technique from section 2.5. In the end of this chapter we will show how the protocols can be proved computationally secure
when they are based on the pseudo-random secret sharing technique introduced in chapter 2.
7.1 Extracting a Bit from an Integer
for extracting a bit from a shared integer follows imA protocol mediately from the protocols in the previous chapter. In order to obtain the
or the
protocol
m-th bit of an integer we can apply either the
to obtain the m least significant bits and then discard all but the requested
bit.
66
Integer Computation
Chapter 7
We note, that we can replace the subprotocol
for binary
addition (section 5.2.2) by a simpler protocol that does not compute all the
intermediate prefix “sums”, but only the complete sum. In this way, the
number of required -operations in the addition phase is halved and the
protocol thus requires roughly 2m multiplications and 2 log m rounds. We
end up with complexities for which are similar to those of
from the previous chapter. Getting the m’th bit in an n-bit integer has the
same complexity as splitting the m first bits of an n-bit integer.
Correctness follows immediately from the correctness of the
protocol and the correctness of the -operand (see section 5.2.2) and privacy is also immediate since the protocol is a sequential composition of
protocols (e.g.
,
, etc.) which are already known to be private.
7.2 Comparison
We now consider the protocol for integer comparison that originates from
the SCET research project, see Toft [36]. Given integer sharings [ a] I and [b] I
we wish to compute a sharing of a bit [c] B such that c = 1 if a ≥ b and c = 0
otherwise.
Given a protocol as the above that securely extracts a bit from an integer,
comparison follows quite easily. Suppose we have a public integer n such
that 0 ≤ a, b < 2n . Then the desired bit can be extracted as the (n + 1)-th
bit of d = 2n + a − b. Security follows immediately from the security of the
protocol and the fact that d is computed by sequential calls to secure
subprotocols. Since comparison in this way reduces to extracting a single
bit from an integer, the protocol has the same complexities as .
We will in the following denote the protocol for comparison of two
shared integers [ a] I , [b] I satisfying 0 ≤ a, b < 2n by
([ a] I , [b] I , n).
7.3 Shifting
We now consider protocols for securely shifting up or down a shared integer a certain public number of bits. We also present a protocol that shifts
a shared integer up a secret number of bits such that the integer fits into a
certain public interval. The following subsections deal with security while
section 7.3.4 treats complexity.
7.3.1 Exact Shifting
Shifting a sharing [ a] I up with m bits is simply done by computing 2 m [ a] I as
long as no overflow occurs; for this we already have secure protocols. Shifting a down m bits is less trivial in that we cannot simply compute b a/2 m c.
However, if we know that 2 m | a we can compute the shift without overflow
Section 7.3
Shifting
67
as 2−m [ a] I where 2−m denotes the inverse of 2 m in Z p . This works since, if
2m | a, we can write a as 2m b and thus 2−m · 2m b = b. Hence, we propose
for shifting down an integer m bits in which we
a protocol
first “turn off” the m least significant bits of a. That is, the players first run
either
or
in order to obtain bit sharings of the m least significant bits of a. These bit sharings, i.e. [ a m ] B , [ am−1 ] B , . . . , [ a1 ] B are then
converted in parallel using
. From the resulting integer shares of the
bits, [ am ] I , [ am−1 ] I , . . . , [ a1 ] I , the players then locally compute
[ ã ] I =
m
∑ 2i −1 [ a i ] I ,
i =1
and finally output 2−m ([ a] I − [ ã ] I ).
Property 7.1. Let 0 ≤ m ≤ α be integers and let [ a] I be
a polynomial
sharing of
is implemented
an integer a such that 0 ≤ a < 2 α . Suppose that p mod
as subprotocol. If the prime p in Z p satisfies
4 = 3 and p >
using 2ρ+α+2 where ρ is the security parameter then ([ a] I , m) securely
computes [b] I where b = b a/2m c.
Proof. Correctness of the involved subprotocols follows due to the con straints on p. Correctness of
then follows from the above de only calls subprotocols in sequence that are
scription. Since
already private and since no further information is revealed during com putation,
is also private.
7.3.2 Approximate Shifting
The above protocol for shifting down an integer involves quite a lot of communication. Algesheimer, Camenish, and Shoup [1] present a much faster
approach with the drawback that the result is only an approximation of the
correct result. This protocol relies on
and
. We will call this pro tocol
. Despite the error that is introduced, it turns out that
the protocol in some situations can be applied as a subprotocol in such a
way as to produce exact results. This is the case in [1] and our division
protocols presented later in this chapter.
protocol for shifting down m bits simply requires
The
the players to jointly convert the sharing [ a] I of an integer F 3 a < 2n into
an additive sharing over the integers h ai Z using
followed by
.
Z
Each player P j then locally shifts down with m bits his additive share h ai j .
Finally, the players convert back the resulting sharing using the appropriate
share conversion protocols, i.e.
and
.
This results in a sharing [b] I such that |b − a/2m | ≤ k + 1 where k is the
number of players. The protocol is correct if p > 2 ρ+n+log k+4 holds because
of conversions with the
protocol. Privacy follows immediately from
the privacy of the involved subprotocols.
68
Integer Computation
Chapter 7
As mentioned in section 3.3.2 we have to make sure that the shares ob
tained from the
protocol are randomized. This is clearly the case here
since
is followed directly by
in which all shares are reshared
polynomially.
7.3.3 Shifting Up Integers Into a Certain Interval
Some protocols, for example
for computing an approximation to
1/b of an element b (described later in this chapter) only work properly
given that the input integer is insured to be in a certain interval. We will
now present a protocol called
that, given a public integer n and a
sharing of an integer 0 < c < 2 n , produces a sharing of an integer 2 m such
that 2n−1 ≤ c2m < 2n .
Our idea for computing a polynomial sharing of an integer 2 m , that
meets the conditions outlined above, is based on the lookup step in [31].
The basic approach is as follows: Let c = (c n , cn−1 , . . . , c1 )2 be the integer
that the players wish to shift. The players start the protocol by creating
in chapter 6, resulting
sharings of the n bits in c using the protocol
in a bit sharing [c n ] B , [cn−1 ] B , . . . , [c1 ] B . Next, they compute a bit vector d
where all entries from the most significant 1-bit in c down to the least significant bit is set to 1. After this, the players compute a vector e where all
bits except the most significant 1-bit in d is set to zero. This computation
could e.g. look like this (remembering that the players do not know these
bits but only shares of them):
c= 0 0 0 1 0 1 1 1 0 0
d= 0 0 0 1 1 1 1 1 1 1
e= 0 0 0 1 0 0 0 0 0 0
The vector d is calculated by letting
[dn ] B = [cn ] B
and for j = n − 1, . . . , 1 computing
[ d j ] B = [ c j ] B ∨ [ d j +1 ] B .
Finally the e vector is calculated by setting
[en ] B = [dn ] B
and then for j = n − 1, . . . , 1 computing
[ e j ] B = [ d j ] B ⊕ [ d j +1 ] B .
(7.1)
Section 7.3
Shifting
69
In order to compute the polynomial sharing of 2 m the players jointly con vert the sharings [e i ] B to [ei ] I using the
protocol from section 4.3.3.
The sharing of 2m is then computed as
[ 2 m ] I = 20 [ e n ] I + 21 [ e n − 1 ] I + · · · + 2 n − 1 [ e 1 ] I ,
i.e. by reverting the bit order of e.
Logarithmic Depth
The most expensive step above is the computation of the d vector which is
done in a linear number of rounds. We can, however, improve on this in a
way that resembles the prefix solution for
, cf. section 6.2. Consider
again the vector
( c n · · · c3 c2 c1 )
(7.2)
and observe that the d vector which was computed in (7.1) can be computed
as the prefix “sums” of (7.2)
dn = cn
d n −1 = c n ∨ c n −1
···
···
d1 = c n ∨ c n −1 ∨ · · · ∨ c1
using the PrefixSum Algorithm and the ∨-operator which is clearly associative. From section 5.2.2 we know that this doubles the number of multiplications needed, but reduces the number of rounds from n to log n. The
security of this protocol is stated as the following property.
Security
Property
7.2. Let [ a] I be a sharing of 0 < a < 2n . If p > 2ρ+n+3 then
([ a] I , n) securely computes a sharing [b] I of the unique integer b = 2 m
such that 2n−1 ≤ ab < 2n .
Proof. Due to the constraint on p, the subprotocol
is correct (see
section 6.2.4) and by the above discussion it should be clear that
is then also correct. Privacy follows since no information is revealed and
because
is a sequential composition of protocols that are already
private.
7.3.4 Complexity
Shifting up is simply done by an invocation of
and thus inherits the
complexity of
. Shifting an integer down m bits using the
70
Integer Computation
Chapter 7
protocol requires splitting m bits with
followed by converting m
bits with
. This is asymptotically dominated by the complexity of
.
The
involves converting from polynomial shares to additives shares over the integers using the four conversion protocols from
chapter 3. This takes Θ(1) rounds, Θ(k log p) bits of communication and
O(k2 ) multiplications in Z p per player. For
to be secure, it must hold
ρ
+
n
+
log
k
+
4
that p > 2
, i.e. log p ∈ Ω(ρ + n + log k).
The
protocol for producing a sharing of 2 m such that 2n−1 ≤
. Then O(n) logical operations are
c2m < 2n first splits n bits using
performed due to the computation of the d vector. Each logical operation
,
, etc.) takes a constant number of calls to
. All in all, this yields
(
a preprocessing in Θ(1) rounds, Θ(nk log p) bits of communication and
O(nk2 ) local multiplications in Z p . The processing takes Θ(log n) rounds,
Θ(kn + k log p) bits of communication, O(k) local multiplications in Z p ,
and O(nk2 ) local multiplications in GF(28 ). Also, we have log p ∈ Ω(n + ρ)
protocol.
due to the use of the
7.4 A First Approach Towards Division
Suppose, that we are given polynomial sharings of integers a and b. The following sections are concerned with protocols for integer division, i.e. protocols for computing a polynomial sharing of the integer quotient b a/bc.
We start out with a simple but relatively inefficient solution based solely
on binary search. This protocol will serve as a basic solution against which
more efficient solutions can be compared. Moreover, it is actually used in a
modified form as a subprotocol in our more efficient solutions.
7.4.1 Binary Search
The standard technique of binary search is usually applied in situations
where we, provided with some large data structure, wish to look up a certain element, see e.g. [25]. However, the standard binary search is not directly applicable in the context of secure multi-party computation since it
relies on branching and table lookup. Here, we present our variant of binary search which avoids direct branching and table lookup.
Suppose we are supplied with a function f : Z → {−1, 1}, a center
c ∈ Z and a range r ∈ Z such that
{ f (i )} ci=+cr−r
is a non-increasing sequence of 1’s and −1’s. Suppose also, that f (i ) = 1
for at least one i in the range {c − r, c − r + 1, . . . , c + r }. Then Algorithm
Section 7.4
A First Approach Towards Division
71
2 finds the rightmost i for which it holds that f (i ) = 1 using only O(log r )
invocations of f .
Algorithm 2 BINSEARCH(c, r )
1: d = f (c)
2: if r = 0 then
3:
return c − (1 − d)/2
4: else
5:
return BINSEARCH(c + d · dr/2e, br/2c)
6: end if
Property 7.3. If f : Z → {−1, 1} is a non-increasing function such that
f (i ) = 1 for at least one i ∈ {c − r, c − r + 1, . . . , c + r } then the
(c,r)
algorithm always terminates and correctly computes the largest i ∈ {c − r, c −
r + 1, . . . , c + r − 1, c + r } such that f (i ) = 1.
terminates and the range r strictly decreases
Proof. Since
for each recursive call, the algorithm always terminates. Correctness is
shown by induction in the range r.
As a special case, we will first prove by induction that the algorithm
returns c − r − 1 if called with all f (i ) = −1. This is clearly the case if
r = 0. If r > 0 the algorithm simply searches recursively on the left half
c − r, c − r + 1, . . . , c of the input range. On this new range, f of course still
evaluates to −1 and we are done.
We now consider the case where f (i ) = 1 for at least one i and give
a proof by induction in the range. For r = 1 the correctness can be verified by computation: We only need to check the three cases where ( f (c −
1), f (c), f (c + 1)) is (−1, −1, 1), (−1, 1, 1), and (1, 1, 1), respectively. Now,
returns the correct answer for any x and y
assume that
when y < r. If f (c) = −1 then the rightmost 1 must be to the left of
f (c) since the sequence { f (i )} is non-increasing. The new search area
(c − dr/2e) ± br/2c covers the left half of the sequence and since br/2c < r,
correctness follows by induction. In case f (c) = 1 a similar argument applies. However, in this case f (c) might itself be the rightmost 1 in the sequence. In this case, if r is even f (c) is included in the recursive search and
we are done, but if r is odd f (c) is omitted. But then we have seen that the
recursive call will return as answer (c + dr/2e) − br/2c − 1 = c since all
elements in the recursive call are −1.
A small optimization is possible since the above approach unnecessarily includes f (c) in the recursive search when f (c) = −1 and r is even.
However, this will not lead to any notable performance increase, but only
makes the algorithm more complicated.
72
Integer Computation
Chapter 7
Property 7.4. The (c,r) algorithm involves a total of blog(r )c + 2 recursive calls (including the first call) for r > 0.
Proof. It is easily seen that the number of recursive calls t(r ) is the solution
to the recurrence
t (0) = 1
t(r ) = 1 + t(br/2c)
for r > 1
which has the closed form solution blog r c + 2 ∈ O(log r ) for r > 0.
The main point to note here is that the above variant of binary search avoids
direct branching by instead recomputing the center and range of the search.
Also, table lookup is replaced by computation of a function. As a consequence, the above algorithm is applicable in the context of our secure
multi-party computation if we provide a subprotocol that securely evaluates f and if we avoid overflow in Z p .
7.4.2 Division Based on Binary Search
In this section we present an approach towards integer division that is
based solely on the binary search algorithm presented in the previous section. The protocol described here will also serve as a subprotocol in the
more efficient protocols for division that follows.
Let a and b be public integers for which we wish to compute the quotient q = b a/bc and let A and B be integers such that 0 ≤ a ≤ A and
1 ≤ b ≤ B, respectively. Consider the function
1
if a − xb ≥ 0
f ( x) =
−1 otherwise
which is non-increasing in any range q ± r. The largest i ∈ Z such that
f (i ) = 1 will be i = b a/bc (see figure 7.1). Therefore, this function may be
plugged into the algorithm in the previous section yielding an algorithm
where x = d A/2e.
for division, i.e. as a call
Note, that if A is odd, we here wish to search a sequence consisting
of an even number of elements, i.e. 0, 1, . . . , A. In such a case, we have to
extend the sequence with one element since
only works with a
sequence of odd length. This means that f (c + r ) = f ( A + 1). This is fine
if b > 1 or a < A since the algorithm then never visits the right end of the
sequence. However, in the case where b = 1 and a = A, the search will
end up with c = A and f (c) = 1 and then continue to c = A + 1, which is
off-by-one. But since f ( A + 1) = a − ( A + 1)b = −1 in all cases, this causes
the algorithm to return the correct value A, cf. the proof of property 7.3.
In this way, the search algorithm is extended to handle search of an even
number of elements with an extra evaluation of the function f which only
occurs in the worst-case when b = 1 and a = A.
Section 7.4
A First Approach Towards Division
i
a − ib
f (i )
1
4
1
2
1
1
3
-2
-1
4
-5
-1
5
-8
-1
6
-11
-1
73
7
-14
-1
Figure 7.1: The search area when a = 7, b = 3, c = 4 and r = 3.
Avoiding Overflow
The algorithm relies only on basic arithmetics and comparison for which
we have already protocols. In order to construct a division protocol from
this algorithm, we must ensure that the comparison subprotocol is given
only non-negative integers1 and – equally important – that no overflow
occurs in Z p during the computation.
with r > 0 (calls with r = 0 will
Consider first a call
be treated later) and where the quotient q = b a/bc actually lies somewhere
within the search area, i.e. c − r ≤ q ≤ c + r. This, combined with the fact
that a − b < qb ≤ a, allows us to bound cb by
a − b(1 + r ) < (q − r )b ≤ cb ≤ (q + r )b ≤ a + rb,
(7.3)
which, given public bounds A and B such that 0 ≤ a ≤ A and 1 ≤ b ≤ B,
yields
− B(1 + r ) < cb ≤ A + rB.
Continuing, we can use equation 7.3 to bound a − cb by
−rB ≤ a − cb < B(1 + r ),
(7.4)
which suggests that we implement the comparison a − cb ≥ 0 by the equivalent a − cb + rB ≥ rB. In this way, we ensure that only non-negative
integers are supplied as input to the comparison protocol. On the other
hand, the protocol must then handle comparison of integers that are potentially as large as B(1 + r ) + rB − 1, i.e. dlog( B(1 + 2r ))e bit integers.
In the implementation we need to work with representations of a, b,
c, rB, cb, rB − cb and rB − cb + a, respectively. By the above discussion
it follows that these integers are all greater than or equal to − B(1 + r ) and
less than or equal to max{ A + rB, B(1 + 2r ) − 1}. We can, however, tolerate
intermediate overflow in Z p as long as the final result, a − cb, is known
to be within the field2 . So, it is sufficient to choose p > B(1 + 2r ) − 1.
Also, since we must compare m = dlog( B(1 + 2r ))e bits, we must ensure
1 The comparison protocol is not designed to handle signed integers; it will treat negative
integers as very large positive integers.
2 This only holds as long as we do not compute “outside” the field, i.e. as done in e.g. the
comparison.
74
Integer Computation
Chapter 7
that p > (1 + 2r ) B2ρ+2 in order for the comparison protocol to provide
appropriate security, see section 7.2.
Since the bounds inferred so far only depend on the public integers r, A,
and B, where A and B are constants and r is decreasing for every recursive
call, we avoid overflow if we replace r with the initial range r 0 as long as
r0 > 0. In the special cases where the actual quotient is not in the search
area, i.e. f (i ) = −1 for all c − r ≤ i ≤ c + r, we know (cf. proof of property
7.3) that it is just to the left, i.e. q = c − r − 1. As this special case does not
occur in the initial call to
but only when we have branched
to the right at least once before, c is still bounded by q + r 0 .
On the other hand, since r decreases for each recursive call, the number
of bits that we have to compare and the maximum values that we have to
represent decrease accordingly. This may be used to optimize the binary
search algorithm. In our implementation we decrease the number of bits in
the comparison during recursive calls.
However, if we use the decreasing r for computing the number of bits
to compare, we also have to cope with the special case where r = 0. In such
a case, we can simply use r = 1 when computing the number of bits to
compare, since we by the proof of property 7.3 know that the right quotient
is either c or c − 1.
Another complication arises in the special case where the quotient is
not within the search space. In such a case, we know from the proof of
property 7.3 that the quotient is precisely one step to the left of the search
area, i.e. c = q + r + 1. This leads to cb = (q + r + 1)b which in turn results
in (still remembering that a − b < qb ≤ a)
r ≤ a + rb < cb ≤ a + b(1 + r ) ≤ A + B(1 + r ),
0 ≤ a − cb + B(1 + r ) < B.
Since B is less than the previous maximum B(1 + 2r ) inferred from (7.4),
we actually need to compare fewer bits in this special case. We do not
know, however, which case we are in (except in the first recursive call), so
we must add the largest offset, i.e. implement the comparison as a − cb +
B(1 + r ) ≥ B(1 + r ). Since we still only have a − cb < B(1 + r ) when we
are not in the special case, we end up with integers for the comparison that
can potentially be as large as B(1 + r ) + B(1 + r ) − 1 = 2B(1 + r ) − 1. We
must therefore choose p > 2B(1 + r ) − 1.
and
We have added this offset also in the first call to
hence p > 2B(1 + r0 ) − 1 must hold.
Another small optimization is possible if we know that all the integers
in the search space are non-negative; this results in the additional bound
0 ≤ cb. We will not go into details with this (nor implement it) since it
.
does only apply to the case where division is done solely with
Even with this optimization this strategy is probably way more inefficient
Section 7.4
A First Approach Towards Division
75
than the division algorithms that we will later describe and to which this
optimization does not apply.
as a stand-alone protocol for division we
When using
must also take care of overflow in the situation that is described in section
7.4.2 above, i.e. the special case where a = A and b = 1 which leads to
evaluation of f ( A + 1). However, the number of bits m that we must be
able to compare only depends on B, m is unaffected. Overflow in Z p when
computing f ( A + 1) is tolerable since we “get back again” before we reach
the input to the comparison.
As a concrete example, suppose we wish to find b a/bc where a and b are
two 32-bit integers, i.e. A = B = 232 − 1. With the optimization discussed
above involving a decreasing range r, the initial call to
should
have c = 231 and the range would go from r = 231 , 230 , 229 , . . . , 21 , 20 , 0,
i.e. 33 recursive calls. The number of bits to compare in the recursive calls
will then be 65, 64, 63, . . . , 34, 33. Furthermore, if we wish to keep the probability of information leakage at, say, 1/2 30 for each comparison, we must
use a 98-bit prime p for our field.
protocol3 is shown as Protocol 3 and Protocol 4 on
The
page 75 and 76.
Protocol 3 DIVBINSEARCH([ a] jI , [b] jI , [c] jI , A, B, r)
Require: 0 ≤ a ≤ A and 1 ≤ b ≤ B
[d] jI ← SIGN([ a] jI , [b] jI , [c] jI , A, B, r )
if r = 0 then
Output [c] jI + (1 − [d] jI )2−1 (where 2−1 means the inverse of 2 in I)
else
[c] jI ← [c] jI + [d] jI dr/2e
Recursively call DIVBINSEARCH([c] jI , [ a] jI , [b] jI , A, B, br/2c)
end if
Security
Property 7.5. Let [ a] I and [b] I be sharings of integers a and b where a and b
respectively satisfies 0 ≤ a ≤ A and 1 ≤ b ≤ B. Suppose r 0 and c0 are integers
such that c0 − r0 ≤ b a/bc ≤ c0 + r0 . Let ρ be the security parameter and let p >
3 The
notation in protocol 3 defines what player Pj should locally do to his shares. In a
protocol such as, e.g. the players must of course participate in synchronous communication . This notation will be used throughout the rest of this thesis.
76
Integer Computation
Chapter 7
(r0 + 1) B2ρ+3 and p mod 4 = 3. Then DIVBINSEARCH([ a] I , [b] I , [c0 ] I , A, B, r0 )
securely computes a sharing [q] I of the integer quotient q = b a/bc.
Proof. Due to the above discussion (section Avoiding Overflow) it should be
clear that these constraints on p are sufficient to avoid overflow in Z p and
for the comparison subprotocols to be correct (p mod 4 = 3 is necessary
to work). Then, by the discussion in section 7.4.2, the algorithm
for
is correct. Privacy follows immediately from the fact that the protocol is a
sequential composition of private subprotocols and that no information is
otherwise revealed by the players during the protocol execution.
The next corollary states that the
protocol can be used as
stand-alone protocol for division of integers.
Corollary 7.6. Let [ a] I , [b] I , and ρ be as described in property 7.5. Assume also
that r0 = c0 = d A/2e. Let p > (r0 + 1) B2ρ+3 and p mod 4 = 3. Then
DIVBINSEARCH([ a] I , [b] I , [c0 ] I , A, B, r0 ) securely computes a sharing [q] I of the
quotient q = b a/bc.
Proof. Security follows by the same argument as in the proof of property
7.5 and the discussion above of the situation where A is odd.
Round and Communication Complexity
In the following we assume that GF(28 ) is used to represent the individual
the protocol is called.
bits. For each recursive call to
This protocol, in turn, involves calls to
and
. We will analyze the protocol without the optimization with decreasing range, i.e. with
r = r0 in all recursive calls; this will clearly not affect the inferred round
complexity. Regarding communication complexity, the optimization might
have a small effect, but the complexity that we derive will of course still be
an upper bound.
Protocol 4 SIGN([ a] jI , [b] jI , [c] jI , A, B, r)
Require: 0 ≤ a ≤ A and 1 ≤ b ≤ B
[ x ] jI ← B(1 + r ) + [ a] jI − MUL([c] jI , [b] jI )
m ← dlog(2B(1 + r ))e
[s] Bj ← COMPARE([ x ] jI , B(1 + r ), m)
[r ] jI ← B2I([s] Bj )
Return 2[r ] I − 1
Section 7.4
A First Approach Towards Division
77
Consider a call to
with range r and center c where the
public upper-bounds A and B are n a and nb -bit integers, respectively. From
the above discussion, it follows that we have to compare numbers that
can potentially be as large as 2B(1 + r ) − 1, i.e. Θ(n b + log r ) bit integers.
Since comparison is done Θ(log r ) times and comparison of x-bit integers
requires Θ(log x ) rounds, we end up with Θ(log r (log(n b + log r ))) rounds.
Preprocessing for a comparison requires Θ(nk log p) bits of communication where n is the number of bits to compare, see section 7.2 and
6.2. As we Θ(log r ) times compare Θ(n b + log r ) bits we end up with
Θ(log r ((nb + log r )k log p)) bits of communication.
The rest of the protocol is dominated by the actual comparisons and by
the execution of the
protocol, each of which is executed Θ(log r ) times.
protocol requires Θ(k log p) bits and the comparison processing
The
step takes Θ(kn + k log p) bits of communication where n is the number of
bits to compare. We therefore end up with a total of Θ(log r (k(n b + log r ) +
k log p)) bits of communication.
Due to the constraints on p from property 7.5 above we see that for the
protocol to be secure, we must have log p ∈ Ω(log r + n b +
ρ). Assuming that n a ≤ nb we get the simplified log p ∈ Ω(log r + n b + ρ)
which will later become useful.
Suppose that we use the
protocol for division of two n bit
integers as pointed out in corollary 7.6. From the above we have that
this takes Θ(1) rounds and Θ(log r ((n b + log r )k log p)) bits of communication for preprocessing. By replacing log r with n in the above complexity
(since r is set to A/2) we see that the actual preprocessing then requires
Θ(n2 k log p) = Θ(n3 k + kρn2 ) bits of communication. Apart from the preprocessing, the actual division requires Θ(n log n) rounds and Θ(kn 2 +
kn log p) = Θ(kn2 + knρ) bits of communication.
Computational Complexity
We know that comparing n bits takes O(nk 2 ) multiplications in Z p for
preprocessing and O(k) multiplications in Z p as well as O(nk2 ) multiplications in GF(28 ) for processing. Comparison is done Θ(log r ) times
with integers that have bit size ∈ Θ(n b + log r ). This yields a preprocessing of O((n b + log r )k2 log r ) multiplications in Z p . Processing requires
O(k2 log r ) multiplications in Z p and O((nb + log r )k2 log r ) multiplications
in GF(28 ).
as a stand-alone division protocol for n bit inteBy using
gers, i.e. with log r ∈ Θ(n), preprocessing becomes O(n 2 k2 ) multiplications
while processing yields O(n 2 ) multiplications in Z p and O(n2 k2 ) multiplications in GF(28 ).
78
Integer Computation
Chapter 7
In this section we have described a relatively simple protocol for division
build on a number of comparisons that are linear in the bit size of the integers to divide. Experiments (chapter 8) show that comparison is a relatively
expensive operation. So spending, say, 32 comparisons on division of two
32-bit integers is not considered efficient. However, this protocol will be
part of more efficient protocols presented in the next section.
7.5 Efficient Division
The above solution can be viewed as a circuit having depth O(n log n)
where n is the bit size of the integers to divide. It was however shown
by Beame, Cook, and Hoover [5] that there exists circuits for integer division with depth O(log n), though their actual construction of such circuits
were quire complicated. A simpler algorithmic O(log n) solution based on
Newton iteration is pointed out by Kozen [26].
It is, however, not obvious how this carries over to secure multi-party
computation. Algesheimer, Camenish, and Shoup [1] have done part of the
job by developing SMPC protocols for securely computing an approximation of the reciprocal of an integer using secure and distributed Newton
iteration. In this section we combine this with the integer comparison protocol from SCET and our own protocols in order to construct complete protocols for integer division. The main idea is to compute an approximation
of 1/b using the protocol from [1] and then multiply this with a. We then
show that the result is so close to b a/bc that we only need to do a small
amount of searching using the binary search protocol from the previous
section in order to find the exact quotient.
Several complications arise when trying to apply the O(log n) solutions
in an SMPC setting. A consequence is that we end up with an SMPC circuit having depth O(log(n + log k)). This is, however, still quite close to
O(log n).
We present two variants of integer division. The main difference is the
use of two different truncation protocols for the final truncation of the approximation of a/b. The first, presented in section 7.3.1, involves some of
the binary techniques introduced in the previous chapters in order to truncate exactly. This exact truncation involves a considerable amount of work,
but reduces the search space that we must finally search for the right quotient. Secondly, we will present a variant that uses the fast but approximate
truncation technique presented in section 7.3.2. This has the disadvantage
that we must finally search a larger range for the exact quotient than is the
case when using the exact truncation. In chapter 8 we compare these strategies based on implementations of the protocols.
Related Work Apart from [1], Atallah et al. [3] is concerned with SMPC
Section 7.5
Efficient Division
79
protocols for division of floating point numbers. However, they work with
another trust model and their protocols are not secure in our model. Hence,
we cannot directly compare their protocols to ours.
7.5.1 Newton Iteration
Newton iteration, or Newton-Raphson iteration, is a method that is used
to approximate the roots of a given equation, see [1, 32]. Let f ( x ) be a
differentiable function where f ( x̃ ) = 0. Then, Newtons iteration formula
is given by
f ( xi )
.
(7.5)
x i +1 = x i − 0
f ( xi )
The geometric intuition behind this is given in figure 7.2. For a given point
xi the tangent line to the point ( x i , f ( xi )) is t xi ( x ) = f 0 ( x )( x − xi ) + f ( xi ).
The next point x i+1 is defined by the intersection between this tangent line
and the x-axis. Since
t xi ( x ) = 0 ⇒ x =
f (x )
f 0 ( xi ) xi − f ( xi )
= xi − 0 i
0
f ( xi )
f ( xi )
we obtain the iteration formula (7.5). If we assume that f 0 ( x ) 6= 0 in a
reasonable neighborhood around x̃ we get a sequence x0 , x1 , x2 , . . . of approximations to x̃.
Figure 7.2: Newton iteration for approximating 1/b.
If we want to find an approximation to 1/b we will apply Newton’s
method with the function f ( x ) = 1x − b that clearly has f (1/b) = 0. By
equation (7.5) we get the iteration formula
x i +1 = x i (2 − x i b ),
(7.6)
80
Integer Computation
Chapter 7
where the x i ’s are known to converge quadratically to 1/b if the starting point x0 is chosen sufficiently close to the root. More concretely, it is
proved by Kozen [26] (section 30.3) that the iteration formula 7.6 converges
quadratically if the starting value x 0 is the unique fractional power of 2,
1 1
i.e. 1/2x for some x, in the interval ( 2b
, b ].
In our protocols we will sometimes in the following let Z p represent
fixed-point fractions; that is, we will treat a ∈ Z p as a2−m for some m.
7.5.2 Computing an Approximation of 1/b
from [1] for
In the following subsection we will present the protocol
calculating a polynomial sharing of an approximation of 1/b using Newton
iteration in a distributed setting. That is, a protocol which, given a polynomial sharing [b] I of an integer b with 2n−1 ≤ b < 2n for a public constant
n, computes a polynomial sharing of an integer b̃ such that b̃2−s = 1/b + e
for certain s and e.
Since we are in a distributed setting we cannot use the Newton iteration method directly as described in section 7.5.1, but instead have to make
some changes in order for the method to work. First of all, we use the function f ( x ) = 1x − 2bn instead of the more obvious f ( x ) = x1 − b. This gives us
the iteration formula
b
x i +1 = x i 2 − x i n .
2
Furthermore, to obtain quadratic convergence we have to choose a good
starting point for the iteration. By requiring that 2 n−1 ≤ b < 2n and hence
1 < 2n /b ≤ 2 we ensure by using 3/2 as starting point that our initial
error is at most 1/2. The convergence is further complicated because the
protocol which yields only an
protocol repeatedly uses the
approximate truncation, see section 7.3.2.
The
protocol is shown on page 81 as Protocol 5. Note, that it uses
t
−
1
3·2
instead of 3/2 as mentioned above; this saves us for a multiplication
in the end when returning sharings of b̃ because we can return it directly
instead of first having to multiply it with 2 t .
Property 7.7. Let ρ be a security parameter and let p > 2 ρ+t+µ+6+log k where
µ = max (n, t). Then it holds for any t > 5 + log(k + 1) and any b, where
2n−1 ≤ b < 2n that the protocol
([b] jI , n, t) securely computes a sharing
[b̃ ] I of an integer b̃ such that
n
2
− b̃ < k + 1
b
t
2 2t −4
with 0 ≤ b̃ < 2t+2 . This means that b̃/2t+n is an approximation of 1/b with a
1
relative error less than 2k+
t −4 .
Section 7.5
Efficient Division
81
Property 7.7 is essentially proved by Algesheimer, Camenish, and Shoup
[1]. Their proof considers a slightly stricter input criteria on b, namely
2n−1 < b < 2n , excluding the situation b = 2 n−1 . Since we also need correctness in the case b = 2 n−1 we present their proof in a slightly modified
and somewhat more elaborate version, showing that the protocol results in
the correct result even when b = 2 n−1 .
First of all, we notice that privacy of the protocol follows immediately
since it is sequentially composed from subprotocols (
,
)
which are already known to be private and since no further information is
revealed at the top-level of the protocol. It only remains to argue for the
correctness of
. We divide the proof into three separate lemmas and
use the notation from Protocol 5, i.e. u i , vi , etc.
Lemma 7.8. If k < 2t−5 − 1 and 2n−1 ≤ b < 2n then it holds ∀i ∈ N that
n
2
− ui ≤ 1
b
2t 2
and thus 1/2 <
ui
2t
≤ 5/2.
Proof. This proof will be given using induction in the variable i. We define
n
ei = | 2b − 2uti | and show ei ≤ 1/2 for all i.
Basis: Since 2n−1 ≤ b < 2n ⇒ 1 <
follows that e0 ≤ 1/2.
2n
b
≤ 2 and u0 = 3 · 2t−1 ⇒
n
u0
2t
= 3/2 it
Induction: Assume that e i ≤ 1/2. Since 1 < 2b ≤ 2 it follows that 1/2 <
ui
≤ 5/2 and because of the error introduced from the approximate
2t
Protocol 5 APPINV([b] jI , n, t)
Require: t > 5 + log (k + 1).
Set [u0 ] jI ← u0 = 3 · 2t−1 mod I
for i = 0 to dlog(t − 3 − log(k + 1))e − 1 do
Compute [z i+1 ] jI ← MUL([b] jI , [ui ] jI )
Run [wi+1 ] jI ←
Run [ui+1 ] jI ←
([zi+1 ] jI , n)
Compute [v i+1 ] jI ← 2t+1 · [ui ] jI − MUL([wi+1 ] jI , [ui ] jI )
end for
Return [b̃ ] jI ← [ui+1 ] jI
([vi+1 ] jI , t)
82
Integer Computation
Chapter 7
truncations we have the following upper and lower bounds on u i+1
1 bui
− k − 1 ui + k + 1
(7.7)
ui+1 ≤ 2ui − t
2 2n
1 bui
+ k + 1 ui − k − 1
(7.8)
ui+1 ≥ 2ui − t
2 2n
which can be rewritten as
u i +1
u
b
≤ 2 ti − n
t
2
2
2
u i +1
2t
2
k+1
ui
+ t
1 + t = : Hi
2
2
2
k+1
ui
b ui
ui
− t
≥2 t − n
1 + t =: Li
2
2 2t
2
2
ui
2t
From this it follows that e i+1 = | 2b − u2i+t 1 | ≤ max{| 2b − Li |, | 2b − Hi |}.
Now, we have that
n
n 2 2
2
ui
2n u i
2
k+1
ui − Li = b
+
−
2
−
1
+
b
2n
b
2t
b 2t
2t
2t n
2
b 2
ui
k+1
ui = n
− t − t
1+ t 2
b
2
2
2
n
2 b 2
k + 1
u
u
i
i
≤ n
1 + t − t + t
2
b
2
2
2
2
k+1
b 2n
ui
ui
+ t
= n
1+ t
− t
2
b
2
2
2
n
n
n
where the last equality is because 1/2 < u2ti ≤ 5/2. Since it also holds
that
n
n
2
2
b 2
k
+
1
u
u
i
i
− Hi = + t
1 + t b
2n b − 2t
2
2
2
k+1
ui
ui
b 2n
1+ t ,
− t + t
= n
2
b
2
2
2
we conclude
n
2
ui+1 ei +1 = − t ≤
b
2
u
2n
− ti
b
2
2
k+1
ui
+ t
1+ t
(7.9)
2
2
ui
b 2 k+1
1+ t
= n ei + t
2
2
2
2
1
5
3
1
1
<
1+
= < .
+
2
32
2
8
2
b
2n
Section 7.5
Efficient Division
83
The last inequality follows from the induction hypothesis and the fact
1
< 1/32.
that b < 2n ⇔ 2bn < 1 and k < 2t−5 − 1 ⇔ k+
2t
Lemma 7.9. If 2n−1 ≤ b < 2n it holds ∀i ∈ N that ei+1 < e2i +
k +1
.
2t −2
Proof. For the same reasons as in the above lemma, cf. inequality (7.9), and
the fact that 1/2 < u2ti ≤ 5/2 we have
ei +1
and since
b
2n
n
2
2
b 2n
ui+1 ui
k+1
5
= − t ≤ n
− t
+ t
1+
b
2
2
b
2
2
2
< 1 we conclude that
ei +1 <
2n
u
− ti
b
2
=
2n
u
− ti
b
2
2
2
+
k+1 8
·
2t
2
+
k+1
k+1
= e2i + t−2 .
t
−
2
2
2
1
Lemma 7.10. If k < 2t−5 − 1, ei+1 ≤ e2i + 2k+
t −2 , and ei < 1/2 then it holds
∀i ≥ 2 that
k+1
1
ei < 2i + t −3 .
2
2
Proof. This proof will be given using induction in the variable i.
Basis: We know from lemma 7.8 that e0 ≤ 1/2. Thus we have
e1 ≤ e02 +
and then
1 2t −5
1 1
3
k+1
<
+ t −2 = + =
t
−
2
2
4 2
4 8
8
2
3
1
9
1
17
e2 <
+ =
+ =
.
8
8
64 8
64
In order to prove the basis case when i = 2 we need to prove that
1
e2 < 214 + 2k+
t −3 . However this should be clear since
1
k+1
1
1
2t −5
1
5
+ t −3 <
+ t −3 =
+ =
4
2
2
16 2
16 4
16
and
17
64
<
5
16 .
84
Integer Computation
Chapter 7
Induction: Assume that e i <
ei+1 ≤ e2i +
≤
+
k +1
.
2t −3
k+1
2t −2
k+1
1
+ t −3
2
22 i
1
=
22 i + 1
<
22 i + 1
=
22 i + 1
≤
1
22 i
1
1
1
i +1
22
Then for ei+1 we have
2
+
k+1
2t −2
1 k+1
k+1 k+1
2
+ t −3
− 2i + · t −3
t
−
3
2
2
2 2
2
t −5
2
k+1 2
1
− 2i +
+ t −3
t
−
3
2
2
2
2
2
k+1 1
1
− 2i +
+ t −3
2
4 2
2
+
k+1
2t −3
The last inequality is due to the fact that ( 14 + 21 +
2
)
22 i
≤ 1 when i ≥ 2.
Now, after i = dlog(t − 3 − log(k + 1))e iterations we know by lemma 7.10
that
1
k+1
1
k+1
k+1
ei < 2i + t−3 ≤ log(t−3−log(k +1)) + t−3 = t−4 .
2
2
2
2
2
2
All that is left to argue, in order for the protocol to be correct, is that no
overflow in Z p occurs. That is, we have to determine the maximal values
of ui , zi , wi , and vi computed during protocol execution. From lemma 7.8
it follows that 1/2 < u2ti ≤ 5/2 for all i and hence 0 ≤ u i < 2t+2 . Then,
as zi = b · ui , we have 0 ≤ z i < 2t+n+2 . Also, since u i is computed as
(vi , t), we know that
( k + 1)
u
( k + 1)
ui
−
≤ vi ≤ ti +
t
t
2
2
2
2t
which, combined with the fact that k < 2 t−5 − 1, allows us to conclude that
0 ≤ vi < 22t+2 .
From the limits of the different variables we see that the v i ’s are the
largest. We must therefore choose p > 2 2t+2 . Because of truncation, p must
protocol in order to avoid overflow,
also fulfill the demands from the
i.e. p > ρ + log x + log k + 4, where x is the input value to the truncation
protocol. Altogether, we must choose p > ρ + t + µ + 6 + log k, where
µ = max(t, n). This completes the proof of property 7.7.
We note that t ∈ Ω(log k). The cost of the protocol is dominated by the
calls to
which each requires Θ(1) rounds, Θ(k log p) bits of
Section 7.5
Efficient Division
85
communication and O(k2 ) multiplications in Z p . Since we call the protocol
Θ(log(t − log k)) times, we end up with O(log t) rounds and
O(k log(t) log( p)) bits of communication. The computational complexity is
O(k2 log t) multiplications in Z p . Also, due to the security of
we get
log p ∈ Ω(n + ρ + log k).
7.5.3 The Division Protocol
We have now presented the building blocks and we will here present the
actual division protocol.
Division with Exact Truncation
Suppose we have [ a] I and [b] I and public bounds n a , nb such that 0 ≤ a <
2n a and 1 ≤ b < 2nb where n a ≤ nb . With the
protocol in section 7.3.3
m
I
m
we can compute a sharing [2 ] such that β = b2 satisfies 2nb −1 ≤ β < 2nb .
In order for us to compute a polynomial sharing of b a/bc we set
t = dlog(k + 1) + 4 − log(
1
)e.
2n b
protocol we by property 7.7 get
With this t and [ β] I as input to the
as output a sharing of an integer β̃ satisfying the following inequality
β̃
1
2n b
1
<
− t < n .
(7.10)
n
m
b
2
b2
2
2 b
Suppose a > 0. Since a < 2n a ≤ 2nb and m ≤ nb imply 2nb −m /a > 1/2nb , it
follows from (7.10) that
−
and therefore
which yields
−
2n b − m
β̃
2n b − m
2n b
< m− t <
a
b2
2
a
1
1
1
− < − β̃2m 2−t−nb <
a
b
a
a
− a β̃2m 2−t−nb < 1.
(7.11)
b
Equation (7.11) is of course also true if a = 0. In other words an execution
protocol with input [ β] I = [2m ] I [b] I and t = dlog(k + 1) +
of the
4 − log(1/2nb )e returns a sharing of an integer β̃, where q = a β̃2m−nb −t is
an approximation of a/b with an absolute error strictly less than one. From
this we conclude that the desired quotient b a/bc is either bqc, bqc + 1, or
in order to
bqc − 1. This means that we can truncate q using
obtain a sharing of bqc and subsequently use
to search for
the exact quotient in the range bqc − 1, bqc, bqc + 1.
The protocol is presented as Protocol 6 below, and we now prove that
the protocol satisfies the usual correctness and privacy properties.
−1 <
86
Integer Computation
Chapter 7
Property 7.11. Let ρ ∈ N be the security parameter. Suppose also, that [ a] I and
[b] I are sharings of two integers a and b satisfying 0 ≤ a < 2 n a and 1 ≤ b < 2nb
for public constants n a ≤ nb . If p > max{2 R , 2S } where
R = ρ + 2nb + n a + dlog(k + 1)e + 8
S = ρ + 2nb + 2dlog(k + 1)e + 14 + log k
and p mod 4 = 3 then
computes a sharing of [r ] I =
is
secure, i.e. it is private and it correctly
([ a] I , [b] I , n a , nb ) where r = b a/bc.
Proof. Privacy follows immediately from the fact that
is sequentially composed of private protocols. Concerning correctness, it should be
clear, based on the above discussion, that
is correct as long as the
subprotocols are correct and no overflow in Z p occurs. First, consider the
size of the computed shares in Protocol 6 assuming that the subprotocols
and
we have that 0 ≤ d < 2 nb
are correct: From correctness of
n
+
n
a
b . From correctness of
it then follows that 0 ≤ c <
and 0 ≤ x < 2
t
+
2
2
for t = dlog(k + 1)e + n b + 4. Hence, we have 0 ≤ y < 2n a +nb +t+2 and
by correctness of
finally 0 ≤ q < 2 n a +2 . In order to represent
the largest of the integers, i.e. y, without overflow (and assuming correct
subprotocols) we need
p > 2n a +nb +t+2 = 2n a +2nb +dlog(k+1)e+6
(7.12)
Secondly, for the subprotocols to be correct we must have that p > 2 ρ+nb +3
for
and for
(remembering that t = n b + dlog(k + 1)e + 4
when used in the division)
p > 2ρ+2nb +2dlog(k+1)e+14+log k
(7.13)
while
requires p > 2ρ+2nb +n a +dlog(k+1)e+8. Finally, the subpro is correct if p > (2nb − 1)2ρ+5 .
tocol
The strictest of these requirements for the size of p are those imposed by
the
(7.13) and the
protocol. We therefore reach the re quirements stated in property 7.11. The protocols
and
both rely on
which imposes p mod 4 = 3.
Division with Approximate Truncation
The final call to
in Protocol 6 (line 7) is quite time consum ing. In this section we present a variation
in which the call
to
is replaced by a call to the much faster
. As
a consequence, we do not only have to find the right result between the
three possible values bqc − 1, bqc and bqc + 1. This is due to the fact, that
Section 7.5
Efficient Division
87
Protocol 6 DIV-EXACT([ a] jI , [b] jI , n a , nb )
Require: 0 ≤ a < 2n a , 1 ≤ b < 2nb , n a ≤ nb
1:
2:
3:
4:
5:
6:
7:
8:
Locally compute t ← dlog(k + 1)e + n b + 4
Compute [m] jI ← CALC2M([b] jI , nb )
[d] jI ← MUL([b] jI , [m] jI )
[c] jI ← APPINV([d] jI , nb , t)
[ x ] jI ← MUL([ a] jI , [m] jI )
[y] jI ← MUL([ x ] jI , [c] jI )
[q] jI ←
([y] jI , nb + t)
Output [r ] jI ← DIVBINSEARCH([ a] jI , [b] jI , [q] jI , 2n a − 1, 2nb − 1, 1)
introduces an error |e| ≤ k + 1, where k is the number of
players. Therefore, we have to search between the elements
b q c − ( k + 2), b q c − ( k + 1), . . . , b q c, . . . , b q c + ( k + 1), b q c + ( k + 2).
This means that we now have to search 3 + 2(k + 1) instead of just 3 ele ments using the
protocol in order to find the right quotient
b a/bc. This leads us to Protocol 7 on page 88.
Property 7.12. Let ρ ∈ N be the security parameter. Suppose also that [ a] I and
[b] I are sharings of two integers a and b satisfying 0 ≤ a < 2 n a and 1 ≤ b < 2nb
for public constants n a ≤ nb . If p > max{2 R , 2S } where
R = ρ + n a + 2nb + dlog(k + 1)e + log k + 10
S = ρ + 2nb + 2dlog(k + 1)e + log k + 14
is secure, i.e. it is private and it correctly
and p mod 4 = 3 then ([ a] I , [b] I , n , n ) where r = b a/bc.
computes a sharing [r ] I =
a b
Proof. The proof is essentially the same as for
. Concerning over flow in Z p , we note that
is now called with an (n a + nb + t +
2)-bit integer instead of
; therefore, p > 2 ρ+n a +2nb +dlog(k+1)e+log k+10
imposes
must hold. Also, the increased range in the call to
n
ρ
+
3
b
that p > (k + 2)(2 − 1)2 .
are again dominated by
However, the requirements from
that of
and, in this case,
.
88
Integer Computation
Chapter 7
Protocol 7 DIV-APPROX([ a] jI , [b] jI , n a , nb )
Require: 0 ≤ a < 2n a , 1 ≤ b < 2nb , n a ≤ nb
1:
2:
3:
4:
5:
6:
7:
8:
Locally compute t ← dlog(k + 1)e + n b + 4
Compute [m] jI ← CALC2M([b] jI , nb )
[d] jI ← MUL([b] jI , [m] jI )
[c] jI ← APPINV([d] jI , nb , t)
[ x ] jI ← MUL([ a] jI , [m] jI )
[y] jI ← MUL([ x ] jI , [c] jI )
[q] jI ←
([y] jI , nb + t)
Output [r ] jI ← DIVBINSEARCH([ a] jI , [b] jI , [q] jI , 2n a − 1, 2nb − 1, k + 2)
Remark Regarding the size of p we notice that when n a > dlog(k + 1)e + 4
the requirement imposed by
, i.e. originating from the con
version to an additive sharing over Z using
, is the strictest. This will
be the case for typical parameter settings, e.g. n a = nb = 32 and k = 5.
Round and Communication Complexity
In this section we will look at the communication and round complexities
of the two division protocols. As mentioned above the protocols are almost
identical except that they use different truncation protocols and therefore
the parameters to the
subprotocol are slightly different.
. As can be seen in this protocol there are
We start out with
four dominant subprotocols. They are
,
,
, and
which must search 3 integers.
We first consider the complexity of the various preprocessing steps; that
is, several of the subprotocols involve work which is independent of the
input – work that can be done in advance and in parallel. First,
involves splitting all bits in an n b -bit integer using
. This takes Θ(1)
rounds and Θ(kn b log p) bits of communication. Secondly, the subprotocol
requires Θ(1) rounds and Θ(k(n b + t) log p) bits of communication for preprocessing, since we only need to produce n b + t random bits.
In the division, t = dlog(k + 1)e + n b + 4 ∈ Θ(log k + n b ), which results in
a communication complexity ∈ Θ(k(n b + log k) log p) for
. At
last, since the search range is constant,
involves Θ(1) rounds
and Θ(knb log p) bits of communication. Hence, we have a total preprocessing that takes Θ(1) rounds and requires Θ(k(n b + log k) log p) bits of
Section 7.5
Efficient Division
89
communication.
Regarding the actual processing, i.e. the computation that depends on
takes Θ(log n b ) rounds and Θ(kn b + k log p)
the input, we note that
4
bits of communication . The
takes Θ(log t) = Θ(log(n b + log k))
rounds and Θ(k log t log p) = Θ(k log(n b + log k) log p) bits. Now, we
must also truncate n b + t ∈ Θ(nb + log k) bits from an n a + nb + t + 2 ∈
Θ(n a + nb + log k) bit integer using the
protocol. This takes
Θ(log(nb + t)) = Θ(log(n b + log k)) rounds and Θ(k(n b + t) + k log p) =
Θ(k(nb + log k) + k log p) bits of communication. With constant range the
takes Θ(log n b ) rounds and Θ(kn b + k log p)
processing of
bits of communication. This leads to a total number of rounds which is
Θ(log(nb + log k)) and Θ(kn b + k log(nb + log k) log p + k log k) bits of com .
munication for
Concerning
we observe that the complexities for
and
are the same as for
. For
we have a
round complexity of Θ(1) and communication of Θ(k log p) bits. With a
range of k + 1 ∈ Θ(k) the
has a preprocessing complexity of Θ(1) rounds and Θ(n b k log k log p + k log2 k log p) bits of communi becomes Θ(log(n b +
cation. The processing complexity of
log k) log k) rounds and Θ(n b k log k + k log2 k + k log k log p) bits of communication. This yields a preprocessing total of Θ(1) rounds and Θ((n b +
log k)k log k log p) bits of communication and a processing complexity of
Θ(log(nb + log k) log k) rounds and Θ(n b k log k + k log2 k + k log k log p +
k log(nb + log k) log p) bits of communication.
Due to the security of the two protocols we have
log p ∈ Ω(n a + nb + ρ + log k)
(7.13)
for
and
. If we make the reasonable assumption that
log k ∈ Θ(1) and furthermore assumes that n a = nb = n, these complexities reduce to those listed in table 7.1. This table, even though hiding
many facts, shows that the two division algorithms have equal asymptotics (when ignoring log k). Disregarding the preprocessing, we see that the
number of rounds is logarithmic and bit communication is almost linear in
the bit sizes of the integers to divide. Also, the amount of bits that a single
player sends during division is linear in the total number of participating
players.
4 If
we know that the dividend b is an n-bit number, i.e. the most significant bit in b is set
to 1, we can optimize the division considerably by skipping the subprotocol. This
will be the case, e.g. when performing ongoing computations in a finite field Z p where p is
a secret prime with known bit length.
90
Integer Computation
Chapter 7
protocol
preprocessing
processing
exact
approx
exact
approx
rounds
communication
1
1
log n
log n
kn 2 + knρ
kn2 + knρ
kn log n + kρ log n
kn log n + kρ log n
Table 7.1: Simplified asymptotic complexities for the division protocols
and
assuming that log k ∈ Θ(1) and n a = nb .
Computational Complexity
We first consider
. Preprocessing for the subprotocols
and
both involve O(n b k2 ) multiplications in Z p . Preprocess requires O((n b + log k)k2 ) multiplications in Z p . The
ing for
and
dominating processing complexity comes from
and is O(nb k2 ) multiplications in Z p and O((nb + log k)k2 ) multiplications
in GF(28 ).
In
the truncation is now done by
which has
negligible complexity compared to the other subprotocols. On the other
hand,
has range ∈ Θ(k). This results in the processing taking
O(nb k2 + log(nb + log k)k2 log k) multiplications in Z p . Processing takes
O(nb k2 ) multiplications in Z p and O((nb + log k)k2 log k) multiplications
in GF(28 ).
If regarding log k as Θ(1) both preprocessing and processing for the two
protocols reduce to O(n b k2 ) Z p multiplications.
Translating this to bit operations rather than multiplications in the fields
is done by remembering that multiplication takes O(log 2 p) bit operations
for Z p and O(1) for GF(28 ). Due to the security and overflow considera
tions, we should also replace log p by the expression (7.13) for
and
.
This is all very nice, but how efficient is our division in practice? Does
the constants and the log k terms that are hidden in table 7.1 make division impractical anyway? And does the efficient approximate truncation in
justify the log k increase of the search range for the final quotient? In the next chapter we seek to answer these questions more precisely
by means of practical experiments.
7.5.4 Public Divisor
The division protocols above take as input two secretly shared integers [ a] I
and [b] I and produce a sharing of the integer quotient [r ] I , r = b a/bc. They
Modular Reduction 91
Section 7.6
first compute a sharing of an approximation to 1/b which is then multiplied
with a.
In applications where only a needs to be secretly shared, a much more
efficient division protocol is obtained by having each player locally compute the approximation to the reciprocal 1/b using the Newton-Raphson
method. That is, they could compute the output β̃ of the
protocol
(cf. section 7.5.2) without communication. The players could then compute
[y] I = [ a] I β̃.
Note, that when b is public, the integer 2 m such that 2nb −1 ≤ b2m < 2nb
is also public. The players therefore only need to truncate n b + t − m bits of
[y] I , i.e. they can compute a sharing of the approximation q to b a/bc as
[q] I ←
([y] I , t + nb − m).
In the original protocols with secret b (cf. section 7.5.3 on page 85), 2 m was
secret and the players had to first compute [2 m ] I [y] I and then truncate n b + t
bits.
The only step left is to search for the exact quotient r in the range q ±
(k + 2) (or the range q ± 1 if truncation were done with
) using
, i.e.
[r ] I ←
([ a] I , b, [q] I , 2n a − 1, 2nb − 1, k + 2).
In this way, division with public divisor reduces to local computations followed by one multiplication, truncation and a final binary search for the
exact quotient. In other words, we save the expensive calls to the subpro and
.
tocols
The protocol for integer division with public divisor have not been implemented. Also, we will not go into details about security and complexity.
7.6 Modular Reduction
When computing with integers we sometimes wish to reduce an integer
a modulo another integer b. In this section we discuss how this can be
implemented in a distributed scenario where a and/or b are secretly shared
as [ a] I and [b] I .
If b is public and a is secret, i.e. the players only have shares of [ a] I ,
modular reduction is simply done by having each player Pj reduce his share
modulo b. In other words, each player Pj computes [ a] jI mod b.
As we already have protocols for computing a sharing of b a/bc, where
both a and b are secret shared (section 7.5.3), we can easily create a protocol
for reducing a modulo b when a and b are both secret. This is due to the
fact, that a mod b = a − b a/bcb. Thus, after computing a sharing of b a/bc
92
Integer Computation
Chapter 7
using either the
or
protocol, we simply need one
multiplication and one subtraction to compute a sharing of a mod b.
Another approach for computing a sharing of a mod b when both a and
b are polynomially shared is found in [1]. The protocol in [1] is quite efficient as it only involves two approximate truncations 5 and two multiplications. The protocol does, however, only compute an approximation to the
correct answer. In some applications, such as those in [1], an approximation
suffices.
7.6.1 Protocols Based on Modular Reduction
Given a protocol for reducing a shared integer modulo another shared integer, further protocols for addition and multiplication of two shared values
modulo a third shared value are easily created. It is also possible to create a
protocol for computing the exponentiation of a shared integer modulo another shared integer, i.e. for computing a sharing of a b mod c given sharings
of a, b, and c. The exponentiation is done by running a distributed version
of the classic square and multiply algorithm (see e.g. [29] section 14.6.1). Finally, as pointed out in [1], a modulo protocol also makes it possible to
compute whether a ≡ b mod c, where all integers are shared secrets. In
short, this is done by first computing a sharing of a − b mod c, multiplying
with a sharing of a random non-zero element r ∈ Z p (that none of the players know) and opening the product which will then be random and reveal
no information. This is zero if and only if a ≡ b mod c. A simple protocol
for computing a sharing of a random non-zero element of Z p that none of
the players know is found in [4].
We will not go into any detail about any of these protocols here and we
have not implemented them.
7.7 PRSS and Computational Security
In this chapter we have presented protocols for integer comparison, division, etc. which are statistically secure. We have done this without the
PRSS that is described in chapter 2. We now return to the issue of PRSS and
show how to build protocols based on PRSS which are computationally secure. We will also, based on the subprotocols and the corresponding partial
simulation arguments presented so far, show how to construct complete
protocols, i.e. protocols which securely realize certain ideal functionalities.
Let FDIV be the ideal functionality for k players defined by
5 Using
FDIV ( a, b, ⊥, ⊥, . . . , ⊥) = (q, q, . . . , q)
that we have described in section 7.3.2.
PRSS and Computational Security 93
Section 7.7
with q = b a/bc. That is, in the ideal world, players P1 and P2 send a and b,
respectively, to the trusted third party which in turn computes the integer
quotient q and returns it to all players 6 .
Now, consider the following protocol
for integer division of integers a and b limited by 0 ≤ a < 2 n a and 1 ≤ b < 2nb . Let the underlying
and
subprotocols be as described in chapter 3, i.e. without PRSS.
1. [ a] j ←
2. [b] j ←
3. [q] j ←
4. q ←
(1, a) for some integer a with 0 ≤ a < 2 n a
(2, b) for some integer b with 1 ≤ b < 2 nb
([ a] j , [b] j , n a , nb )
([q] j )
Note that in step 1 and 2, the integers a and b are private input to players
P1 and P2 – the other players do not know a and b; they each only receives
shares of them from player P1 and P2 , respectively.
be the same protocol except that the underlying protocols
Let
and
are replaced by the
and
protocols from section 2.5
which are implemented with PRSS.
Property 7.13. Let ρ be the security parameter. If the field used for integer sharings is Z p for a prime p satisfying
p > max{ R, S}
(7.14)
where R and S are as defined in property 7.12 on page 87, the protocol
securely
realizes the ideal functionality FDIV in the statistical sense. Furthermore, if secure
realizes the same ideal functionality
pseudo-random functions are used,
in the computational sense.
Proof. We first argue that
securely realizes FDIV in the statistical sense.
If p satisfies the constraint (7.14), the subprotocols are known to be secure,
follows immediately
i.e. they are correct and private. Correctness of
from correctness of the subprotocols. Privacy of the subprotocols means
that there exists partial simulators S SSP , S
and SOPEN . Now, given a
real-world adversary, we can construct a simulator S DIV , which will essentially consist of the simulators SSSP , SSSP , S
, SOPEN in sequence. This
simulation combined with the correctness results in
securely realizing
FDIV .
Now, the proof that
is computationally secure, i.e. that it realizes FDIV in the computational sense, is essentially the same as that in
was shown to be computationally secure w.r.t. the
section 2.5.3 where
6 Note
that we here abstract from the random input, the public input (such as the upperbounds n a and nb for the bit size of a and b, and the security parameter ρ) which is – strictly
speaking – also part of the input for the ideal functionality, see chapter 2.
94
Integer Computation
Chapter 7
functionality FSUM . The protocol
is correct for the same reason as
above, i.e. correctness of the subprotocols. In
the players will,
e.g. during
, broadcast values which are not, as in
, completely random, but instead only pseudo-random.
If an adversary A0 and input a0 , b0 exist such that EXEC
,A0 and
IDEALFDIV ,S are computationally distinguishable for all simulators (i.e. in
), we are able to construct a
cluding the simulator S that worked for
polynomial-time algorithm D that distinguishes between true randomness
and (pseudo) randomness from the pseudo-random functions on which the
PRSS is based. For details on how the distinguisher is constructed, we refer
to the proof of property 2.4. The existence of D is a contradiction since the
pseudo-random functions are assumed to be secure.
Remark It should be clear by now, how similar protocols for integer comparison, shifting, etc. can also be proved to securely realize their ideal functionalities, statistically or computationally depending on whether PRSS is
used at the bottom level or not.
Remark Note, that once the pseudo-random generators are securely distributed, the use of PRSS completely reduces the need for confidential communication between the players to broadcast of public information, even
in high-level protocols such as integer division.
We will conclude this chapter with an overview of the complexities of our
integer protocols given the use of PRSS. These complexities reflect the increased efficiency with respect to communication that is due to the basic
and
being non-interactive and
requiring only a single
protocols
broadcast.
Complexity using PRSS
In this section we consider the complexity of our protocols when PRSS is
applied. As noted, apart from system initialization, communication now
consists purely of broadcasts. One player broadcasting an element e ∈ F
is counted as that player sending e to each player, i.e. that player sending
a total of k log |F| bits. Since our communication complexity indicates the
average amount of bits sent from one player, this results in communication
complexity Θ(log |F|).
and
become non-interactive due to
As described in section 2.5,
the
and
protocols. Also,
reduces to one player broadcasting
an element from F. The
boils down to each player broadcasting an
element, i.e. the same as
.
is now non-interactive, conversion from polynomial to addiSince
tive sharings over F is now also for free. Conversion the other way around
PRSS and Computational Security 95
Section 7.7
protocol
,
,
rounds
communication
1
1
0
0
1
1
log |F|
k log |F|
0
0
k log |F|
k log k
Table 7.2: Asymptotic complexity of basic protocols using PRSS.
and hence Θ(k log |F|) bits of communication.
requires k executions of
The
complexity is unaffected, i.e. still constant round and Θ(k log k)
bits of communication.
The complexities for the basic protocols using PRSS are summarized in
table 7.2. It can be verified that the asymptotic complexities of the remaining protocols of this thesis are in fact unaffected by the use of PRSS except
that communication is now public. This is, generally speaking, due to the
complexity is unaffected and that all remaining protocols
fact that the
rely heavily on multiplication.
We should however remember, that using PRSS would improve the
asymptotics to a higher extend if one did not count broadcast of one bit
to k players as k unicasts. Also, the benefit of PRSS would to a higher extend reflect itself in the asymptotics in a model where the communication
channels between players were not secure, i.e. in the cryptographic setting.
In such a setting, secret information must be encrypted resulting in additional Ω(ρ) bits being sent in each round where secret information would
otherwise have been sent. As an example, in the cryptographic setting one
multiplication would require Θ(k log |F| + ρ) bits of communication without PRSS compared to Θ(k log |F|) as is the case when secure channels are
available.
The downside of PRSS is that scalability with respect to the number of
players is lost. As described in section 2.5, a player Pj must during a secret
sharing compute
s j = ∑ r T f T ( j ),
T ∈T : j/
∈T
which involves as many multiplications as Pj has pseudo-random functions, i.e. (k−τ 1) multiplications. Since it is known that
k−1 τ
k−1
≤
τ
τ
we see that this involves Ω(2 k/2 ) multiplications when τ = b k−2 1 c. This
exponential growth in the number of players influences all our protocols
96
Integer Computation
Chapter 7
since they rely on secret sharing. In chapter 8 we discuss experiments with
3, 5, and 7 players, and already for 7 players it turns out that local computation partly becomes the performance bottleneck. One of the reasons for
this probably is that the computational complexity is exponential in k as
argued here.
7.8 Summary
In this chapter we have described several protocols for basic integer operations such as comparison and division. The protocols were presented
hand in hand with arguments for correctness and partial privacy and we
have shown in section 7.7 how the protocols are used in complete protocols realizing certain ideal functionalities. Finally, we have seen how we
obtain increased performance with respect to communication at the cost of
increased communication complexity and a slightly weaker notion of security (computational security) when using PRSS.
Chapter 8
Implementation
8.1 Implementing SMPC
In line with the spirit of experimental algorithmics as pointed out in articles
such as [30] and also captured by D. E. Knuth in a comment from 1977
Beware of bugs in the above code; I have only proved it correct, not
tried it.
we have implemented the protocols treated in this thesis. This section contains a description of the general structure of this implementation; further
details concerning the code are found in appendix B.
8.1.1 The SCET Framework
Our implementation basically consists of extensions to the SCET framework described in [7]. In general, the SCET system provides implementations of secure protocols for some basic operations such as addition, multiplication, creation/opening of Shamir sharings, as well as a protocol for
secret comparison of integers. Our extensions consist of further protocols
for computation on bits and integers 1 . In the following, we describe the
SCET code and our implementation as one entity.
The system is implemented on Microsoft’s .NET platform using the object oriented language C#. As the system is divided into several distributed
components, the .NET Remoting System is applied in order to facilitate
the communication between the components. The .NET Remoting System
communicates via tcp and transparently handles marshalling and unmarshalling of all data to be sent over the network.
1 However,
as one of the authors of this thesis has concurrently been involved in the implementation of the SCET system, there have been some modifications to the SCET system
due to insight gained while writing this thesis, resulting in the boundary between SCET
and the implementation of the protocols of our thesis being somewhat blurry.
98
Implementation
Chapter 8
The components consist of a number of player clients and a central
server component named the coordinator. The coordinator is introduced
in order to manage the initialization of the system as well as the broad
cast that is part of e.g. the
protocol mentioned in the previous chapter. To perform a secure computation, the coordinator must initially be up
and running; then, each player connects to the coordinator. When all players have connected, the coordinator locally generates and distributes the
necessary keys for the
. The sensitive information is encrypted using
standard public key cryptographic techniques. Finally, the actual computation begins. During this phase, the coordinator simply forwards messages
it receives from a player to all players that is connected to the coordinator.
That is, the coordinator merely simulates a network in which broadcast is
available.
Having the coordinator initially compute the keys for each player conflicts with the general goal of avoiding a single point of trust. The reason for
doing this anyway is simplicity. Our intention is to implement and benchmark the performance of certain protocols, not the setup of the system. The
single point of trust can be eliminated by having the players initially run
using the basic SMPC
protocols that generates the random keys for
techniques of chapter 3.
Figure 8.1: Structure of the SCET system.
The Arithmetics Layer
Figure 8.1 depicts the overall structure of the components. At the bottom
there is a layer containing logic for performing arithmetic operations on
large integers as well as in fields such as Z p and GF(28 ). Such logic is
Section 8.1
Implementing SMPC
99
necessary in order to manage the local shares mentioned in the previous
chapters. The logic for computing on large integers (multiple precision
, written by Chew Keong TAN 2 .
arithmetics) is based on a class,
This implementation is based on efficient algorithms such as Barrett’s Reduction [29] for modular reduction and exponentiation of large integers.
A class representing an element of Z p is implemented on top of the
class using its modular reduction method to reduce modulo
the prime p after each operation. We have modified the implementation
of
such that the constant used for Barrett’s Reduction is computed only once, making computations modulo p more efficient. Elements
of GF(28 ) are represented by single bytes, and addition of these elements
are simply bitwise of the bytes. Multiplication in this field is implemented using table lookup.
The Primitives Layer
While the arithmetics layer is common to all components, the primitives
layer contains separate logic for the players and the coordinator, respectively. At the side of the players, this layer contains the implementations
,
, etc. Here, each player also
of the various protocols, such as
keeps its individual shares in a hash table. At the coordinator, this layer
contains logic for generating the initial keys and for forwarding messages
during computation. The process of forwarding messages is synchronized
meaning that all player processes must hand-shake before proceeding. The
implementation of this is straightforward as the .NET Remoting system
provides ready-to-use functionality for synchronous remote method invocation.
Many of the protocols at this layer work with any kind of field element
as long as the implementations of such elements implement a common interface capturing the basic properties of field elements. This layer contains
the major part of the extensions according to this thesis.
As explained, a player broadcasts a message by sending this to the coordinator which, in turn, forwards it to all players. During the first stages of
our thesis we considered implementing the primitives layer in such a way
that each player instead had direct communication channels to the other
players. Broadcasting a message would then simply require a player to
send that message to each of the other players. One could expect this to
cause less communication overhead since broadcast of an n-bit message to
k players would then result in only kn bits traveling through the network in
one turn and not n + kn bits in two turns due to the round-trip to the coordinator. However, to save time and because the “no-coordinator”-solution
would probably complicate implementation and debugging, we chose to
2 See
!"!$#
%
&
%
'$ .
100
Implementation
Chapter 8
use the already existing code from SCET, i.e. the “coordinator”-solution.
The API and Engine Layers
One way of specifying a secure computation is to have a class implement
a certain interface, , which gives direct access to the protocols in
the underlying primitives layer. However, a feature of the SCET system is
that it allows secure computations to be specified in a script language, thus
avoiding further recompilation. Currently, the script language is simply an
ECMAScript variant, JScript, with certain restrictions on its form. However,
this is likely to be replaced sometime in the future by a domain specific
language, making the management of secret sharings in combination with
ordinary computations easily comprehensible.
On top of the primitive operations, the engine layer is responsible for
parsing such scripts and invoking the relevant protocols in the primitives
layer accordingly. The API layer simply provides a final interface of the
system towards applications.
8.1.2 Benchmarking Protocols
In order to benchmark the performance of our protocols we have set up
a benchmark scenario (see figure 8.2), resembling – to a certain degree – a
real-world situation. In this scenario, the coordinator and all players except
one are run on individual computers connected via the campus LAN at
DAIMI3 . The last player is instead run from a computer situated at one
of the author’s home addresses, connected to the coordinator via a vpn
connection over the Internet.
Figure 8.2: The benchmark setup for 5 players.
3 The
Department of Computer Science, University of Aarhus.
Section 8.2
Performance Results 101
As the protocols are synchronous and the players hence must wait on each
other in each round, we believe that this setting to some extend reflects the
real-world situation where all players are spread on different locations and
connected by the Internet.
The computers at DAIMI were all equipped with 2GB RAM and 3.1GHz
dual core Pentium processors and the Windows XP Pro operating system.
The computer at the author’s home had 512MB RAM, a 1.7GHz Pentium
processor, a 2048/256 Internet connection, and the Windows XP Pro operating system.
Measuring performance of distributed applications is inherently problematic: The exact execution time depends of various uncontrollable factors
such as packet loss rates, current network traffic, changing router strategies, etc. However, we believe that our benchmarks still provide reasonable
results on which to base further conclusions.
Only the execution time of a protocol itself is measured, thus excluding the time it takes to initialize the whole system. Each benchmark is
repeated several times in order to reduce variance. Furthermore, we sometimes benchmark the individual steps in protocols in order to gain additional insight, a technique that is referred to as splitting, see [28].
8.2 Performance Results
We now present the results of our performance benchmarks; appendix A
contains additional information about these. Based on the results we discuss and compare some of the various alternative protocols that we have
and
for bidescribed for the same task, e.g.
nary addition,
and
for division, etc.
Each benchmark consists of an experiment which is run in three settings
referred to as (3,1), (5,2) and (7,3). Setting (7,3) means e.g. that the system
have been set up with 7 players and threshold τ = 3, cf. chapter 2. All
experiments are carried out with ρ = 30. Furthermore, each experiment
have been repeated a number of times to reduce variance. This allows us to
accompany our results with 95%-confidence intervals depicted as vertical
errorbars in the graphs. In some cases we fit the data to certain functions
using the fit functionality of GNUPLOT and list the corresponding asymptotic standard error.
The reason for keeping ρ fixed throughout this chapter while investigating the other free parameters, usually the number of players (k) and the bit
size (n), is to keep the number of benchmarks and hence our time spent setting up and running benchmarks at a reasonable level. Also, for most of the
protocols, we roughly expect the effect of increasing the security parameter
to be upper-bounded by the effect of increasing n with the same amount.
E.g. for division and comparison, the main effect of increasing ρ with, say, δ
102
Implementation
Chapter 8
is that the size of Z p increases. However, the size of Z p increases at least as
much when n increases with δ and furthermore, many of the subprotocols
must do considerably more work when n increases, e.g. splitting more bits,
etc.
During execution of the benchmarks, we have used Windows Performance Counters to measure processor work load, memory usage, etc. of
the involved computers. This was done in order to determine the performance bottlenecks. In the (3,1) and (5,2) settings, network capacity turned
out to be the bottleneck whereas processing power (on the slowest computer) and network capacity in combination seemed to be the bottleneck in
the (7,3) setting. This should be kept in mind when analyzing the results.
8.2.1 Basic Protocols
Some of our basic protocols are non-interactive, e.g.
,
,
, and
. The execution of such protocols involves only local operations at each
player such as e.g. multiplication of two field elements and storage of field
elements in a local hash table for further reference. Therefore, we expect
their execution time to be negligible compared to protocols involving communication, and hence we have not bothered to measure them.
The remaining basic protocols require only a small fixed amount of
and
protocols involve broadcast from a
communication. The
single player whereas
requires each player to perform a broadcast. We
have focused on benchmarking the variants of the
protocol based on
the assumption that
and
require time that is not too different from
that of
.
Performing, say, n independent operations such as e.g. multiplication
concurrently during one round using e.g.
is expected to take less
time than executing the same operations in n consecutive rounds. So, aside
from giving an idea of the execution time for the basic operations, our first
benchmark is also designed to determine to what extent parallel protocol
execution pays off.
We have set up an experiment measuring the execution time for doing 5, 10, 15, . . . , 50 multiplications in sequence as well as in parallel. This
was done for both multiplication in GF(2 8 ) and in Z p for p being a 65-bit
prime4 . The experiment carries this out for both 32-integer multiplications,
i.e. multiplications in Z p for a 65-bit prime p and for multiplications of elements in GF(28 ).
Figure 8.3 shows the resulting execution times for the (3,1) setting. The
graphs for the other settings are omitted since they look quite similar ex4 Choosing p as a 65-bit prime allows for multiplication and comparison of 32-bit integers
without overflow and with reasonable security in the comparison (ρ = 30) and is thus
considered to be sufficient for many practical purposes. We will later present benchmarks
covering varying sizes of p.
Performance Results 103
Section 8.2
2.5
Zp sequential
GF(256) sequential
Zp parallel
GF(256) parallel
avg time in sec
2
1.5
1
0.5
0
5
10
15 20 25 30 35
number of multiplications
40
45
50
Figure 8.3: Parallel versus sequential multiplication for 3 players.
field
setting
Zp
(3,1)
(5,2)
(7,3)
GF(28 )
(3,1)
(5,2)
(7,3)
a seq
bseq
a par
b par
45.6 ± 0.0
49.4 ± 0.4
70.1 ± 0.2
−0.1 ± 1.1
−15.3 ± 13.
−4.4 ± 7.3
3.3 ± 0.1
8.0 ± 0.4
29.4 ± 0.5
43.4 ± 4.1
51.7 ± 12.
48.4 ± 14.
41.1 ± 0.0
44.4 ± 0.9
45.8 ± 0.3
−3.1 ± 1.0
−33.3 ± 25.
−15.3 ± 8.0
1.1 ± 0.0
2.5 ± 0.0
6.4 ± 0.3
37.5 ± 2.0
45.0 ± 3.0
50.6 ± 9.6
Table 8.1: Timings for multiplication in milliseconds (± is std. error).
cept that the time range on the left is increased. As expected, multiplication
in GF(28 ) is faster than in Z p . Also, parallel execution is seen to be indeed
much faster than sequential. This justifies our efforts to construct protocols
with parallel execution of subprotocols. We also note that in both the parallel and the sequential case, there is a strong linear relationship between
the number of operations and the resulting execution time. This suggests
that we describe the time required to execute x operations as
f ( x ) = ax + b
for certain constants a and b, which will likely depend on characteristics of
the underlying network. Table 8.1 summarizes the constants a and b for all
settings (3,1), (5,2), and (7,3). Note, that when the number of players grows,
the relative increase of the slopes for sequential multiplication is about the
104
Implementation
Chapter 8
same for GF(28 ) and Z p multiplications. For parallel multiplication, however, Z p multiplications for 7 players takes 8.9 times as long as for 3 players
while GF(28 ) multiplications for 7 players only take 5.8 times as long as for
3 players. This is probably due to the fact, that local CPU capacity becomes
part of the bottleneck for parallel multiplications for 7 players; the CPU capacity sooner becomes the bottleneck for parallel Z p multiplications since
they require more local processing power to carry out than multiplications
in GF(28 ).
8.2.2 Binary Addition
In chapter 5 we presented both the ripple-carry and the prefix technique for
binary addition. As argued there, prefix addition requires only a number
of rounds that is logarithmic in the bit length of the number to add, but
involves twice as many multiplications as the ripple-carry solution.
We have benchmarked both protocols for additions of numbers with
varying bit size. In order to measure the effect of the optimization discussed in section 6.2.3, i.e. where one of the numbers to add is public, we
have benchmarked both protocols in two flavors which is referred to as
type A and type B, respectively. Type A means that both numbers to add
are secretly shared while type B means that one of them is public.
Figure 8.4 shows the result for the (5,2) setting. From the graph we
see that prefix addition pays off for addition of large numbers. Here, the
benefit of parallel execution is clearly superior to the factor 2 in number of
multiplications. The graphs for the (3,1) and (7,3) settings reveal the same
tendency, but of course with different execution times (for these results,
consult appendix A).
The (5,2) benchmark also reveals that addition with one of the numbers
being public does not seem to speed up the prefix addition significantly
contrary to the case of the ripple carry solution. But prefix addition of two
secret numbers is still faster than ripple carry addition with one public integer when the bit size is around 8 bits or more. For the (3,1) and (5,2)
settings, the prefix solution turns out to be superior for addition of more
than 8-10 bits. In the (7,3)-setting (see appendix A), the intersection of the
graphs for ripple-carry and prefix addition is less clear, but it seems that
prefix addition is superior for addition of more than 8 bits when both numbers are shared and for addition of more than 20 bits when only one of the
numbers is public. The fact that the intersection seems to “move” to the
right when k increase is probably due to the fact that the communication
overhead for e.g. a multiplication becomes more expensive relative to the
cost of rounds when k increase.
This benchmark shows that prefix addition indeed scales better for large
as subprotocol in our adn and thus justifies that we use
vanced protocols rather than
. However, in situations where
Performance Results 105
Section 8.2
3.5
3
Ripple Carry A
Ripple Carry B
Prefix A
Prefix B
avg time in sec
2.5
2
1.5
1
0.5
0
10
20
30
40
bit size
50
60
Figure 8.4: Binary Addition (A=both secret, B=one secret), (5,2) setting.
k is large, n small, and one of the numbers is public, it might be preferable
use ripple-carry addition.
8.2.3 Splitting Bits
Chapter 6 was concerned with protocols for securely splitting integers into
bits and two quite different approaches,
and
, were developed. The aim of our next benchmark is to determine which of those are
superior and to give some insight with respect to the relative time consumption of the individual steps in the protocols.
splits a polynomial sharing into bits whereas
starts
The
off with an additive sharing over the integers. In order to provide a fair
comparison and since we are really interested in splitting polynomial sharings, we have included the execution time for converting from polynomial
to additive sharings over the integers, i.e. execution of
and
, in
the execution time for
.
From section 6.2.5 we know that
, when doing preprocessing
and processing together, requires Θ(log n) rounds and Θ(kn 2 + nkρ) bits of
communication for completely splitting n bit integers. In contrast,
requires Θ(log k + log n) rounds but Θ(k 2 n) bits of communication. For
we must also remember the conversion from a polynomial to an
additive sharing using
and
. This leads to a communication
complexity of Θ(k2 n + kρ + k log k), since
is Θ(k log p) with log p ∈
2
Ω(n + ρ + log k). Roughly speaking, the k factor for
is due to the
binary addition of k bit sharings whereas the n 2 in
comes from the
106
Implementation
protocol
round
communication
processing
1
log n
kn2 + knρ
kn + kρ
incl. conversion
log n + log k
k 2 n + kρ + k log k
preprocessing
Chapter 8
Table 8.2: Asymptotic complexities for splitting bits.
somewhat heavy working with shares over Z p during the preprocessing
phase. This is summarized in table 8.2.
Figure 8.5(a) shows execution times for splitting all bits in polynomi and
ally shared integers of various bit sizes using 1) conversion +
2) the
solution including preprocessing. We see that for the given
is superior in the (3,1) setting while
bit range (2-96 bits),
performs best in the (7,3) setting. In the (5,2) setting, the two protocols
show almost the same performance. Inspecting carefully the graphs for
is best for approximately 2-64
for 5 players, though, it seems that
bits but gets outperformed by
for larger bit sizes. This behaviour
is expected due to the above asymptotics:
is quadratic in the bit
size and will eventually be less efficient than
for large bit sizes. But
since
scales worse than
when the number of players k increase, the “crossing point” moves to the right as k increases. For k = 3 the
point is somewhere “before” 2 bits, for k = 5 approximately at 64 bits, and
for k ≥ 7, the crossing point probably is at a bit size much larger than the
96 bits that we have benchmarked.
For a fair comparison we should take into account that much of the exe cution time for
consists of preprocessing that is independent of the
integer to split. If we ignore the preprocessing,
has no n 2 factor and
the picture now looks as in figure 8.5(b) where
is definitely supe be used as subprotocol instead
rior. This benchmark suggests that
of
.
8.2.4 Integer Protocols
We now turn to benchmarks of the protocols for comparison and division
of integers.
Comparison
when
The preprocessing for an n-bit comparison is the same as for
splitting n + 1 bits. Regarding the processing, we note that the only dif
ference between
and comparison is that where the comparison pro tocol simply calculates the “-sum”,
computes all prefix “-sums”
Performance Results 107
Section 8.2
10
9
8
I2QBIT (7,3)
P2QBIT (7,3)
I2QBIT (5,2)
P2QBIT (5,2)
I2QBIT (3,1)
P2QBIT (3,1)
avg time in sec
7
6
5
4
3
2
1
0
10
20
30
40
50
60
70
80
90
80
90
bit size
(a) Incl. P2QBIT preprocessing.
10
9
8
I2QBIT (7,3)
P2QBIT (7,3)
I2QBIT (5,2)
P2QBIT (5,2)
I2QBIT (3,1)
P2QBIT (3,1)
avg time in sec
7
6
5
4
3
2
1
0
10
20
30
40
50
bit size
60
70
(b) Excl. P2QBIT preprocessing.
Figure 8.5: Execution time for splitting bits.
(see section 7.2). Both require logarithmic rounds and linear communication, but communication for comparison is faster by a factor of 2. Figure
8.6(a) and 8.6(b) show the preprocessing and processing time for comparison, respectively. As expected, preprocessing time is seen to grow faster
than linear when bit size increase. Compared to figure 8.5(b) we see that
comparison is indeed faster than splitting bits, but not asymptotically.
108
Implementation
3.5
(7,3)
(5,2)
(3,1)
3
2.5
avg time in sec
avg time in sec
Chapter 8
2
1.5
1
0.5
0
10
20
30
40
50
60
integer bit size
(a) Preprocessing.
1.3
1.2
1.1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
(7,3)
(5,2)
(3,1)
10
20
30
40
50
60
integer bit size
(b) Processing.
Figure 8.6: Execution time for comparison.
Division
Our next benchmark is concerned with the final division protocols. Figure
8.7(a) shows execution time for division including the time for preprocessing while figure 8.7(b) shows the same, but without preprocessing. We see,
that except for bit sizes less than approximately 10 bits,
is ge
; e.g. ignoring preprocessing, division of two
nerally superior to
64-bit integers takes approximately 12 and 16 seconds in the (5,2) setting
for
and
, respectively.
Preprocessing versus Processing
The absolute time spent on processing and preprocessing of course increases when the number of players k and the bit size n increase. However,
as well as
there is a clear
figure 8.8 reveals that for
tendency that also the fraction of the total execution time spent on preprocessing grows when n and k increase. Since preprocessing for fixed k has
communication complexity O(n 2 ) while processing has only O(n log n)
this relative increase is expected when the bit size increases. The simplified
asymptotics in table 7.1 on page 90 state that both preprocessing and processing are linear in k. However, figure 8.8 suggests that there are quite different slopes for the linear growth of preprocessing and processing. Also,
we should remember that the computational complexity is exponential in k
which probably affects the results of the (7,3) benchmark where CPU usage
is known to be part of the bottleneck.
Generally, figure 8.8 tells us that quite a lot of the time is spent preprocessing; for large n and k preprocessing even takes more time than the
actual processing. Looking carefully at the figure, we see that in the (3,1)
and (7,3) settings,
generally spends more of its time doing pre processing than
while in the (5,2) setting the difference is less
alevident. Part of the explanation for this probably is that
Performance Results 109
Section 8.2
55
DivExact (7,3)
DivApprox (7,3)
DivExact (5,2)
DivApprox (5,2)
DivExact (3,1)
DivApprox (3,1)
50
45
avg time in sec
40
35
30
25
20
15
10
5
10
20
30
40
integer bit size
50
60
50
60
(a) Incl. preprocessing.
35
DivExact (7,3)
DivApprox (7,3)
DivExact (5,2)
DivApprox (5,2)
DivExact (3,1)
DivApprox (3,1)
30
avg time in sec
25
20
15
10
5
0
10
20
30
40
integer bit size
(b) Excl. preprocessing.
Figure 8.7: Integer division.
110
Implementation
Chapter 8
60%
50%
40%
16 bit
32 bit
64 bit
30%
20%
10%
0%
exact
(3,1)
approx
(3,1)
exact
(5,2)
approx
(5,2)
exact
(7,3)
approx
(7,3)
Figure 8.8: Fraction of total division time spent on preprocessing.
ways does 2 comparisons in
while 2 + blog(k + 1)c is needed
in
. Thus, the number of comparisons and hence the relative
and while 3
amount of preprocessing increases stepwise for
and 5 players belong to the same “level”, 7 players is on the next.
Division Subprotocols
Figure 8.9 shows execution times for the individual subprotocols for division in the (3,1) setting without preprocessing. Similar figures for the (5,2)
and (7,3) settings are found in appendix A. The graphs are cumulative in
the sense that e.g. the label
shows the execution time up to and in
subprotocol. Since
is the last subprotocol of
cluding the
division, the graphs for
thus are the total execution time for the
division. As expected,
spends more time doing binary search,
but the benchmark shows that this is outbalanced by the much more effi cient truncation protocol. The
and
subprotocols take almost
and
since they essentially do the
the same time in
same job.
Perhaps the most interesting subprotocol in the division is the
protocol for approximating the reciprocal 1/b. We know from section 7.5.2
that this protocol requires O(log t) rounds and O(k log t log p) bits of communication where t is the parameter that determines the quality of the
approximation. Figure 8.2.4 shows execution time in the (5,2) setting for
for a fixed 32-bit integer and increasing t. Since for fixed k, rounds
and communication are logarithmic in t (and since local CPU usage is only
bottleneck in the (7,3) setting), it makes sense to fit execution time to a function f ( x ) = a ln ( x ) + b. Table 8.3 shows the resulting functions for all three
settings. Note the staircase increase; this is due to the fact that the number
of iterations is given by the integer function dlog(t − 3 − log(k + 1))e.
Summary 111
Section 8.3
avg time in sec
12
12
BINSEARCH
TRUNC
10
APPINV
CALC2M
8
10
8
6
6
4
4
2
2
0
BINSEARCH
TRUNC
APPINV
CALC2M
0
10
20
30
40
50
60
10
20
30
integer bit size
(a) 40
50
60
integer bit size
(b) Figure 8.9: Division in (3,1) setting excl. preprocessing.
5
APPINV
1.49*ln(t)-1.65
avg time in sec
4.5
4
3.5
3
2.5
2
1.5
1
10
15
20 25 30 35 40
approximation parameter (t)
Figure 8.10: Execution times for
setting
(3,1)
(5,2)
(7,3)
45
50
, (5,2)-setting.
execution time (seconds)
1.20 ln(t) + 0.32
1.49 ln(t) − 1.65
2.18 ln(t) + 0.27
Table 8.3: Fitted execution times for
(seconds).
8.3 Summary
We have given an overview of the SCET framework and presented the
setup and results of our benchmarks. The benchmarks are meant to give
realistic ideas of the execution times of the protocols as well as to determine which of the alternative protocols for doing the same job that are the
112
Implementation
Chapter 8
most efficient.
We have seen in this chapter that division is indeed possible within a
reasonable amount of time, at least for some applications.
Chapter 9
Concluding Remarks
In this thesis we have treated various protocols for integer computation.
In chapter 2 we introduced the concept of SMPC, the security model, and
some basic constructs such as schemes for secret sharing. Chapters 3-7 have
covered the construction of the various protocols as well as proofs of security and complexity analysis. In chapter 8 we have presented and discussed
the performance results of the protocols based on a prototype implementation.
The main conclusion is that construction of secure protocols for integer
computations that are efficient enough for many real-world applications
is indeed possible. This comes in spite of the fact, that almost everything
tends to become very complicated when applied in the context of secure
multi-party computation. E.g. we have seen that securely shifting down an
integer a couple of bits is neither as simple nor efficient as locally shifting
down an integer on a single computer. It should be noted, however, that
execution time of the protocols is probably still to long for some applications, especially real-time applications.
In the following sections we will briefly describe the process that we have
been through during creation of our thesis. Furthermore, we will discuss
some ways in which this work could be extended, and finally we briefly
mention some possible applications of our SMPC protocols.
9.1 Process Overview
The creation of this thesis can be divided into three “modes”, namely 1)
understanding of the existing protocols and development of ideas for new
protocols, 2) implementing and benchmarking of these protocols, and 3)
writing this report. Throughout the project we have worked in those modes
concurrently and progress in one mode has often lead to understanding
and progress in another mode.
114
Concluding Remarks
Chapter 9
Initially, our focus was on implementation and comparing two existing
strategies for securely generating a distributed RSA modulus [1, 8]. Along
the way, we decided to change the focus to development of protocols for secure integer computation with focus on division. We considered this to be
more exciting since it would involve our own development of some subprotocols. The change was obvious since those protocols from [1] which
we had already implemented were well suited as subprotocols for division. Also, we already had access to the implementation of the protocol for
integer comparison from the SCET project.
In the process we have followed several trails, some more fruitful than
others. The main part of this report covers the nice results. Some less fruitful trails include the implementation of a communication model with the
players being directly connected, i.e. without the coordinator. Also, we
have spent time developing carry look-ahead protocols for binary addition
with Θ(n2 ) communication. At a certain stage, we considered “decimal”
sharings instead of binary sharings; that is, splitting an integer into sharings of its decimal digits over Z q for some small prime q instead of its bits.
In this way, a 32-bit integer would only have to be split into about 10 digits.
But it turned out that this approach only complicated our design without
resulting in any performance advantages.
9.2 Future Work
A main drawback of our prototype implementation is that performance
does not scale well as the number of players increase. The experiments described in chapter 8 show that performance quickly drops as the number of
players grows. Part of this is probably due to the computational complexity of the PRSS technique which as noted in section 7.7 is exponential in the
number of players1 . While distributing the trust among a relatively small
number players may suffice for some applications, this may limit the usage
in other contexts. It could be interesting to investigate techniques allowing
trust to be distributed among a larger number of players.
Another limitation is due to our security model: In many applications
protocols are required to be secure against an active adversary. As mentioned in section 2.2.3 on page 14 there exist standard techniques that could
be applied to our protocols in order to make them secure in the active adversary model. However, these techniques tend to decrease performance of
the protocols. Future work could be to further investigate the cost of applying these standard techniques. Also, the protocols presented in this thesis
generally require honest majority, i.e. that τ < b(k − 1)/2c. A stronger
1 Without
PRSS, however, we would need to encrypt the communication and some basic
protocols would require more communication, probably causing the protocols to be too
inefficient even for few players.
Section 9.3
Applications 115
notion of security would be self-trust, meaning that τ = k − 1.
Due to e.g. the security, our protocols for division require the field Z p
for representing integers to be much larger than the integers which are to
be divided. E.g. the division of two 32-bit integers with ρ = 30 using the
protocol requires a 172-bit prime p for the field Z p . As seen
in chapter 8 execution time certainly depends on the size of the field. Efficiency could be increased if one could find ways to e.g. divide integers
using smaller fields.
In section 7.5.4 we discussed how to increase performance of division
when the divisor is public. One could imagine that optimizations also exist
if instead the dividend is public. We have, however, not had the time to
investigate this. The Newton-Raphson iteration used in our division protocols is just one example of functional iteration. Other kinds of functional
iteration, such as e.g. Goldschmidt’s algorithm that is based on Taylor series expansion, exist. One could imagine that some of these might have
properties that could lead to increased performance in our setting. In [32]
an overview of different algorithms, including Goldschmidt’s algorithm,
for division in given.
Finally, we note that the current prototype ignores several issues such
as key handling, authentication of players, etc. which would be necessary
in an industrial application.
9.3 Applications
Throughout the years, the use of SMPC in real-world applications has been
very limited due to the major draw back that the results for SMPC have
been to general, thereby causing the implementations of specific problems
to be too impractical and slow to be used in practice. Recently though, more
efficient protocols for SMPC problems have been developed, thus making
it possible to create useful and effective industrial applications.
We will here give a short introduction to some of the possible applications
for which the integer protocols in this thesis might prove useful.
9.3.1 Secure Auctions
From economics it is known that several kinds of auctions and trading
mechanisms involve a trusted party (also known as a mediator or “social
planner”) for carrying out computations on private data from the participating parties. The private data could e.g. be the total amount of goods
or money that the participants in an auction possess. A participant in an
auction generally does not want to reveal such information and yet, the
optimal parameters of the auction might depend on such information.
116
Concluding Remarks
Chapter 9
Since such a trusted party is either very expensive to establish or does
not exist at all, the SMPC techniques could be an alternative.
In fact, the SCET research project [36, 7] has focus on emulating such
a trusted third party for a specific kind of auction called a double auction
using SMPC. As explained in [36] the double auction can be implemented
solely on basic integer arithmetics and integer comparison. One could easily imagine other applications in economics involving integer division.
9.3.2 Privacy-Preserving Distributed Datamining
The field of datamining is concerned with the extraction of valuable knowledge from large databases. Sometimes these databases are distributed
among several organizations. Privacy-preserving distributed datamining
deals with techniques that allow the organizations to carry out datamining
on the complete database without the organizations having to reveal their
individual parts of the database. The following examples are from [3].
Imagine a collection of hospitals that wish to compute the average number of medical operations that have caused death due to mistakes during
the operation. Each hospital might want to keep such information confidential and yet each hospital is interested in comparing its own “death”rate to the average rate. Protocols for such datamining could be implemented using SMPC with simple integer addition and division.
Privacy-preserving distributed datamining also relates to the field of
private collaborative forecasting [3], where companies collaborate in order to
compute e.g. future customer demands. As an example consider the following case: A number of small companies and a giant company are in
the same line of business. On their own, the small companies will, unlike the giant company, not have enough information to make a precise
market analysis of future customer demands on which they can base future production rates and thereby minimize their expenses and increase income. However, if they collaborate and pool together their customer data
collected over a period of time they will be able to compete with the giant company. The problem is though, that none of the small companies
are interested in revealing sensitive information to the other small companies, since they are still competitors in the same market and revealing trade
strategies to the other small companies does not improve their chance of
survival. The collaborative forecasting can be implemented using SMPC
techniques in such a way that the companies can keep their data private
and one could also in this case imagine that integer division could prove
useful.
Section 9.3
Applications 117
9.3.3 Games
Several games also rely on a trusted party, e.g. for shuffling cards, etc. Distributed games such as Internet Casinos are becoming popular. In this
kind of distributed games the trusted party is essentially the casino itself.
Usually, players have enough trust in the provider of the online casino, but
as we have seen, SMPC makes it possible to distribute the trust on more
than one party, e.g. the casino, the players, and maybe other parties.
Appendix A
Further Experimental Results
This appendix contains some additional results from our benchmarks. The
results are presented without further interpretation. The tables A.1 and A.2
and
summarizes the average execution time for division using
, respectively.
integer
bit size
8
16
32
64
3 players
pre proc
5 players
pre proc
0.83
1.23
2.29
5.07
1.12
1.98
3.63
8.90
4.84
5.90
7.16
9.06
5.87
7.26
9.15
12.28
Table A.1: Average execution time for
integer
bit size
8
16
32
64
5 players
pre proc
0.88
1.33
2.23
5.07
1.40
2.13
3.68
8.89
5.87
7.70
10.36
15.99
Table A.2: Average execution time for
3.46
6.05
11.94
28.43
3 players
pre proc
4.74
6.02
7.73
11.02
7 players
pre proc
8.68
10.95
14.77
21.74
(seconds).
7 players
pre proc
3.23
4.77
9.64
23.27
8.42
11.74
17.19
30.78
(seconds).
In section 8.9 on page 111 cumulative graphs for division in the (3,1)-setting
were shown. Figures A.1 to A.4 provide the same figures in the (5,2) and
(7,3) settings.
120
Further Experimental Results
avg time in sec
25
Appendix A
25
BINSEARCH
TRUNC
20
APPINV
CALC2M
20
15
15
10
10
5
5
0
BINSEARCH
TRUNC
APPINV
CALC2M
0
10
20
30
40
50
60
10
20
integer bit size
(a) 30
40
50
60
integer bit size
(b) avg time in sec
Figure A.1: Division, (5,2) setting, incl. preprocessing.
18
18
16
16
10
10
8
8
6
6
4
4
2
2
BINSEARCH
TRUNC
APPINV
14
CALC2M
12
BINSEARCH
TRUNC
APPINV
14
CALC2M
12
0
0
10
20
30
40
50
60
10
20
integer bit size
(a) 30
40
50
60
integer bit size
(b) Figure A.2: Division, (5,2) setting, excl. preprocessing.
avg time in sec
60
60
BINSEARCH
TRUNC
50
APPINV
CALC2M
40
50
40
30
30
20
20
10
10
0
BINSEARCH
TRUNC
APPINV
CALC2M
0
10
20
30
40
50
60
10
20
integer bit size
(a) 30
40
50
60
integer bit size
(b) Figure A.3: Division, (7,3) setting, incl. preprocessing.
A graph for binary addition using
and
was
shown in the (5,2)-setting in section 8.4 on page 105. The graphs in figure A.5 provide the results for the same benchmarks in the (3,1) and (7,3)
settings.
121
35
35
30
30
20
20
15
15
10
10
5
5
BINSEARCH
TRUNC
APPINV
CALC2M
25
BINSEARCH
TRUNC
APPINV
CALC2M
25
0
0
10
20
30
40
50
60
10
20
integer bit size
(a) 30
40
50
integer bit size
(b) Figure A.4: Division, (7,3) setting, excl. preprocessing.
3.5
3
Ripple Carry A
Ripple Carry B
Prefix A
Prefix B
avg time in sec
2.5
2
1.5
1
0.5
0
10
20
30
40
bit size
50
60
50
60
(a) The (3,1)-setting.
6
5
avg time in sec
avg time in sec
Section A.0
Ripple Carry A
Ripple Carry B
Prefix A
Prefix B
4
3
2
1
0
10
20
30
bit size
40
(b) The (7,3)-setting.
Figure A.5: Binary Addition, A=both secret, B=one public.
60
Appendix B
The Code
The prototype implementation described in chapter 8 as well as the related
source code are found on the CD that accompanies this report. Alternatively, this can be downloaded from
∼
where instructions for running and/or compiling is also found. As earlier mentioned, the prototype including the protocol for integer comparison was originally developed as part of the SCET research project and have
subsequently been extended with the remaining protocols described in this
thesis. The source code is far too extensive to go through here. Instead we
will list and explain some selected pieces of code illustrating some key features of the implementation. When doing this, we have taken the liberty to
leave out some aspects and change the naming to better fit the terminology
of this report. Therefore, the reader should not expect this code to run or
even compile if cut-n-pasted directly from this report. Instead the reader is
referred to the real code which also contains further explanation.
B.1 Field Arithmetics
All code concerned with the implementation of the protocols is contained
which is bundled with both the player and coordinain tor applications. The implementation of the protocols rely on implemen tations of elements in Z p and GF(28 ). An interface
defines
the functionality needed for such elements. The following code shows the
essential part of this interface.
The methods ,
, , , and carry out the basic
field operations. In order to avoid synchronization issues the field element
objects are kept immutable. That is, the methods do not alter the object on
which they are invoked, but instead returns the results as new objects.
124
The Code
Appendix B
In order to keep the protocol implementations as independent of the
actual field implementations as possible, a factory approach is taken. This
means that the remaining methods create various kinds of elements while
hiding the actual field: If a player holds an element e, he can use this element to create new elements of the same type while the actual field type
remains hidden behind the interface.
The and methods thus return the additive and multiplicative
identities. Also, since field elements are sometimes used to index the players, we need a way to obtain indexing elements. Such elements are ob
method. To obtain an element
tained by calling the for indexing, say, player 3, one calls where is an arbitrary element of the desired type. A Z p factory
will then return 3 mod p while a GF(28 ) factory will return a unique element based on some other ordering, e.g. the lexicographic ordering of the
string representation of the GF(28 ) elements. Finally, there is also a method
for generating a random element given a pseudo-random function and a
unique id of a sharing. As described in section 2.5 this is necessary in order
to create random sharings using the PRSS technique.
1
6
namespace SmcLibrary . A r i t h m e t i c s
{
public i n t e r f a c e I F i e l d E l e m e n t
{
/ / immutable f i e l d o p e r a t i o n s
I F i e l d E l e m e n t Mult ( I F i e l d E l e m e n t e ) ;
I F i e l d E l e m e n t Add( I F i e l d E l e m e n t e ) ;
IFieldElement Inverse ( ) ;
I F i e l d E l e m e n t Negate ( ) ;
I F i e l d E l e m e n t Power ( i n t p ) ;
11
16
}
}
/ / f a c t o r y methods
I F i e l d E l e m e n t Zero ( ) ;
I F i e l d E l e m e n t One ( ) ;
I F i e l d E l e m e n t GenerateIndexElement ( i n t i d ) ;
I F i e l d E l e m e n t GenerateRandomElement ( AesKey key , i n t i d ) ;
B.2 A Simple Protocol
To give a feeling about the implementation of our protocols we describe the
for openimplementation of a simple protocol, namely the protocol
ing a polynomial (Shamir) sharing. The theory behind this is described in
chapter 3.
In each of the player applications the shares of the secrets, including
intermediate sharings, are managed by associating each sharing with an
integer and by storing shares in a hashtable, , with this id as key.
Also, a player is equipped with an “id dispenser”, i.e. an object that is re-
A Simple Protocol 125
Section B.2
sponsible for delivering fresh, unused ids for new sharings.
Each player also has a field, , which is a reference to the
remote coordinator object. Once this remote reference is established, the
.NET Remoting system takes care of marshalling etc., making remote invocation of methods at the coordinator look like standard local method
invocations.
Each player holds a “setup package”, , which encapsulates
all information that was generated and sent to the player at the beginning
of the computation by the coordinator. This information includes the id of
this player, the total number of players, pregenerated polynomials, and encrypted AES keys for the pseudo-random functions as described in section
2.5.
Since several player threads may visit the same remote coordinator object at the same time, thread synchronization is needed at the coordinator.
For this synchronization to work properly, each joint basic protocol operation – that is, each synchronized handshake that the players do by calling
the remote coordinator object – is assigned a unique “operation id”. Id’s
field that is also held by each player.
for this is delivered by the 2
7
12
17
private
private
private
private
private
Hashtable s h a r e s = new Hashtable ( ) ;
SmcLibrary . P r i m i t i v e s . Coordinator . I 2 P l a y e r c o o r d i n a t o r ;
SetupPackage setupPack ;
FreeIdDispenser dispenser ;
O p e r a t i o n I d D i s p e n s er oid ;
public I F i e l d E l e m e n t P a r t i c i p a t e O p e n ( i n t i d )
{
I F i e l d E l e m e n t [ ] s = c o o r d i n a t o r . PerformOpen (
oid . Next ,
setupPack . P l a y e r I d ,
( IFieldElement ) shares [ id ] ) ;
I F i e l d E l e m e n t [ ] i d s = new I F i e l d E l e m e n t [ setupPackage . K ] ;
IFieldElement s e c r e t = this . InterpolateDynamic ( s ) ;
this . shares [ id ] = s e c r e t ;
return s e c r e t ;
}
The implementation was written in .NET 1.1 where generics were not yet
available. Hence, quite a lot of explicit casting of objects is needed. The
method is called at each player when they wish to jointly
execute the
protocol. The argument
is the id for the sharing that
they wish to open. First, each player contacts the coordinator remote object supplying the coordinator with an operation id, their respective player
ids, and their shares of the secret. This call is blocking and only returns
when all players have contacted the coordinator. The coordinator essentially simulates a broadcast: It collects the shares submitted by the players
into an
array which is then returned to all players.
Now, each player locally interpolates the secret by invoking the method
. It simply carries out the computations described in
126
The Code
Appendix B
section 2.3.1 for retrieving a secret from the individual shares 1 . Finally, the
resulting element is stored in the hashtable for further reference.
The next piece of code shows the corresponding functionality of the remote
coordinator object.
3
/ / for synchronization of the players
p r i v a t e o b j e c t plock = new o b j e c t ( ) ;
p r i v a t e long oid = 0 ;
/ / t o t a l number o f p l a y e r s and s h a r e t h r e s h o l d
private int n ;
private int threshold ;
8
13
/ / d e f i n e s how l o n g t i m e t o w a i t f o r p l a y e r s
p r i v a t e c o n s t i n t MaxWait = 1 0 0 0 0 ;
p r i v a t e c o n s t i n t Timeout = 2 0 0 0 ;
/ / ind ic ates i f protocol is aborted
p r i v a t e bool f a i l = f a l s e ;
/ / / c o u n t s ms s i n c e a r r i v a l o f f i r s t p l a y e r t h r e a d
p r i v a t e long t i c k ;
18
23
28
/ / / contains ids for the players that are s t i l l
/ / / active , i . e . that have not f a i l e d to respond to the p r o t o c o l
private IDictionary active ;
/ / shared s t a t e f o r t h e open p r o t o c o l
IFieldElement [ ] shares ;
i n t count = 0 ;
public I F i e l d E l e m e n t [ ] PerformOpen ( long oid , i n t pid , I F i e l d E l e m e n t pshare )
{
l o c k ( plock )
{
i f ( f a i l ) throw new A p p l i c a t i o n E x c e p t i o n ( " too many p l a y e r s missing " ) ;
i f ( ! a c t i v e . Contains ( pid ) )
throw new A p p l i c a t i o n E x c e p t i o n ( " p l a y e r excluded " ) ;
33
/ / b l o c k i f p r e v i o u s o p e r a t i o n hasn ’ t f i n i s h e d
while ( oid ! = t h i s . oid ) Monitor . Wait ( plock ) ;
38
/ / f i r s t player i n i t i a l i z e s
i f ( s h a r e s == n u l l )
{
s h a r e s = new I F i e l d E l e m e n t [ n ] ;
count = a c t i v e . Count ;
t h i s . t i c k = System . Environment . TickCount ;
}
43
s h a r e s [ pid − 1] = pshare ;
Monitor . P u l s e A l l ( plock ) ;
48
1 The
method is robust in the sense that if only part of the shares is returned by the
coordinator, interpolation still works as long as enough shares are received. However, this
is functionality due to the SCET project; we are not concerned with this in our thesis since
we assume honest players.
Prefix Addition 127
Section B.3
/ / k e e p w a i t i n g some ms a s l o n g a s n o t a l l p l a y e r t h r e a d s
/ / h a v e a r r i v e d h e r e ; i f w a i t e d enough t i m e s ,
/ / e x c l u d e m i s s i n g p l a y e r s and c o n t i n u e i f s t i l l enough
/ / players l e f t to i n t e r p o l a t e
while ( Missing ( s h a r e s ) )
{
i f ( System . Environment . TickCount − t h i s . t i c k > MaxWait )
{
/ / e x c l u d e p l a y e r s who h a v e n o t p u t s h a r e i n a r r a y
Exclude ( s h a r e s , r e f count ) ;
f a i l = a c t i v e . Count < n − t h r e s h o l d ;
i f ( f a i l ) throw
new A p p l i c a t i o n E x c e p t i o n ( " too many p l a y e r s missing " ) ;
}
Monitor . Wait ( plock , Timeout ) ;
}
IFieldElement [ ] res = shares ;
count −−;
53
58
63
68
/ / l a s t v i s i t o r e r a s e s a r r a y and
/ / allows threads to enter f o r next o p e r a t i o n
i f ( count ==0)
{
openshares = n u l l ;
t h i s . oid ++;
}
73
78
}
}
return res ;
Most of this code is concerned with thread synchronization and keeping
track of when the first player thread entered the remote object for execution
of the current
protocol. A player is excluded from the computation if
his threads does not arrive within a reasonable period of time and a dictionary of players that is still active, i.e. that have not been excluded yet, is
maintained. Apart from this, the coordinator basically collects shares (line
47) from the players. Each player thread returns in line 77 with the com plete set of shares. The private helper methods and have
been omitted as the jobs they carry out are quite straightforward.
B.3 Prefix Addition
The next example concerns the implementation of the prefix addition technique as explained in section 5.2.2 on page 50. This is intended to give
the reader an idea of how we have implemented protocols such as
,
, and
.
Since we need the prefix algorithm in more than one protocol, a generic
approach is adopted. That is, the implementation works with two inter faces and defining general associative
operands and operations. Special classes implementing these interfaces
128
The Code
Appendix B
have been created for each of the two situations where we need prefix com putation, that is, and for the binary ad
for the
dition in chapter 5 and , protocol in
section 7.3.3 on page 68.
The first piece of code shows these interfaces. The only entry to a
is a factory method that creates an operation object of the
same kind as the operand on which the method was called. The operation
has a method for initializing and for finalizing the operation. This method
takes as input a
. The is an abstraction that we have implemented in order to facilitate protocols involving many basic protocols
carried out in parallel, i.e. in one round. Essentially, this is done as follows.
Suppose we have four sharings of integers a 1 , a2 , b1 , b2 with ids
, respectively. To carry out the protocol, i.e. com-,
,
,
pute the products a1 b1 and a2 b2 in one round, the players create a ,
say, and calls
After this, and will hold ids for the two products a 1 b1 and a2 b2 , but
the hashtable containing shares will not have any entries for these ids. The
players must first call which encapsulates the parallel execution of the basic operations that have been added to the batch job. This
abstraction greatly simplifies the implementation of more complex protocols as e.g. the subprotocol for computing prefix sums.
1
public i n t e r f a c e I P r e f i x O p e r a n d
{
IPrefixOperation CreateOperation ( IPrefixOperand a , IPrefixOperand b ) ;
}
6
public i n t e r f a c e I P r e f i x O p e r a t i o n
{
void I n i t i a t e ( B a t c h J o b b j o b ) ;
IPrefixOperand F i n a l i z e ( ) ;
}
The following code sample shows the two concrete implementations of the
and used in the
protocol. The operand in
the “or”-case simply holds an id of a bit sharing. The object
in line 50-52 simply holds methods for execution of the basic protocols,
i.e.
,
, etc.
5
/ / / <summary>
/ / / R e p r e s e n t s a l o g i c a l OR o p e r a n d , \ i e a b i t .
/ / / </ summary>
public c l a s s OrOperand : I P r e f i x O p e r a n d
{
private int id ;
Section B.3
Prefix Addition 129
public i n t Id
{
get { return this . id ; }
}
10
public OrOperand ( i n t i d )
{
this . id = id ;
}
15
public I P r e f i x O p e r a t i o n C r e a t e O p e r a t i o n ( I P r e f i x O p e r a n d a , I P r e f i x O p e r a n d b )
{
r e t u r n new OrOperation ( a , b ) ;
}
20
}
25
30
/ / / <summary>
/ / / R e p r e s e n t s a l o g i c a l OR o p e r a t i o n , i . e . a o r b = a + b − ab
/ / / </ summary>
public c l a s s OrOperation : I P r e f i x O p e r a t i o n
{
p r i v a t e OrOperand d1 ;
p r i v a t e OrOperand d2 ;
p r i v a t e i n t ab ;
public OrOperation ( I P r e f i x O p e r a n d d1 , I P r e f i x O p e r a n d d2 )
{
t h i s . d1 = ( OrOperand ) d1 ;
t h i s . d2 = ( OrOperand ) d2 ;
}
35
40
public void I n i t i a t e ( B a t c h J o b b j o b )
{
t h i s . ab = b j o b . Mult ( d1 . Id , d2 . Id ) ;
}
45
50
55
}
public I P r e f i x O p e r a n d F i n a l i z e ( )
{
/ / c o m p u t e a + b − ab , w h i c h i s e q u i v a l e n t t o " o r "
i n t r e s = p r i m i t i v e s . Add( d1 . Id , d2 . Id ) ;
p r i m i t i v e s . P a r t i c i p a t e S u b t r a c t i o n ( r e s , t h i s . ab , r e s ) ;
p r i m i t i v e s . S h a r e s . Remove ( t h i s . ab ) ;
I P r e f i x O p e r a n d rop = new OrOperand ( r e s ) ;
r e t u r n rop ;
}
Since each -operation requires a multiplication and calculating the prefix
sum requires several multiplications, the job is parallelized by adding each
multiplication to a batchjob in line 43. In the method in lines 4654 the final computations in order to complete an -operation are carried
out. These do not need to be parallelized since only two additions and a
multiplication with a constant are required. These are all local operations,
cf. chapter 3. From this it should be easy to imagine how the more complex
diamond prefix operator of section 5.2.1 is implemented, though the dia-
130
The Code
Appendix B
mond operator involves more than one multiplication.
The next code sample shows the method for computing a list of prefix sums
and rounds off our brief code review. For further details we again refer the
reader the source code on the CD or the url given above. The method takes
as input a list of prefix operands and calls itself recursively according to the
pseudo-code listed on page 51.
5
10
15
20
25
30
35
40
/ / / <summary>
/ / / Calculates the p ref ix l i s t of a l i s t of
/ / / a s s o c i a t i v e operands using the p r e f i x algorithm .
/ / / </ summary>
public I P r e f i x O p e r a n d [ ] P r e f i x P a r a l l e l ( I P r e f i x O p e r a n d [ ] a )
{
i f ( a == n u l l ) r e t u r n n u l l ;
i f ( a . Length == 0 ) r e t u r n new I P r e f i x O p e r a n d [ 0 ] ;
i f ( a . Length == 1 ) r e t u r n a ;
i n t n = a . Length ;
/ / h a n d l e c a s e w h e r e n i s odd , i . e . n = 2 k + 1
IPrefixOperand t a i l = null ;
i f ( n%2==1)
{
/ / s p l i t operand array
t a i l = a [ a . Length − 1];
I P r e f i x O p e r a n d [ ] newa = new I P r e f i x O p e r a n d [ a . Length − 1];
f o r ( i n t i = 0 ; i <newa . Length ; i ++) newa [ i ] = a [ i ] ;
a = newa ;
n−−;
}
I P r e f i x O p e r a n d [ ] b = new I P r e f i x O p e r a n d [ n ] ;
b[0] = a [0];
I P r e f i x O p e r a n d [ ] c = new I P r e f i x O p e r a n d [ n / 2 ] ;
B a t c h J o b j o b = new B a t c h J o b ( p r i m i t i v e s ) ;
I P r e f i x O p e r a t i o n [ ] dop = new I P r e f i x O p e r a t i o n [ n / 2 ] ;
f o r ( i n t i = 1 ; i <=n / 2 ; i ++)
{
dop [ i − 1] = a [ 0 ] . C r e a t e O p e r a t i o n ( a [ 2 ∗ i − 2] , a [ 2 ∗ i − 1 ] ) ;
dop [ i − 1]. I n i t i a t e ( j o b ) ;
}
j o b . Execute ( ) ;
f o r ( i n t i = 1 ; i <=n / 2 ; i ++)
{
c [ i − 1] = dop [ i − 1]. F i n a l i z e ( ) ;
}
IPrefixOperand [ ] d = P r e f i x P a r a l l e l ( c ) ;
45
50
f o r ( i n t i = 1 ; i <=n / 2 ; i ++)
{
b [ 2 ∗ i − 1] = d [ i − 1];
}
dop = new I P r e f i x O p e r a t i o n [ n/2 − 1];
f o r ( i n t i = 2 ; i <=n / 2 ; i ++)
{
Prefix Addition 131
Section B.3
dop [ i − 2] = a [ 0 ] . C r e a t e O p e r a t i o n ( d [ i − 2] , a [ 2 ∗ i − 2 ] ) ;
dop [ i − 2]. I n i t i a t e ( j o b ) ;
}
j o b . Execute ( ) ;
f o r ( i n t i = 2 ; i <=n / 2 ; i ++)
{
b [ 2 ∗ i − 2] = dop [ i − 2]. F i n a l i z e ( ) ;
}
55
60
/ / i f o r i g i n a l l i s t had odd number o f e l e m e n t s , a p p e n d t h e l a s t
i f ( t a i l != null )
{
I P r e f i x O p e r a n d [ ] newb = new I P r e f i x O p e r a n d [ n + 1 ] ;
f o r ( i n t i = 0 ; i <b . Length ; i ++) newb [ i ] = b [ i ] ;
I P r e f i x O p e r a t i o n t a i l O p = a [ 0 ] . C r e a t e O p e r a t i o n ( b [ b . Length − 1] , t a i l ) ;
tailOp . I n i t i a t e ( job ) ;
j o b . Execute ( ) ;
newb [ newb . Length − 1] = t a i l O p . F i n a l i z e ( ) ;
b = newb ;
}
65
70
}
return b ;
If we adopt the notation from the PrefixSum algorithm in section on page
52, lines 30-40 take care of calculating the new list C of prefix operands.
Then the method calls itself recursively in line 42 and finally from line 44-59
the list B of prefix sums are computed. The special case where the number
of operands is odd is treated in lines 14-23 and lines 62-70.
Bibliography
[1] A LGESHEIMER , J., C AMENISCH , J., AND S HOUP, V. Efficient computation modulo a shared secret with application to the generation of
shared safe-prime products. In CRYPTO ’02: Proceedings of the 22nd
Annual International Cryptology Conference on Advances in Cryptology
(London, UK, 2002), Springer-Verlag, pp. 417–432.
[2] A LGESHEIMER , J. C. Distributed Computing on and with Secrets. PhD
thesis, Der Universität des Saarlandes, Schweiz, 2002, pp. 1-43 and
66-84.
[3] ATALLAH , M., B YKOVA , M., L I , J., F RIKKEN , K., AND T OPKARA ,
M. Private collaborative forecasting and benchmarking. In WPES ’04:
Proceedings of the 2004 ACM workshop on Privacy in the electronic society
(New York, NY, USA, 2004), ACM Press, pp. 103–114.
[4] B AR -I LAN , J., AND B EAVER , D. Non-cryptographic fault-tolerant
computing in constant number of rounds of interaction. In PODC ’89:
Proceedings of the eighth annual ACM Symposium on Principles of distributed computing (New York, NY, USA, 1989), ACM Press, pp. 201–209.
[5] B EAME , P. W., C OOK , S. A., AND H OOVER , H. J. Log depth circuits
for division and related problems. SIAM J. Comput. 15, 4 (1986), 994–
1003.
[6] B EN -O R , M., G OLDWASSER , S., AND W IGDERSON , A. Completeness
theorems for non-cryptographic fault-tolerant distributed computation. In STOC ’88: Proceedings of the twentieth annual ACM symposium on
Theory of computing (New York, NY, USA, 1988), ACM Press, pp. 1–10.
[7] B OGETOFT, P., D AMGÅRD , I., J AKOBSEN , T., N IELSEN , K., PAGTER ,
J., AND T OFT, T. A practical implementation of secure auctions based
on multiparty integer computation. FC ’06: Financial Cryptography
(2006).
[8] B ONEH , D., AND F RANKLIN , M. Efficient generation of shared rsa
keys. J. ACM 48, 4 (2001), 702–722.
134
Bibliography
[9] C ANETTI , R. Security and composition of multiparty cryptographic
protocols. Journal of Cryptology: the journal of the International Association for Cryptologic Research 13, 1 (2000), 143–202.
[10] C ANETTI , R. Universally composable security: A new paradigm for
cryptographic protocols. Cryptology ePrint Archive, Report 2000/067,
2000. .
[11] C HAUM , D., C RÉPEAU , C., AND D AMGÅRD , I. Multiparty unconditionally secure protocols. In STOC ’88: Proceedings of the twentieth
annual ACM symposium on Theory of computing (New York, NY, USA,
1988), ACM Press, pp. 11–19.
[12] C RAMER , R., AND D AMGÅRD , I. Zero-knowledge proofs for finite
field arithmetic; or: Can zero-knowledge be for free? In CRYPTO
’98: Proceedings of the 18th Annual International Cryptology Conference on
Advances in Cryptology (London, UK, 1998), Springer-Verlag, pp. 424–
441.
[13] C RAMER , R., D AMGÅRD , I., AND I SHAI , Y. Share conversion, pseudorandom secret-sharing and applications to secure computation. TCC
2005: LNCS 3378 (2005), 342–362.
[14] C RAMER , R., D AMGÅRD , I., AND N IELSEN , J. B. Multiparty computation from threshold homomorphic encryption. Report, Århus University (2000).
[15] D AMGÅRD , I. Commitment schemes and zero-knowledge protocols.
BRICS, University of Aarhus.
[16] D AMGÅRD , I., F ITZI , M., N IELSEN , J. B., AND T OFT, T. How to split a
shared number into bits in constant round and unconditionally secure.
Report, Aarhus University (2005).
[17] F RANKEL , Y., G EMMELL , P., M AC K ENZIE , P. D., AND Y UNG , M.
Optimal-resilience proactive public-key cryptosystems. In FOCS ’97:
Proceedings of the 38th Annual Symposium on Foundations of Computer
Science (FOCS ’97) (Washington, DC, USA, 1997), IEEE Computer Society, pp. 384–394.
[18] G ENNARO , R., R ABIN , M. O., AND R ABIN , T. Simplified vss and fasttrack multiparty computations with applications to threshold cryptography. In PODC ’98: Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing (New York, NY, USA, 1998),
ACM Press, pp. 101–111.
Bibliography
135
[19] G OLDREICH , O., M ICALI , S., AND W IGDERSON , A. How to play any
mental game. In STOC ’87: Proceedings of the nineteenth annual ACM
conference on Theory of computing (New York, NY, USA, 1987), ACM
Press, pp. 218–229.
[20] H EATH , M. T. Scientific Computing, An Introductory Survey. McGrawHill, 1997, pp. 217–224.
[21] H ELLEKALEK , P., AND W EGENKITTL , S. Empirical evidence concerning aes. ACM Trans. Model. Comput. Simul. 13, 4 (2003), 322–333.
[22] H ENNESSY, J. L., AND PATTERSON , D. A. Computer Architecture: A
Quantitative Approach, Second Edition. Morgan Kaufmann Publishers,
Inc., San Francisco, California, 1996, pp. A.2–A.3.
[23] H IRT, M., AND M AURER , U. Complete characterization of adversaries
tolerable in secure multi-party computation (extended abstract). In
PODC ’97: Proceedings of the sixteenth annual ACM symposium on Principles of distributed computing (New York, NY, USA, 1997), ACM Press,
pp. 25–34.
[24] I TO , M., S AITO , A., AND N ISHIZEKI , T. Secret sharing scheme realizing general access structure. In GLOBECOM ’87: Proceedings of IEEE
Global Telecommunication Conf. (1987), pp. 99–102.
[25] K NUTH , D. E. The Art of Computer Programming, Searching And Sorting.
Harcourt Brace College Publishers, 1995, pp. 409–417.
[26] K OZEN , D. C. The design and analysis of algorithms. Springer-Verlag
New York, Inc., New York, NY, USA, 1992, pp. 163-165.
[27] L ADNER , R. E., AND F ISCHER , M. J. Parallel prefix computation. J.
ACM 27, 4 (1980), 831–838.
[28] M C G EOCH , C. Analyzing algorithms by simulation: variance reduction techniques and simulation speedups. ACM Comput. Surv. 24, 2
(1992), 195–212.
[29] M ENEZES , A. J., VANSTONE , S. A., AND O ORSCHOT, P. C. V. Handbook of Applied Cryptography. CRC Press, Inc., Boca Raton, FL, USA,
1996 pp. 603–606 and 614-620.
[30] M ORET, B.
Towards a discipline of experimental algorithmics.
In Proc. 5th DIMACS Challenge (2000).
Available at
www.cs.unm.edu/∼moret/dimacs.ps.
[31] N IELSEN , J. B. Comparing some comparisons, a scet document. Report, Aarhus University (2005).
136
Bibliography
[32] O BERMAN , S. F., AND F LYNN , M. J. Division algorithms and implementations. IEEE Trans. Comput. 46, 8 (1997), 833–854.
[33] R ABIN , T. A simplified approach to threshold and proactive rsa. In
CRYPTO ’98: Proceedings of the 18th Annual International Cryptology
Conference on Advances in Cryptology (London, UK, 1998), SpringerVerlag, pp. 89–104.
[34] S HAMIR , A. How to share a secret. Commun. ACM 22, 11 (1979), 612–
613.
[35] S KYUM , S. Lecture notes in parallel algorithms, 2000. BRICS, University of Aarhus.
[36] T OFT, T. Secure integer computation with applications in economics.
Ph.D Progress Report, DAIMI, Aarhus University (2005).
[37] WALLACE , C. A suggestion for a fast multiplier. IEEE Transactions on
Electronic Computers 13 (1964), 14–17.
[38] WASER , S., AND F LYNN , M. J. Introduction to Arithmetic for Digital
Systems Designers. Harcourt Brace College Publishers, 1995, pp. 139–
142.
[39] YAO , A. Protocols for secure computations(extended abstract). In 23rd
Annual Symposium on Foundations of Computer Science (1982), pp. 160–
164.