This thesis presents a web-based system for secure business computation utilizing garbled circuits to facilitate privacy-preserving interactions between partners in a supply chain. It introduces a secure business computation language (SBCL) to express economic functions, such as the joint economic lot size, which can be computed without disclosing private data. The developed application leverages cryptographic protocols for secure multi-party computation, enabling efficient decision-making while maintaining data confidentiality.

1. University of Trieste
Italy
Master of Science in Computer Engineering
Master Thesis
Secure Business Computation
by using Garbled Circuits in a Web Environment
´
by ILIC Dejan
UNITS Supervisor SAP Supervisor
DR. BARTOLI Alberto ¨
M.Sc. SCHROPFER Axel
Piazzale Europa 1 Vincenz-Prießnitz-Straße 1
34127 Trieste, Italy 76131 Karlsruhe, Germany
March 5, 2010

2. Acknowledgments
It is an honor for me to give my biggest thank to my professor and supervisor Alberto
Bartoli. He has made available his support in a number of ways. His professional,
positive, informed and encouraging nature has been an inspiration throughout. From
the first day, at University of Trieste, to the very end of my studdings.
I am indebted to my many of my colleagues for supporting me at SAP Research
in Karslruhe. To all who helped and encouraged me during my time within their
department. Firstly, I am heartily thankful to my second supervisor Axel Schr¨pfer,
o
whose encouragement, supervision and support from the preliminary to the conclud-
ing level enabled me to hit even harder for my future career development. It is an
honor for me to acknowledge the project leader Florian Kerschbaum for his willing
support, advice and hard work in many aspects of the project. I am also grateful to
the many students who participated in the Secure SCM project, in particular Daniel
Funke, Vishaal Kumar and Piter Kohl. Their tolerance, team work, good humour
and insight added much to this work experience. Hopefully, all my colleagues felt
as rewarded as I did for their time and effort.
It is a pleasure to thank those who made this thesis possible. Firstly, I owe my
deepest gratitude to my parents and my brother who gave me the moral support
I’ve required from the very first day. I am particularly indebted to my girlfriend
and my friends, who has turned a blind eye to the dereliction of duty that occurred
over the past few years. Also, many thanks goes to my friends and colleagues at
the University of Trieste that were supporting and encouraging me to pursue this
degree.
Lastly, I offer my regards and blessings to all of those who supported me in any
respect during the studies.
Sincerely yours,
´
ILIC Dejan

3. Abstract
English. Collaboration among partners in a supply chain has been proven bene-
ficial. Thus, the full potential of a supply chain is not achievable by locally optimal
strategies, but rather requires cooperation of all participating parties. Yet part-
ners are reluctant to share private data in fear of exploitation by suppliers and
competitors. Secure Computation (SC) enables the effective decision making upon
comprehensive partners data, while assuring the secrecy of private data.
The SC is an interesting topic in modern cryptography. Rapid growth in process-
ing and communication speeds made a web based two-party SC realistic paradigm.
This thesis introduces a web based system for secure evaluation of economic func-
tion, named Secure Business Computation (SBC), in the manner suggested by Yao
in [29]. A function is described with high level Secure Business Computation Lan-
guage (SBCL), which will be used to generate a one-pass Binary Circuit Description
Language (BCDL) object. Indispensable libraries for cryptographic tools, like Obliv-
ious Transfer and Yao’s secure function evaluation protocol, were developed. These
libraries are used by a pair of Supplier/Buyer web based SBC applications. This
work is particularly focused on a Joint Economic Lot Size (JELS) function.
Italiano. La collaborazione tra i partner pu migliorare il funzionamento di una sup-
ply chain rispetto ad uno scenario in cui ogni componente della supply chain adotta
una strategia ottimale a livello locale. Realizzare questa collaborazione nella prat-
ica molto complicato in quanto i componenti sono riluttanti a condividere i propri
dati con altre organizzazioni, siano esse fornitori o potenziali concorrenti. La Secure
Computation (SC) uno strumento potente in questo contesto in quanto permette
di prendere decisioni su dati globali garantendo la segretezza dei dati stessi.
La velocit di calcolo e di comunicazione delle tecnologie moderne rende il paradigma
SC praticamente utilizzabile. La tesi descrive un sistema web basato sul paradigma
di SC per realizzare forme di Secure Business Computation in accordo al protocollo
proposto da Yao in [29]. La funzione da calcolare viene descritta con linguaggio ad
alto livello Secure Business Computation Language e da questa descrizione viene
poi derivato un oggetto Binary Circuit Description Language che realizza la fun-
zione per mezzo di un circuito combinatorio. Sono state sviluppate le librerie per i
componenti crittografiche essenziali, quali la componente di Oblivious Transfer e la
componente che realizza il protocollo di secure evaluation proposto da Yao. Queste
librerie sono utilizzate in una applicazione web per Supplier e Buyer in paradigma
SC. Il lavoro ` focalizzato in particolare sulla funzione Joint Economic Lot Size.
e

4. Contents
1 Introduction 3
2 State of the Art 5
3 Boolean Circuit Construction 8
3.1 Formula Tree Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 In-Memory Tree Structure . . . . . . . . . . . . . . . . . . . . 10
3.1.2 SBCL Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Arithmetic Operation Blocks . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Formula Tree To BCDL Compiler . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Boolean Circuit Description Language . . . . . . . . . . . . . 19
3.3.2 Formula Circuit Composition . . . . . . . . . . . . . . . . . . 21
3.3.3 Circuit Correctness . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Web Based Secure Business Computation 29
4.1 Browser To Browser Message Exchange . . . . . . . . . . . . . . . . 30
4.1.1 Exchange Session Manager . . . . . . . . . . . . . . . . . . . 32
4.1.2 Browser Message Box . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Cryptographic Library . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Secure Hash Algorithm SHA-1 . . . . . . . . . . . . . . . . . 41
4.2.2 Oblivious Transfer . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Garbled Circuits . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Web Yao Application Structure . . . . . . . . . . . . . . . . . . . . . 51
4.4 Graphic User Interface Design . . . . . . . . . . . . . . . . . . . . . . 56
5 Evaluation 58
5.1 Joint Economic Lot Size . . . . . . . . . . . . . . . . . . . . . . . . . 58
1

5. 5.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Conclusion and Future Work 68
A Cryptographically Secure Random Number 70
2

6. Chapter 1
Introduction
This thesis work is a part of the IT research at SAP AG Research CEC (Campus-
based Engineering Center) situated in Karlsruhe, Germany. The corresponding
project is focused on a Security&Trust1 research field, particularly onto improvement
of the Supply Chain Management (SCM) by using secure multi-party computation.
Thus, the project is denominated ”Secure SCM” project.
The key title parts are ”Secure Business Computation”, ”Garbled Circuits” and
”Web Environment”. The Secure Business Computation (SBC) was born by adapt-
ing Secure Function Evaluation (SFE) technique, while the evaluated function is a
simple economic (or business) function constructed from basic arithmetical opera-
tions. The technique described by Yao in [7], named Garbled Circuits, is used to
develop secure business computation paradigm. At the end, the entire system is
accommodated to run on internet, or in other words ”Web Environment”.
The successful work result is an internet based service that performs a secure
business computation between a supplier and a buyer, in a web browser. A specified
high level language has been developed dedicated to a custom business function
description named Secure Business Computation Language (SBCL). This language
then will be parsed to an in-memory formula object which will be compiled to a one-
pass boolean circuit described with Binary Circuit Description Language (BCDL).
The final result is a fully operational web based product which performs a secure
business computation behind a friendly Graphical User Interface (GUI). As such
this product is ready to be released to the market.
1
Security&Trust is a research program of SAP Research. This program approach emphasizes
on the users and their individual protection needs, including confidence in the system security and
awareness of its security status. Itrelates to security properties including authenticity, authorization,
integrity, confidentiality, privacy, anonymity, pseudonymity and non-repudiation.
3

7. Business data exchange between a business partners is always critical for each
partner, thus they keep their sensitive information private. But the partners would
like to achieve collaborative business improvements e.g. to identify a globally optimal
production plan (Funke [8]). A good example for this is an economic function named
Joint Lot Economic Size (JELS), used in the collaborative supply chain which has
to be computed by both partners. This function can be evaluated securely with
secure function evaluation technique. In this case, this function is described as an
encrypted (garbled) boolean circuit. Therefore, a SBC is a secure function evaluation
technique, but represented trough the garbled boolean circuit. With this method
each partner can compute an economic function output without revealing his input
to his partner. Final application is a secure computation service meant for business
partners that are willing to execute the computation in a web environment.
The entire work is divided in two parts. In the first part, a SBCL language
has been developed. Than a SBCL parser was developed to generate an in-memory
formula object. A developed compiler then compiles in-memory formula to a BCDL
object. The parser and compiler are written in Java programing language. The
second part is development of a web based (Yao protocol) SBC application between
two browsers. These browsers communicate over an artificial channel through a web
server message exchange subsystem developed with Java Servlet and deployed on the
Apache Tomcat server. The server application logic uses Java Server Pages (JSP),
the server-side Java technology. While the client application work flow is developed
with JavaScript scripting language, together with the Asynchronous JavaScript And
XML (AJAX) technology used for client/server communication. Even for the Yao
evaluation, the cryptographic libraries were developed in JavaScript. The AJAX
technology was also used to build a rich GUI for client application.
The State-of-the-Art chapter compares this thesis work with similar available
practical privacy-preserving web based information systems on market.
The chapter 3 describes how a secure business computation is composed (from
the four arithmetic blocks) using dedicated languages for its construction.
The chapter 4 explains how the application itself is constructed. It describes
how messages between two browsers are exchanged. Indispensable cryptographic
libraries for Yao and OT protocol evaluation will be explained.
The evaluation chapter describes the final web based application system. The
system runs a secure computation of the Joint Lot Economic Size function.
In the chapter 6 an overall research conclusion is described and desired future
work on a web based privacy-preserving secure business computation systems.
4

8. Chapter 2
State of the Art
In cryptography, secure multi-party computation (SMC) is a problem that was ini-
tially suggested by Andrew C. Yao in a 1982 paper [28]. In that publication, Yao
raised the issue of two millionaires, Alice and Bob, willing to find out who is richer
without revealing the precise amount of their wealth. A SMC solution has been
provided, satisfying Alice’s and Bob’s curiosity while respecting the constraints. By
looking at this example, there is no doubt that without a SMC those parties would
be forced to reveal amount of their wealth to a third (trusted) party.
This example show the type of the problems that generalized a multi-party com-
putation (as in [11]), or SMC protocols. In an SMC, there is a number N of partici-
pants p1 , p2 , . . . , pN , where each participant has a private data d1 , d2 , . . . , dN . These
participants want to compute the value of a public function with their private in-
puts, e.g. F (d1 , d2 , . . . , dN ). By definition, a SMC protocol computation is privacy
preserving, i.e. nothing else is revealed to the other players than what is inferable
by his private input and the outcome of the function. These functions should be se-
curely computed, or evaluated, and this process is called Secure Function Evaluation
(SFE).
In order to construct SFE there has been accepted Yao’s encrypted (garbled) bi-
nary circuit approach [29]. In this approach one of the participants, Bob, constructs
the garbled circuit by assigning two random (garbled) bit strings to all the wires
which are represented by 0 and 1 respectively and sends it to the other participant,
Alice. Before Alice can evaluate the circuit she needs to learn her corresponding
garbled input string. To do so, they use a cryptographic technique called 1-out-of-2
2
oblivious transfer (OT1 ) for Alice to receive her input in garbled form. With this
technique Alice reveals only one message mA , while two messages m0 and m1 were
offered by Bob, but still Bob cannot reveal value A and therefore he doesn’t know
5

9. which message Alice has choose. Alice then evaluates the garbled circuit and sends
Bobs output back. They both translate the garbled output strings for their output
wires into output bits, or computation result.
As has been shown in practice, various real-life problems would require SMC
solution. Such problems are distributed voting, private bidding and auctions, private
information retrieval, etc. But some problems can rely only on the sub-problem of
SMC. That’s because of its close relation to many cryptographic tasks is referred
to as secure two-party computation (2PC). As has been proven by Yao in [28], a
SFE can be achieved with help of the garbled circuits. Since now, the Yao’s garbled
circuit was implemented only as non web based solution. Therefore, the main goal of
the thesis is to contrive a web based two-party application which runs SFE with Yao
protocol. Till now this concept was mostly theoretical, but modern cryptography
coupled with rapid growth in processing and communication speeds made secure
two-party computation a realistic paradigm.
First system that runs Yao protocol is presented in a Fairplay project [7]. It
comprises two applications that are activated by the two players, who want to engage
in two-party SFE. This system presents the first evaluation of an overall SFE in real
settings. The two-party FairPlay system includes a high-level language SFDL for
specifying a distributed protocol, a compiler that compiles the high-level definition
into a low-level sequence of primitive operations (boolean circuit) named SHDL, and
cryptographic protocols for securely executing this sequence of operations.
An important notice is that the two-party FairPlay system is not a web based
solution. Nowadays an essential business request is to have a system capable to be
run in a web environment. Maybe FairPlay it can evaluate simple SFDL programs,
but business partners will require to be transparent and independent while they still
can evaluate simple custom economic functions.1 This was also mentioned in the
FairPlay project paper [7], a secure two-party computation system can be extended
in many ways. One important improvement was developing a new applications
driven by advances in the communication infrastructure (such as the ubiquity of the
Internet or the emergence of web services).
As has been described in chapter 1, this work shows a cutting edge web based
SFE application in a security information systems. The final system is able to
demonstrate the concept of SFE in a web environment, with protocol proposed by
Yao. This systam will protect partners and their confidentiality by contrive them
to learn the SFE result without revealing their secret inputs. It will be shown in
chapter 4, that this system provides a service to business partners for a custom
1
An simple economic function is expected that can be built with four basic arithmetical operators.
6

10. Figure 2.1: The final web SBC application look
economic function computation. The key task is to demonstrate evaluation of the
JELS function defined with BCDL object, that is generated with help of a high-level
language SBCL used to define an economic function. This example makes clear that
the final circuit can be an arbitrary economic function.
Therefore, the thesis research goes to cutting edge in the security research field
and delivers state of the are system. The resulting application provides an oppor-
tunity for future engineering of practical privacy-preserving web based information
systems. It pushes research in supply chain optimizations even further, making pos-
sible and secure computation for all participating parties. At the very beginning,
there has been mentioned that thesis result is a pair of internet applications ready
to be release to the market. Indeed, as has been shown, two browsers are capable
to evaluate a secure two-party computation over the internet. The figure 2.1 shows
entering web page for the final SBC application, and more pictures are shown in the
section 4.4.
7

11. Chapter 3
Boolean Circuit Construction
A boolean circuit is a mathematical model of computation used in studying compu-
tational complexity theory. This circuits are also the main object of study in circuit
complexity [27]. In this study, a boolean circuit with n input bits is a directed
acyclic graph in which every node (usually called gates in this context) is either an
input node of in-degree 0 labeled by one of the n input bits, an AND gate, an OR
or a NOT gate. One of these gates is designated as the output gate. Such a circuit
naturally computes a function of its n inputs. The size of a circuit is directly related
to the number of gates it contains.
Several important complexity measures can be defined on boolean circuits, in-
cluding circuit depth1 , circuit size, and number of alternations. In a circuit family
the size complexity is considered for this thesis work, e.g. of a family to be the
function of n that gives the size of the circuit that decides inputs of length n.
A boolean circuit is defined in terms of the gates it contain. As mentioned, a
basic circuit might contain binary AND and OR gates and unary NOT gates. This
basic circuits gates can be used to derive a binary gate eXclusive OR, or XOR. The
usage of the XOR gate can help to decrease circuit size, or total gate number. Each
gate corresponds to some Boolean function, meaning that it is some mathematical
function which takes k bits as input and which outputs a single bit.
One important feature of the one-pass(or combinatorial) boolean circuits is that
they are oblivious. They perform the same operation sequence independently of the
input (i.e. compute the values of the gates one after the other). A combinatorial
circuit is a circuit whose output is uniquely defined by its inputs. They do not
have memory, previous inputs do not affect their outputs. This structure differs to
a sequential circuit structure where the circuit gates can be reused, obviating the
1
Depth of a circuit, denotes the maximum distance from an input to an output.
8

12. circuit memoryless property. Therefore, the combinatorial circuit structure makes
this circuits oblivious as required by Yao in [29]. This obliviousness is the key reason
why one-pass boolean circuits were used as the computation model for the secure
function evaluation protocols (rather than, e.g. a Turing machine). The concept of
the obliviousness is important since the BCDL (from section 3.3.1) object will need
to respect this rule.
As said, this circuits are capable to compute also a general function where n
inputs are assigned to k players. In this scenario a boolean circuit contains n in-
puts dedicated to k = 2 players. Bob and Alice are players with their inputs a
and b respectively. Together they wish to compute some general function f (a, b)
using a properly constructed boolean circuit. This is a general problem of a secure
multi-party computation (SMC). In this work circuit evaluation is a protocol that
accomplishes three things:
1. Alice can enter her input a without Bob’s being able to learn it.
2. Bob can enter his input b without Alice’s being able to learn it.
3. Both Bob and Alice can agree on an arbitrary boolean circuit used to calculate
the output.
This way both parties are sure on the output correctness and that neither party
has tempered it. The theory regarding Yao protocol evaluation will be explained
detailed in section 4.2.3.
As Yao proposed in [29], the SMC circuit should differ from circuits constructed
out of the real hardware compilers. He specified that a boolean circuit should be a
purely combinatorial circuit, with no sequential logic. Compilers into real hardware
are mostly designed to use (and re-use) circuit components i.e. usage of registers.
For instance, look at a compound statement command like sum = sum + a[i], where
i = {1 . . . 32}. Real hardware compilers would produce a circuit with a single (sum)
register and a single addition circuit, where in each of the 32 clock cycles, one
value a[i] is added to the sum register. Fallowing Yao’s proposal, a compiler should
produce a circuit that has 32 copies of the addition circuit.
Looking at an arbitrary economic function it is obvious that a repetition of an
arithmetic operation will be common. But still, the circuit construction blocks,
described in section 3.2, can’t have any sequential logic and they can’t be reused.
From this it can be concluded that each arithmetic operation inside the formula will
require one arithmetic block.
In this work an economic formula is considered as a really simple mathematical
9

13. formula, that involves only the four basic arithmetic operations. Of course that
even an economic can include interest rates, percentage etc., but all these should be
then represented through the four arithmetic operations. This definition is valid for
entire document.
3.1 Formula Tree Object
An arbitrary economic formula will be represented as an in-memory object. Because
of the restriction on sequential logic, mentioned inside the introduction of chapter 3,
a chosen approach is to represent formula as a binary tree data structure. A binary
tree is a tree data structure in which each node has at most two children. With
this structure a parent has to be an arithmetic operation and the child would be an
operand. Also, it will be shown that formula described inside the binary tree also
satisfies Yao’s restriction on sequential logic.
A typical request in business would be a computation of a custom formula be-
tween n business partners. In other words, request is to construct the circuit out of
an economic formula defined by the business partners in a high-level programming
language. For that reason, as the part of this work, a high-level programming lan-
guage named Secure Business Computation Language (SBCL) has been developed.
This have leaded the work to development of a SBCL parser, which will parse the
SBCL description into an in-memory formula object.
3.1.1 In-Memory Tree Structure
Before describing a structure of the in-memory formula tree, there are some impor-
tant definitions for a rooted binary tree:
• A directed edge refers to the link from the parent to the child (the arrows in
the picture of the tree).
• The root node of a tree is the node with no parents. There is at most one root
node in a rooted tree.
• A binary tree is a tree data structure in which each node has at most two
children.
• A leaf node has no children.
• The depth of a node n is the length of the path from the root to the leaf. The
set of all nodes at a given depth is sometimes called a level of the tree. The
root node is at depth zero.
10

14. Figure 3.1: A formula tree example representing formula (3 ∗ d)/c − (a + b).
• Siblings are nodes that share the same parent node. In a rooted binary tree
each node have at most two siblings, left and right.
An in-memory tree object is an economic formula represented in data structure
of the rooted binary tree. To represent a formula inside this structure a root node
has to be an arithmetic operation. The children nodes are also arithmetic operation,
but a leaf can be either an input variable or a constant.
To understand this better, an arbitrary economic function can be seen in figure
3.1. In the figure an root node is shown that perform subtraction of the children
nodes. The left child is an node performing division of the children nodes, where
the left node is another arithmetic operation and the right one (leaf) is an input
variable, etc.
Thus, a node (or a child) can perform an arithmetic operation dedicated to
economic calculations such as addition, subtraction, multiplication and division.
Operation values can derive from another node as a result of arithmetic operation
result on lower binary tree levels. In this case first node is known as the root node and
the child nodes are called left and right. This is important because two of the four
basic arithmetic operations are operand position dependent. In the representation
of subtraction the minuend is the left child, while the subtrahend is the right one.
In the representation of division the dividend is the left child, while the divisor is
the right child.
Looking first at the structure of a binary tree starting from the root node there
has to be provided a recursive function. This function should run through the
11

15. Figure 3.2: A formula tree classes from tree.arithmetic package
entire tree, on all nodes and leafs. This shows necessity for an abstract class that
is supposed to be extended by arithmetic operation, input variable and constant.
As shown on figure 3.2 each tree node extends the abstract class Operand. Inside
the tree a leaf input variable and a constant is an instance of FormulaVariable or
FormulaConstant class, respectively.
For an arithmetic operation a class named Operation is meant to be extended
further to a four classes intended for four arithmetic operations. The Operation
class extends the Operand class with two attributes. This attributes are mentioned
even before as left child and right child, but in this case the term child is substituted
with the term operand.
Now, the recursion trough a rooted binary tree can be executed with a help of
predefined abstract functions inside the Operand class. There are two main func-
tions:
getValue(inputs) returns a formula’s calculated output value for the specific input
values. This function is called recursively for all operands from the tree root to
the leafs. For instance, if binary tree root computes a function f0 (a, b) = a + b,
then a and b will be returned values from the both Operand nodes. Therefore if
a is an another arithmetic operation where a ≡ f1 (c, d) = c − d than operand’s
function getValue(inputs) will take recursion to 1st level of binary tree etc.
getSize() returns a calculated bit output size from the tree. This function is also
called recursively for all operands from the tree root to the leafs. For example,
12

16. relating to previous example if binary tree root computes a function f0 (a, b) =
a + b, where a and b are node operands, than getSize() function will return
i+1 i≥j
g(i, j) =
j+1 otherwise.
where i and j are bit output size returned from the getSize() function invoked
on the a and the b operands respectively.
Of course, if function getValue(inputs) is called than a result will be com-
puted respect to the arithmetical operations of the nodes. Thus, if getSize() is
invoked, returned result depends also on operands and its characteristic to binary
representation. Therefore, if i and j are size of operands, then:
Addition will return bit size of max(i, j) + 1
Subtraction will return i size, or minuend bit size2
Multiplication will return i + j integer
Division will return dividend (i) bit size
Later in text it will be shown that an in-memory formula tree object is only a
transition object between SBCL and BCDL3 . That is important, because in the
final application design an business partner should just provide the formula, written
in SBCL, and BCDL object is generated out of it.
3.1.2 SBCL Parser
The secure function evaluation protocol requires that an evaluated function is given
as a Boolean circuit, preferably described in with BCDL. Business partners, however,
will desire a more convenient high-level form for a given economic function. In
the context of secure protocols, this is even more important than the strong usual
reasons for writing in high level programming languages. The starting point of
any attempt of security is a clear, formal, and easily understandable definition of
the requirements. Such clarity of definition is nearly impossible for humans, using
low-level formalisms such as Boolean circuits. The clear high-level domain specific
languages are required, such as SBCL.
To fulfill one of the users request there has been provided a high-level definition
language called Secure Business Computation Language (SBCL) used for a clear
2
Subtraction returns minuend’s bit size because of arithmetic block limits to only positive integer
numbers.
3
For a detailed description refer to the section 3.3.
13

17. computation overview. The SBCL is language-oriented and its tailored to describe
economic formulas. Expressions combine the standard notations as constants, vari-
ables, operators and optionally, parenthesis. The allowed operators include arith-
metic addition, subtraction, multiplication and division. It is also capable to handle
input data of a different input bit size. Once such a specification is given, a parser
generates an intermediate level specification of the computation in the form of an in-
memory formula tree object. The main reason to parse a SBCL object to in-memory
binary tree is for actual BCDL construction. The SBCL language serve only to ease
the development effort for the construction of a BCDL objects.
Let’s demonstrate an economic type of formula written in SBCL. This is a simple
two-player example with multiple variables and arithmetic operations:
default-bits:12
a:Alice
b:Bob
c:Bob
d:Alice
x:Alice,Bob
x = d/c - (a+b)
representing the variables input size, variable names and owners, together with a
function to compute. To explain the shown code, starting from top of the bottom,
a few important expressions have to be explained:
default-bits:12 is default input size only for all input variables. This is not true
for the output bit size, because is supposed to be calculated respect to the
given formula;
a:Alice is an input variable named a who’s owner is Alice. The other input variables
are a, b, c and d where Bob owns b and c , while Alice owns a and d;
x:Alice,Bob is an output variable. It can be seen that the variable is owned by
both players, Bob and Alice;
x = d/c - (a+b) is a custom formula suggested by business partners. Here can
be also seen that x is an output variable.
The input and output variables, together with the owners have to be defined for
every formula. If th+ e variables and the owners are not defined than the parser
14

18. can’t create an in-memory tree object meant to be compiled to BCDL. In order to
fulfill requests for future development, variable can have multiple owners. This rule
is valid for input and output variables.
Therefore, if a business partners provide all necessary data, the parser will thus
accept an economic function written in a high-level programming language and parse
it into a in-memory object that representing the same function. In our case the
compiler compiles an SBCL program into an rooted binary tree object.
It is also important to notice that the overall circuit size directly effect on eval-
uation performance. For example, due to their cost, multiplication and division
should be used with great caution. The multiplication would increase circuit size
really fast, therefore it is recommended to be used as least operation. The division
operator should be avoided if possible, or at least used with great restrictions. This
restrictions are just a hint to decrease circuit size, because final circuit have to be
purely combinatorial, in order to maintain obliviousness. For further details on the
arithmetic blocks characteristics refer to the table 3.1
Regarding to previously mentioned performance, the very first step in circuit
optimization is actually recomposition of the given economic formula. Making an
automatic optimizer for economic formula will make a life of the business partners
easier. This is one of the future development points. Another focus in future de-
velopment would be developing a SBCL-to-BCDL compiler. The a SBCL-to-BCDL
compiler is a novel endeavor in itself, because unlike common hardware compilers,
our compiler may use no registers, no loops, and moreover, may use every gate only
once. Still, the development of a direct SBCL-to-BCDL compiler, at this point of
time, is in a phase of development.
3.2 Arithmetic Operation Blocks
Now will be shown the construction of the arithmetic building blocks in the above
circuits given the one-pass constraint by Yaos protocol. Building blocks are com-
binations of previously mentioned logic gates. The necessary building blocks for
an economic function are addition, subtraction, multiplication and division. Note
that there exist circuits with better asymptotic complexity than circuits here pre-
sented, but many of them cannot be used, since they either do not adhere to the
one-pass constraint (Oberman and Flynn, 1997 [18]) or their complexity hides very
high constants in the ”big O” notation (e.g. Karatsuba and Ofman, 1962 [12]). The
goal is to optimize the number of gates for a realistic domain D, e.g. 32 bit. The
domain D needs to be chosen, such that it includes all possible inputs, outputs and
15

19. Figure 3.3: Half adder circuit diagram
intermediate values of j(XA , XB ) and therefore no over- or underflow occurs during
the computation. It is emphasized that the size of D is independent of any security
parameter chosen to protect the privacy of data sets. Thus circuits with the same
(or even lower) asymptotic complexity may noticeably differ in the absolute num-
ber of gates. The absolute number of gates is relevant because computation and
communication costs increase linearly with the number of gates.
Table 3.1 depicts for the three arithmetic building blocks a function on the num-
ber of gates required for inputs of length l bit, g(l), and the asymptotic complexity
of g(l).
3.2.1 Addition
The addition building block takes as input two positive numbers, a and b, both
having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number
o = a+b, having l +1 bits, o = ol . . . o0 . The circuit is composed from one half-adder
which is constructed from two gates and l − 1 full-adders which is constructed from
five gates each. A half adder is a logical circuit that performs an addition operation
on two one-bit binary numbers. The one half-adder takes as input bits a0 and b0
and has as output the sum bit o0 and carry bit c0 . A full adder is a logical circuit
that performs an addition operation on three one-bit binary numbers. For 0 < i ≤ l
a full-adder takes as inputs bits ai , bi and carry bit ci−1 and has as output sum bit
oi and carry bit ci . It can be combined with other full adders or work on its own.
The final bit ol is cl−1 . The total number of gates then is 2 + (l − 1) ∗ 5 = 5l − 3
which is proved to be the theoretical optimal lower bound for carrying out addition
of two l-bit numbers (Redkin, 1981 [22]).
3.2.2 Subtraction
The subtraction building block takes as input two numbers, a and b, both having l
bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number o = a+b,
having l bits, o = ol−1 . . . o0 . The circuit is composed from one complement or
16

20. Figure 3.4: Full adder circuit diagram
negation ¬x (NOT) circuit and two addition circuits already explained in subsection
3.2.1. The complement circuit takes as input bits bl−1 . . . b0 and the output c =
cl−1 . . . c0 will have same length of input size. Second part of the circuit takes as input
bits cl−1 . . . c0 as one of input variables of first addition circuit together with other
constant input variable equal to one, giving output d = dl . . . d0 . Third and the last
part, addition circuit from 3.2.1, takes a = al−1 . . . a0 and d = dl−1 . . . d0 , where dl is
discarded, and giving out the output o = ol . . . o0 , where, again the most significant
bit ol is discarded. The total number of gates then is l + 2 ∗ (2 + (l − 1) ∗ 5) = 11l − 6.
3.2.3 Multiplication
The multiplication building block described in (Wegener, 1996) takes as input two
positive numbers, a and b, both having l bits. We denote a = al−1 . . . a0 and
b = bl−1 . . . b0 . The output is a number o = a ∗ b, having 2l bits, o = o2l−1 . . . o0 .
First, l intermediate products si for 0 ≤ i < l will be computed, each having l
bits. Let sij denote bit j of intermediate product si , then si,j is computed from
aj ∧ bi for 0 ≤ i, j < l , i.e. requires l2 gates. We then calculate by employing
the addition building block l − 1 intermediate sums tk for 0 ≤ k ≤ l − 1 of two
l-bit strings having as output l + 1 bit. Let tk ,m denote bit m of intermediate sum
tk . tk is computed by adding the two l bit strings sk+1 and tk−1,l . . . tk−1,1 . t0 is
computed by adding the two l-bit strings s0,l−1 . . . s0,1 and s1 . The final output o
is then the concatenation of bits tl−2,l . . . tl−2,1 tk,0 s0,0 . The total number of gates is
l2 + (l − 1) ∗ (5l − 3) = 6l2 − 8l + 3.
3.2.4 Division
The division building block takes as input two positive numbers, a and b, both
having l bits. We denote a = al−1 . . . a0 and b = bl−1 . . . b0 . The output is a number
o = a/b, having l bits, o = ol−1 . . . o0 . In the phase of planning there were proposed
17

21. Addition Subtraction Multiplication
g(l) 5l − 3 11l − 6 6l2 − 8l + 3
O(g(l)) O(l) O(l) O(l2 )
g(32) 157 346 5891
Table 3.1: Gate number and asymptotic complexity, respect to the l input size, for
each arithmetic building block
Figure 3.5: Number of gates per building block, respect to input size
two solutions.
The first circuit performed as proposed by Oberman and Flynn (1997) in [18]
by first calculating the reciprocal of b, b−1 , with the iterative Newton-Raphson
approximation, and then performing a multiplication to obtain o = a ∗ b−1 . This
circuit had a total gate number equal to (log2 l − 1) ∗ (2(6l2 − 8l + 3) + 5l − 3) +
6l2 − 8l + 3 = log2 l(12l2 − 11l + 3) − 6l2 + 3l. For an l = 32 the circuit size is equal
to 53647 gates.
A second proposed building block for division by Kerschbaum and Schr¨pfer has
o
reduced the size of the first proposal, for a l = 32 input size, by factor three4 . At
the moment the circuit is still if phase of development, therefore a reader is referred
to the [19] for a detailed explanation.
4
Detailed explanation of the circuit will be published in WP2 deliverable for Secure SCM project.
18

22. 3.3 Formula Tree To BCDL Compiler
The in-memory object formula represents an arithmetic function chosen by busi-
ness partners. But still, before the evaluation this formula has to be represented
as a boolean circuit object. Therefore the language has been developed and used
for describing this boolean circuit. This language is denominated Boolean Circuit
Description Language (BCDL). It is expected that an in-memory formula can be
compiled into BCDL object. This step is required to provide a necessary input
object to the web-based application (described in chapter 4), i.e. a BCDL object.
3.3.1 Boolean Circuit Description Language
Required data for evaluation of a boolean circuit are the circuit gates, their truth
tables and circuit output wires. While this circuit data were enough for a mathe-
matical formula, there were required some additional informations for an economic
formula. To calculate an economic formula input and output variables have to be
owned by at least one of the business partners.
There had been decided a specific boolean circuit descriptive language develop-
ment, after the structural analysis of a boolean circuit. This language shall describe
a one-pass boolean circuit together with all necessary data required to represent an
economic function e.g an input owner. A BCDL object contains all necessary infor-
mations about a boolean circuit gates, truth tables, input/output wires and their
owners. As such a BCDL object can be divided into following descriptive parts:
Inputs. There are n inputs, e.g. for each function variable vl where l ∈ {1, . . . , n}.
As said before, each input (or variable) has its own size sl described with
SBCL. This input size sl is the size of an array representing an input vl , where
each element in the array is a circuit wire wu . Therefore, inputs in BCDL are
represented as a double array i.e. the inputs and their sizes.
Gates. The circuit connections are represented with gates gs where s ∈ {1, . . . , m},
and the circuit wires wu where u ∈ {1, . . . , k}. Then all gates are represented
as an array of length m and k is the total number of unique wires in the circuit.
g
Each element gs inside this array is a gate composed of multiple inputs wi s
g
and one output wos , where i = o and i, o ∈ u. The gate gs is represented as
an array of circuit wires wu , where first wires represents input wires (e.g. two
g g g
inputs w0s and w1s ) and the last wire (w2s ) is an output wire. In this thesis
work, each gate is a two input gate5 .
5
The security of the Yao protocol is still not prove for more than two inputs per gate.
19

23. Truth tables. Each gate inside the circuit has its own truth table tgs . This table
is represented as an array, where a gate gs is paired to a truth table tgs . The
output value tgs from a gate gs depends on the binary representation of the
h
input h of the fixed bit size r, where h ∈ {0 . . . 2r − 1}. I.e. if the input size is
r = 2 and the binary input is h = 1, then its binary representation would be
h = 012 . In this case, for an AND gate a result would be tgs = 0. Thus, there
01
is an obvious link between gate input size and truth table size, while output
values tgs have to be inserted respect to required gate.
h
Outputs. The outputs format of a BCDL object is exactly the same to its inputs
format. Each output (or result) has specific output size depends on the formula
described with SBCL. The only difference in respect to inputs is that the
g
output is an array of the output wires for specific gates wos .
Owners. A circuit described in a BCDL object also requires that all circuit vari-
ables(input and output) have their owners, as previously shown with an ex-
ample in section 3.1.2, where all the variables have their owners.
Looking at descriptive parts of the gates and the truth tables, there can be concluded
that a gate can be notated as Gs (gs , tgs ).
A compiler has been developed to generate the BCDL object from in-memory
formula. This BCDL object will contain all the mentioned information for the
circuit that computes an arbitrary business function from the formula tree object.
For example, the BCDL object exported in JSON6 format looks something like
following:
var circuit = {
"input":[[{"wires":[0,...,31],"name":"2*d*fa"}...
"tt":[[0,1,1,0],[0,0,0,1],[0,1,1,0],...
"output":[[{"wires":[24009,24010,24011,24012,24013,...
"gates":[[0,32,128],[0,32,129],[1,33,130],[130,129,131],...
}
Once the circuit is created it is required to check the circuit’s correctness. In this
case the correctness check supports only integer numbers, because operations are
limited to the unsigned integer numbers to maintain technical simplicity.
Thus, the in-memory formula tree to BCDL compiler includes many novel tricks
for reducing the number of resulting gates in the circuit.
6
JSON is a light weight markup language suitable for data representation in the JavaScript
scripting language.
20

24. Capability to compile a formula tree together with a constant values will affect
evaluation performance of the Yao protocol, especially in a web environment. That’s
because each additional operation will increase the final circuit size. There has been
decided to precalculate all public informations, e.g. sharing the same input value
from both sides, necessary for secure function evaluation. This precalculation is
done before the evaluation of a circuit, providing a minimized circuit as much as
possible ready to directly improve the protocol evaluation performance.
In this software version the ”formula-to-circuit-compiler” cannot export constant
value into the circuit. However compiling formula tree that contain constant values
will throw an exception informing user about unsupported functionality.
3.3.2 Formula Circuit Composition
To compose a binary circuit there has to be a logic behind when the circuit size start
to increase. A good solution to represent an economic formula trough a boolean
circuit is to provide basic arithmetical operations as prepared building blocks. Each
of these building blocks is stored inside a Java class with some internal logic for
a generic construction of the block, independent on the size of the inputs. The
preparation of this basic arithmetic blocks is done with help of a base Gate class
which is extended by each derived gate class inside the circuit.
There have been prepared a classes for a basic logical operation gates and a gates
that represents an artificial boolean value inside the circuit. Beside the basic logical
operations there is also a derived logical operation class. All this classes extend the
base Gate class whose illustrated attributes in figure 3.6 are the following:
win is an array of Wire instances wi where i ∈ {1 . . . n} and n is the size of input
bits for specific gate;
tt array is a truth table of Integer elements tg inside, where g ∈ {0, . . . , 2n − 1}.
Truth table output is represented with Integer and it is paired to a g input
where g is inserted as a binary value;
wout is a Wire element holding the information for gate’s output wire wo where
o = i. This makes it clear that each Gate element can have only one output
wire.
With the help of this three attributes the basic logic operations can be represented,
such as AND, OR and NOT. The same structure is appropriate to represent derived
logic operations, e.g. XOR operation. Said that, there can be even constructed more
complex gates of different input sizes, but with only one output.
21

25. Figure 3.6: A circuit basic gates classes from binary.circuit.gate package
For the basic and derived logic operations there have been provided classes illus-
trated on the right side of the 3.6 figure. The classes GateAnd, GateOr, GateNot and
GateXor extends base Gate class, and their constructors require the input size argu-
ment. A class constructor will generate automatically the truth table for a specific
binary operation gate.
The GateZero class is also extended from class Gate, but with some slight differ-
ence. Looking at the GateZero class on UML diagram in the figure 3.6 the difference
between this class and the other gate classes can be noticed. The static function
getZeroGate() returns the unique GateZero object for the overall circuit. That is
because the output of gate gz is always artificial zero, independently of the binary
input value. Later in text it is explained why this gate will be used multiple times
inside a BCDL object.
In this phase of development each circuit arithmetic building blocks, used to
compose a BCDL object, requires the equal operands size. This is a crossing point
in between the compilation of SBCL to the BCDL object. The SBCL offers con-
struction of an in-memory formula with a specific input size for each input variable.
Thus, if x and y are the size of the inputs, where x = y, then the GateZero output
wire have to be used for a |x − y| most significant bits on the min(x, y) input. The
result of the process is x, y = max(x, y) and all provided arithmetic building blocks
can be used for the construction of a BCDL object. An interesting optimization
point is focused to this problem.7
There has been also provided a GateOne class extended from Gate. After previous
7
Discussed as a future development in chapter 6.
22

26. Figure 3.7: A circuit’s InputVariable and OutputVariable classes from
binary.circuit.variable package extended from abstract class Variable
example, it is obvious that this gate will return artificial value tgo = 1 independently
h
on the binary input value h.
All wires in the circuit can be divided in two groups, the variable wires and
wires in the middle. The variable wires can be separated into input(in-degree 0) and
output variables. That’s why some wires have to be memorized inside the Variable
class. On the right side of the figure 3.7 the base Variable class is shown with the
name and the wires attribute. The attribute name is used only if the variable is of
importance for a final BCDL object, e.g. an information about the circuit output
variable used as an input variable to another circuit may have no importance. There
is also a method getSize() which returns the number of Wire elements inside the
wires array. As expected, a method as isNamed() ensuring the importance of the
variable for a final BCDL object, i.e. if a variable is named than it should be a part
of final BCDL object.
On the left side of the figure the classes are presented for the input and the
output variables nominated as InputVariable and OutputVariable respectively.
These classes extend Variable class and an abstract method addOwner(owner).
In the first version of the BCDL specifications these methods differ on the owners
number. At first version an InputVariable can have only one owner, while an
OutputVariable can have multiple owners.
While a name attribute is not obligate, the wires is an obligate attribute indepen-
dently on type of the variable i.e. input or output. It is obvious that a BCDL object
can be evaluated even without the owners, but in the secure two-party computation
protocol proposed by Yao [28] all the variables must have the owners.
As it has been shown, it is necessary to construct an economic formula circuit
out of the arithmetic building operation blocks. In the figure 3.8 all classes for
a four arithmetic blocks builders are shown. A base, or a parent, class per each
building block class is an instance of the Operator class. The Operator class is
23

27. an abstract class with a protected abstract function createCircuit(vina, vinb,
vout) extended to the all arithmetic blocks. Each arithmetic block will override
the abstract function of Operator class from a binary.arithmetic package. This
abstract method is
protected Circuit createCircuit(Variable vina, Variable vinb,
OutputVariable vout)
used to create a specific arithmetic circuit block, providing input parameters vina,
vinb, vout. All these parameters are arrays of wires for variable inputs (vina,
vinb) and array of wires intended to the output of the circuit (vout). Mentioned
function require two Variable arguments for left and right operands, and an out-
put OutputVariable argument. While this function is protected and dedicated for
internal circuit construction logic, there has been ensured an another function for
public calls. In figure 3.8 it is shown a public call function getCircuit in two forms.
Both functions require two Variable arguments for left and right operands, while
only one of them expect voutName argument used to nominate OutputVariable of
returned Circuit class. Here, the nomination of the output variable is important
only if this output is required in a final BCDL object.
Inside the class Circuit all the informations are stored to build a BCDL object.
In the Circuit class attributes are inputs, gates and outputs, stored as arrays of
Variable, Gate and OutputVariable elements, respectively. These attributes are
presented in the figure 3.8, together with their types. All these elements inside the
arrays are generated together with a Circuit class returned from getCircuit(vina,
vinb, vout) function.
It is obvious when looking at the figure 3.7 that an inputs attribute should be an
array of InputVariable elements. This fact shows that an input into the Circuit
instance can be also an output from another Circuit element. Thus, referring
again to the figure 3.8 and the Circuit class, a function prepareCircuit() shall
eliminate OutputVariable elements from whom are unnamed from outputs and all
from inputs. Afterward a BCDL object is prepared for future evaluation.
In a final BCDL object every wire wi has its unique identification number.
Uniqueness of each wire is required for correct evaluation of the circuit explained
later in text. Therefore, composition of overall circuit may require multiple arith-
metic blocks or, in other words, added circuits to the main circuit. While circuit
becomes more complex its getting more difficult to manage a uniqueness wire identi-
fication number. Although, keeping uniqueness is even harder if static BCDL objects
as GateZero can be reused for each building block of the final circuit.
24

28. Figure 3.8: Circuit arithmetic blocks classes from binary.arithmetic package
Figure 3.9: A WireManager class for managing of all the Wire objects in a circuit.
There has been developed WireManager class in order to facilitate manage-
ment for a wire identification uniqueness in a final BCDL object. Therefore, in
a WireManager class a function getWire() shall be called for every Wire instance.
As expected, unique WireManager instance stores every produced Wire instance
inside the wires attribute. Idea behind this is to use one static global wire identifi-
cation attribute gwid inside the Wire class. Once a final BCDL object is constructed
a function setWiresId() needs to be invoked from unique WireManager instance.
This function will invoke the function setWid() for all instances produced from
WireManager. Afterwards each Wire instance is identified in respect to the position
inside the wires array.
Looking at the figure 3.8, particularly on class Circuit, it is clear that a BCDL
object can be also generated from an in-memory formula tree. Composing the circuit
out of the in-memory formula object requires a compiler that will go through entire
rooted tree. Therefore an method inside the Operand class, from tree.arithmetic
package8 , named getSize() will help in BCDL object construction. From the fol-
lowing figure 3.10 can be understood how the circuit is constructed from the tree
8
Refer to figure 3.2 for detailed explanation of the tree.arithmetic package.
25

29. Figure 3.10: Flow diagram for generation of the BCDL from in-memory formula
rooted tree, starting from root Operation element.
root Operation.
The algorithm for circuit construction will start from binary tree root, which
is an Operation instance. Every Operation instance contains a left and a right
Operand instance, as shown in figure 3.2. As it has been shown on circuit generation
flow diagram a first checked Operand is a left one. If this instance is an oper-
ation (e.g. MulOperation) than the algorithm would invoke, for the second time,
generateCircuit(formula) for that particular Operation. Else, if the Operand is a
FormulaVariable then an InputVariable instance from the binary.circuit.variable
package. This function is recursively called trough entire tree until it reach a tree
leafs or FormulaVariable instance for both operands. A function returns a specific
operation building block which is added to the main circuit of the instance which
called the method. Afterward the algorithm goes for the right Operand instance and
repeat the same process. As a very final step the algorithm will process in a same
manner with building block of current instance. For the arithmetic block will use as
3.3.3 Circuit Correctness
As has been shown, four of the arithmetic building blocks have been provided for
circuit construction. Still in a future development of an arithmetic block there is
always a place open for an improvement. Therefore, a system to prove correctness
of the circuit had to be developed. Further in the text is shown an improvement of
the Division block and testing for the following circuit.
Some building blocks, particularly the Division block, have evolved in planning
26

30. and development process of a JELS circuit9 . I.e. in the development process of
this thesis work a two versions of the Division building blocks were proposed. The
division building block takes as input two positive numbers, a and b , both having
l bits. The output is a number o = a/b, having l bits.
A first circuit performed as proposed by Oberman and Flynn (1997) in [18]
by first calculating the reciprocal of b, b−1 , with the iterative Newton-Raphson
approximation, and then performing a multiplication to obtain o = a ∗ b−1 . This
circuit had a total gate number equal to (log2 l − 1) ∗ (2(6l2 − 8l + 3) + 5l − 3) +
6l2 − 8l + 3 = log2 l(12l2 − 11l + 3) − 6l2 + 3l. For an l = 32 the circuit size is equal
to 53647 gates.
A second proposed building block for division by Kerschbaum and Schr¨pfer has
o
reduced the size of the first proposal, for a l = 32 input size, by factor three. At the
moment the circuit is still if phase of development, therefore a reader is referred to
the [19] for a detailed explanation.
In this section the correctness is focused on an overall BCDL object and not just
for the specific block. Thus, if a requested is to test specific building block than an
input formula can be just a single arithmetic operator.
Formula tree object can be used to compute formula output over predefined
function, inside abstract Operand class
public abstract Integer getValue(HashMap<String, Integer> inputs);
where function call in classes Constant and Variable, that extends Operand class
will return number values, while Operation class call same function for left and right
Operand objects. In case of that one of operands is another Operation object, than
call becomes recursive trough entire tree. Custom input variable objects return their
values go over provided parameter HashMap<String, Integer> inputs containing
all possible values inside the tree. Parameter inputs contains String for key values
and Integer represents value used for this input variable.
In case of circuit correctness there been provided a fallowing static function inside
Evaluator class
public static int evaluate(Circuit c, HashMap<String, Integer>
inputs);
requiring Circuit object to evaluate and HashMap for input variables values.
9
Abbreviation of the JELS stands for Joint Economic Lot Size explained later in chapter 5.
27

31. At the end, its enough to create random Integer values of proper input size
for each input variable inside HashMap table and to provide this instance to the
previously mentioned functions, comparing returned result. This is good approach
because sometimes you can’t test all possible inputs because of overall circuit input
size.
28

32. Chapter 4
Web Based Secure Business
Computation
The secure business computation is a new concept in a business world, but still
there is a missing system to provide SFE for an economic function. In FairPlay
[7] project has been shown that a SFE can be done using a Yao protocol, but this
system isn’t suitable for an economic function. Beside that, the methods for doing
business evolved rapidly and these methods tend run business on internet, what
would require to make an web oriented SBC application. Developing a web based
application for the secure evaluation, in the manner suggested by Yao [28], is a real
challenge.
This chapter gives an introduction to libraries developed for web based secure
business computation application. Then follows a presentation of the subsystem
developed for browser to browser message exchange. It will explain the cryptographic
libraries for secure computation, which were required by the original solution of Yao
[28]. Once message exchange system and the libraries were described, an overall
description for web application (work flow) libraries and its structure are presented.
The figures give detailed formal descriptions of the libraries and protocols while the
text tries to explain their details supported by some examples. All the libraries and
message exchange subsystem were developed as a part of this work.
At the very end, the main target is to use this functionality on a real business
case. Therefore, the task was not only to create a system itself, but also an appli-
cation demo to be demonstrated in public. The final web application is presented
as a pair of client focused sub-applications which run in an internet browser. For
that reason, the SBC progress is displayed to the business partners in a user friendly
GUI. This application requires from business partners to insert their private inputs
29

33. and to run the evaluation, while at the end they should verify result, confidentiality1
and integrity2 provided by this system.
4.1 Browser To Browser Message Exchange
In everyday business each partner requires to be transparent and independent re-
spect to the other partners. To make them independent, an independent working
environment has to be developed for each partner. In todays business an inter-
net browser became an interesting basis for the business applications. An internet
browser can interpret, in this case, a JavaScript code required to run a business
application.
In order to evaluate a n-party protocol each party is obligate to exchange mes-
sages with other parties until the protocol is evaluated. Since this work focus on the
Yao’s protocol to evaluate the JELS economic function, where n = 2, requirement is
a secure two-party computation system. This specification gave an option to develop
a message exchange subsystem to support only n = 2 parties. It is expected that
a ”theoretical” system as this one has to be less complex and therefore a scenario
with n = 2 had been accepted to maintain the simplicity of developed code.
Following the analysis of a general service in a web environment, took this sub-
system to a multiple message exchange session provider. This subsystem will provide
a selection to the user between options to host or to join this subsystem. Hence,
another exchange session can be created on a same web server without any influence
to the other exchange sessions.
It is well known that an internet browser is designed to open a TCP/IP chan-
nel with a web server in order to exchange application data. This data exchange
allows a client/server application to run. But in order to run the SBC in a web
environment there have to be at least two clients processing the data among their
internet browsers. This is why there has to be developed a subsystem dedicated
to help in a message exchange between the browsers trough a web server. Usually,
among client and server data is exchanged with favor of HyperText Transfer Pro-
tocol (HTTP). The HTTP protocol will satisfy a subsystem requirements, plus it
will make profit out of an Asynchronous JavaScript And XML (AJAX) technology.
With the AJAX technology a GET/POST HTTP request/response is executed in an
application background, while user can have a complete control over the application.
The HTTP GET method is used to download data and to use basic functions for
1
Confidentiality ensure privacy, it prevents unauthorized represent of the secret data.
2
Integrity ensures correctness, the original data cannot be changed or substituted.
30

34. data manipulation on the web server. While the HTTP POST method its therefore
exclusively used to upload data onto the web server. This technology opens a door
to a completely new business logic on a web page and gives to a user more friendly
Graphical User Interface (GUI).
While almost every browser on the todays market provide an AJAX object in
its local library, a creation of an AJAX object is different in some browsers. This
differentiation comes because of the difference in browsers class name for the AJAX
object. Therefore, a JavaScript function has to be provided to discover the AJAX
class name inside the most popular web browsers. Afterward this JavaScript object
is going to be used for all HTTP requests.
Inside a specially developed library app/appAjaxReq.js there is a function called
getXMLHttpReq() which tests and returns a valid AJAX object for the specific
browser. For example, there is a conflict between IE7+, Firefox, Chrome, Opera,
Safari where object is called with XMLHttpRequest() function, and in IE5, IE6
there the object has to be called with a ActiveXObject("Microsoft.XMLHTTP")
command.
After the creation of a XML HTTP Request (XHR) instance, a HTTP request
can be made directly from JavaScript. A first step is to call open(type,url,async)
used to initialize the object. In this function a three arguments are requested:
Request Type: Request method type, only GET or POST
URL: Web server Unique Resource Location (URL) string
Async: Boolean value indicates which if a request should be dispatched in asyn-
chronous mode
The async argument is really important in this case. If the async value is true,
request will be executed in the asynchronous mode and rest of the JavaScript code
will continue to run. In this case, it is necessary to have an event manager to discover
the origin of the event. If the async value is false, the request will be executed in
the synchronous mode and the application will freeze until a web server responds.
In the final application version the synchronous method has been used, instead of
asynchronous, for every AJAX call. This has been done in order to skip necessity to
have an event manager to discover the origin of the event used to prevent confound
of the web server responses.
Knowing that an AJAX object can execute only the GET and the POST request
definitely helped to maintaining the simplicity. For each HTTP parameter used in a
client exchange session a dedicated AJAX library will contain a function dedicated to
31

35. one of two possible requests. Following JavaScript functions, in app/appAjaxReq.js
library, ware provided for these operations
• ajaxDoGet(url, param, destObject) request with the HTTP GET method
• ajaxDoPost(url, data, destObject) request with the HTTP POST method
used to simplify GET or POST method call of an open(type,url,async) function
predefined inside the browser’s AJAX library. The arguments url and destObject
stays for URL of a web server that provides some service and an object where
function stores a return value, respectively. In case of GET request, there is a param
argument where all required parameters of a HTTP GET request should be placed.
While POST request has data argument that is an instance of a byte array to upload
on a web server.
In an ideal application case the AJAX technology combined with a Comet tech-
nology. The Comet technology offers a server push3 methodology, instead of a pull4
methodology used in this work. In scenario with the Comet technology an overall
result of TCP/IP packages efficiency will increase in a SBC application.
As it has been said two browsers can exchange data only if there is a web server
in between. There has developed a exchange session manager class ManagerME in-
tend for management of a multiple parallel exchange sessions. Below this exchange
mechanism is one browser’s (or client’s) instance of a dedicated message box class
Browser.MessageBox. A client has to administer his message box in order to keep
it up to date. These concepts are described in details in the following chapters.
4.1.1 Exchange Session Manager
A browser exchange sessions manager on a web server shall provide a robust ex-
change service, to keep securely stored data directed to a client. It has to support
multiple independent exchange sessions, together with user dedicated functions to
host a session and to join an existent session. While secure storage is an important
issue there is also a feature of a great importance, the latency. All this issues are
”unimportant” in a test environment (as in this work), but in a real web server there
are hundreds or thousands of the exchange sessions this can become an enormous
concern.
3
Push technology, or server push, describes a style of Internet-based communication where the
request for a given transaction is initiated by the publisher or central server.
4
Pull technology or client pull is a style of network communication where the initial request for
data originates from the client, and then is responded to by the server.
32

36. Figure 4.1: Ideal session activation flow in two-party message exchange system
The message exchange system has to be deployed on a web server approachable
to all SBC players. This system has help running a multiple parallel and independent
SBC sessions. Running in parallel would mean that a multiple n-party SBC can be
evaluated at the same time. This independence give guaranties that each client has
one and only one exchange session on a web server, refereed to his current exchange
session ID information stored in browser. If client wants to host/join another session
the old exchange session ID will be overwritten.
Any client can host/join a message exchange session in any point of time, even
in the middle of a SBC evaluation. Once client host/join a new session, his internet
browser stores an information regarding a currently hosted/joined exchange session.
This information will be stored until client chose to host/join an another session or
to delete the information. The reader is referred to the figure 4.1 for the host/join
exchange session step.
If an exchange session is created (hosted), the host client becomes automatically
a part of this session. His internet browser should store his current exchange session
ID as a browser cookie. The created exchange session shall stay an inactive session
until all the players join. That’s why the host must invite (e.g. email, SMS, letter
etc.) a guest to join the exchange session, as represented with gray arrow in figure
4.1. Afterward, once all the required clients join the session it becomes an active
session (figure 4.1). Once session is active no additional players can join the session.
If some other player tries to join the session an exception will be thrown to inform
the player about the exchange session status.
33

37. There is also an advantage if subsystem is designed to provide only n = 2 ex-
change sessions. In this case, a web server can automatically recognize designation
player in an exchange session ID where player is trying to send a message. Otherwise
it would require additional message destination parameters in a HTTP request. In
n > 2 case the system requires further development. This system should contain
an information about the destination inside a HTTP request, while n = 2 parties
system transmits messages directly to the opposite party.
Dynamic server responses were inevitable, since all message exchange requests
goes over HTTP request methods (GET, POST). Therefore, Java Servlet technology
with its HTTPServletRequest and HTTPServletResponse classes entirely fulfilled
elaboration requirements. An extended Servlet class ServletME runs on a web
server and listens for incoming
• doGet(HttpServletRequest request, HttpServletResponse response)
• doPost(HttpServletRequest request, HttpServletResponse response)
requests. A doGet function call responds on HTTP GET method requests, while
doPost responds on POST method requests. A personal message exchange ser-
vice(read, delete,...) for clients is administered trough GET method, while all the
POST method are exclusively for message sending, uploading data to a message
box.
The decision on which method to use is what purpose is directly related to
HTTP protocol specification. E.g. Microsoft Internet Explorer has a maximum
uniform resource location (URL) length of 2,083 characters. It also has a maximum
path length of 2,048 characters. This limit applies to both POST request and GET
request URLs5 . I.e. if GET method is used there is a limit to a maximum of 2,048
characters, minus the number of characters in the actual path. This is more than
enough to control a web server via parameters. However, the POST method is not
limited by the size of the URL for submitting name/value pairs. These pairs are
transferred in the header and not in the URL. The ”unlimited” parameters in header
of the POST method were not enough to transfer entire circuit, since the application
expects only one (huge) BCDL object. Instead it is decided to transfer BCDL object
in a data section of the HTTP POST method.
All HTTP GET request should contain one and only one parameter, because
only first parameter is going be processed by ServletME and all the others will
5
RFC 2616, ”Hypertext Transfer Protocol – HTTP/1.1,” does not specify any requirement for
URL length.
34

38. be discarded6 . Single parameter rule is not valid only with one specific applica-
tion request, this request is the host/join HTTP GET request which requires two
parameters.
This specific GET request will contain message exchange session ID string which
will be used to host/join message exchange session. The difference is introduced
because need for some additional information e.g. the file contains the BCDL object,
which will be evaluated in the final web application.
Once client hosts an exchange session on ServletME, his browser receives an
unique JSESSION cookie from a HTTPSession class. The browser will use this cookie
for identification purpose in future requests. Actually, Servlet uses HTTPSession in-
stance to store some additional parameters for specific client. Similar to the Servlet’s
browser recognition, a message exchange system is going to use JSESSION value to
discover his message exchange session. The JSESSION value is stored in bwId vari-
able in a BrowserME class. Since every client has to provide an unique exchange
session ID parameter to host/join the session, the Servlet will store this parameter
as esId attribute in the browser’s HTTPSession instance. After this step, the esId
value is linked to JSESSION (which is equal to bwId) value. The bwId value will be
used to restore the message exchange session instance through the esId value.
Working environment is managed though ManagerME class. This class is de-
signed to simplify creation of an exchange session. This is made with help of
a MessageExchange class where esId and bwId values are stored, in SessionME
and BrowserME instances respectively. Basically, the ManagerME keeps multiple
MessageExchange instances stored in an array. Manager has openSession(esId,
bwId) function dedicated to creation of a MessageExchange instance. This func-
tion is used to host/join an exchange session with provided parameters. Obvi-
ously, a player invokes this function to register his bwId for specific esId inside the
ManagerME.
Once player tries to host/join a session the manager will check if there is already
an existent exchange session with equivalent the esId value. If there is no equivalent
esId, the player will be considered as a host and a function hostSession(esId,
bwId) will be invoked. If equivalent esId already exists, the player will be considered
as a guest and a hfunction joinSession(esId, bwId) will be invoked.
Usage of the ManagerME makes everything automatized, in fact an user should
use available management requests designed as the HTTP request parameters. Most
of these HTTP management commands should be used without a parameter value.
6
One parameter rule is present for subproject simplicity.
35

39. For an example, the fallowing HTTP request sends a valueless getMsg parameter as
http://10.55.145.XXX:8080/WebYao/ServletME?getMsg
This command will call deployed ServletME Servlet in order to read a message
from the browser’s message box. On HTTP request reception, a Servlet restores
the exchange session (esId) attribute stored in HTTPSession trough bwId. As said,
with assistance of JSESSION cookie the attribute values can be restored from Servlet.
This means that client will have to provide esId value only once, when he host/join
the session.
Following HTTP parameters are dedicated to management of an exchange session
on a web server:
• GET: esId - host or join to the specified exchange session
• GET: esActive - valueless parameter used to check if exchange session is
active
The parameters are transfered trough HTTP GET method where only esId param-
eter is expected to have a value of his exchange session. Both responses is going
to have string value ”true” or ”false”. The esId request returns true if player has
successfully hosted/joined the session and esActive returns true if all players joined
the session. A false value can sometimes be expressed trough exception message e.g.
if player tries to join multiple times an exchange session or if player tries to join
an active session. However, only a response with data content ”true” is a success-
ful/positive operation.
Previously mentioned parameters are meant to invoke the following functions,
with ”es” prefix, from app/appAjaxReq.js library :
• esOpen(url, esId, destObject) host/join exchange session
• esActive(url, destObject) check if exchange session is active
where url is the URL of the ServletME instance and detsObject is an object used
to store a response value. The esOpen function requires an exchange session esId
argument, client is willing to host/join.
All the other commands are related to message box operations and those will be
explained in details in the following section 4.1.2.
36

40. 4.1.2 Browser Message Box
Starting at ManagerME class that contains a vector of a MessageExchange classes
where you can find a SessionME and array of BrowserME classes particularly linked
to an exchange session, all the way to MessageBox class. As has been said, every
browser has its own message box on a web server. This box is represented as a
Browser.MessageBox class. An owner of this message box will have benefit to
receive messages and to manage it through the HTTP requests.
Since each client’s browser instance can be involved in only one message exchange
session, it indicates that a browser instance can have only one active message box. In
fact, any client can open multiple sessions and therefore multiple message boxes, but
only if the browsers don’t share memory space. If client tries to host/join multiple
exchange sessions with the same browser a JSESSION value remain the same and it
will refer only to the last hosted/joined session. Important notice is that client can’t
go backward and reuse an existing message box if he has hosted/joined a different
session.
The message box class has to be simple as possible, therefore it can receive
one and only one message. This message cannot be overwritten if there is another
incoming message, instead the mail box owner have to read the message first and
than to execute command that will delete the message.
The message box has to be managed and messages should be sent by client, hence
there has been provided a few management commands. The managing commands
are following:
• Received message
1. READ: Read a message from the box. If there is no message in the box
return ”false” value.
2. DELETE: Delete a message from the box. If there had been a message
in the box return ”true” value, otherwise return ”false”.
• Intended message
1. REQUEST TO SEND: Ask is a receiving box capable to receive a
message. Response is the boolean ”true” or ”false” value
2. SEND: Send a message. A response is ”true” value if the message is sent
successfully , or ”false” otherwise.
where all the commands are obvious except the ”request to send” command. If client
pi wants to send a message to pj , where i = j, firstly he should send a ”request to
37

41. send” to a web server. The pi can check if there is already a message in pj message
box. If there is the message, pi can move on with sending a ”small” size packets to
a web server, until pj is available to receive the message. Without this command a
pi would be forced to send ”large” packets, and this can be highly inefficient if the
pj message box is unable to receive those packets.
There has been predefined a limit l of messages inside the message box. The limit
has to be enough to exchange all the necessary data between two browsers, while
subsystem complexity is reduced to minimum. This limit is set to limx→∞ l = 1
where x is the number of messages on wire directed to one of the message boxes.
Of course, each client is responsible to maintain his message box in order to allow
new messages to be received. Therefore, each client has to know the subsystem’s
predefined maintenance commands used for read, delete, send etc.
Some protocols can require more than one message to be sent (or to be received)
at the same time, which would make this exchange aspect ineffective. The mentioned
inefficiency can be noticed e.g. in an OT protocol part inside the Yao’s protocol when
a multiple binary inputs has to be exchanged in order to evaluate the circuit. Since
this system relies on Yao’s protocol, exchanged messages can be adopted to perform
this subsystem with maximum efficiency, e.g. parallelization of OT7 step.
An advantage in the accepted n = 2 exchange scenario is that each client pi
can send a message to the opposite party pj without any informations on message
destination. This feature is allowed by background logic of the subsystem where
i, j ∈ {0, 1} and i = j are used to discover who is a pj party. Therefore, pi will
send a message to the ServletME and the message will be stored directly in a pj ’s
message box.
All HTTP requests from clients will be sent with help of the AJAX technology.
These requests are predefined on a ServletME used for message box management
over few basic predefined functions to read, send, delete message. Requests to the
web server, followed by responses to the browser, should contain following HTTP
parameters:
• GET, getMsg - get message from personal message box
• GET, delMsg - delete message from personal message box
• GET, reqSend - request to send message to other client
• POST, without a parameter - send message to other client
7
Oblivious Transfer(OT) is a cryptography technique described later in chapter 4.2.2
38

42. Figure 4.2: Ideal message exchange flow in an active session of two-party message
exchange system
In order to exchange messages the clients will have to send one of these HTTP
requests to a web server over a previously opened exchange session (figure 4.2).
This session with another browser has to be also active before sending a message.
As it has been shown, the clients also need to have some additional parameters
(commands) used to execute a few basic controls over their mail boxes, e.g. delete
a message before receiving another one.
There are two possible responses for each HTTP upload (POST) request method
to a server, ”true” or ”false”. If there is no message inside the box, the message
will be stored and server will return value ”true” as in figure 4.2. Response will
be ”false” if there is an undeleted message in the box, thus sent message will be
discarded. For that reason, one of the GET parameter requests reqSend is intended
to spare unnecessary network traffic i.e. sending a messages that cannot be stored.
All these methods have been designed to provide message exchange in between
players browser for the SBC with help of following cryptographic libraries.
4.2 Cryptographic Library
A generic type of secure computation (SC) was suggested by Yao [28] in his seminal
work where he introduced the notion of a secure function evaluation (SFE). In that
work Yao raised the issue of two millionaires Alice and Bob, eager to determine
whom of them is richer, but reluctant to reveal their actual wealth. Assuming Bob’s
and Alice‘s amount of a wealth is i and j respectively, where i, j ∈ [0, N ] and N ∈ N.
39

43. In order to determine who is richer they should evaluate a following protocol
1 i≥j
f (i, j) =
0 otherwise.
where f = 1 claims that Bob is richer.
In secure multi-party computation (SMC) the millionaires problem represents
only a special case of a broad issue. In SMC [11], set of n players Pi , where i ∈
{1, . . . , n} wish to jointly compute an arbitrary function of their private inputs
y1 , . . . , yn = f (x1 , . . . , xn ) with each party Pi private input xi . There is no Pi that
is willing to reveal his private input xi to Pj , where i = j. This rule is also valid for
the outputs where each party Pi receives only their output yi without learning or
inferring anything else, except what can be inferred from input xi and yi [10].8
In general definition the SMC allows to the players P1 , . . . , Pn computation of a
public function f (x1 , . . . , xn ) = (y1 , . . . , yn ). The computation is privacy preserving,
i.e. nothing else is revealed to a player than what is inferable by his private input
and the outcome of the function.
This work, more generally, focuses on the following two-party SFE problem.
Alice has an input x = x1 , . . . , xs and Bob has an input y = y1 , . . . , yr where s and r
are their input size respectively. They both are willing to learn f (x, y) for an agreed
public function f , but without revealing any information on their inputs.
In order to evaluate the SFE with help of a Yao protocol, there have been
developed indispensables JavaScript libraries for the final web application. As a
part of this work, the following libraries were developed:
• crypto/digest/sha1.js Secure Hash Algorithm SHA-1 JavaScript library
• crypto/ot Oblivious Transfer JavaScript package
• crypto/yao Yao’s garbled circuits JavaScript package
where crypto/ot and crypto/yao are composed out of multiple objects. All these
libraries are sorted by dependence, but each library is going to be explained in details
in following sections.
8
In a two party setting the function y = f (x1 , x2 ) = x1 + x2 , where y is output for each Pi . The
party Pi cannot compute function y without learning the party’s Pj input xj . But it is obvious the
each player can reveal the other players input if commits a simple subtraction. In order to keep
both inputs private an introduced secret sharing scheme by Shamir[25] and Blakley[2] needs to be
applied.
40

44. bit size
Output Internal state Block Max message Word Rounds
160 160 512 264 − 1 32 80
Table 4.1: Characteristics of Secure Hash Algorithm SHA-1
4.2.1 Secure Hash Algorithm SHA-1
Theory. A hash function is a deterministic procedure that takes an arbitrary block
of data and returns a fixed-size bit string, the hash value, such that change to the
data will ideally change the hash value. A message digest is a secure one-way hash
function that take arbitrary-size data and outputs a fixed-length hash value. The
SHA is called secure because it is designed to be computationally infeasible to recover
a message which produce the same message digest.
In this work a library has been developed that produces a 160 bits long message
digest. This is the Secure Hash Algorithm SHA-1, derived from his predecessor SHA-
0. SHA-1 is a symmetric cryptographic function that is actually used in the Yao
protocol for actual circuit garbling described in section 4.2.3. It has been chosen
because for convenience of a block cipher usage9 , therefore it supports a variable
input length. Some of its main characteristics are presented in table 4.110 .
Practice. This function is the most frequently used function in the entire appli-
cation i.e. this function will be called multiple times for every wire in the circuit.
Because of that, the key objective to achieve is to obtain a hash function which
performs as fast as possible, but written as a JavaScript library.
Consequently, exclusively for this application, a JavaScript library sha1.js in
crypto/digest package has been developed. Whole (mostly binary) background
processing is hidden behind a dedicated function which requires a message as an
argument. This function is defined as
function sha1(message)
and returns the message hash value in a BigInteger11 object. This is a key function
of the library, while all the other functions are used as a behind logic used by the key
9
In cryptography, a block cipher is a symmetric key cipher operating on fixed-length groups of
bits, called blocks.
10
Internal state means the internal hash sum after each compression of a data block.
11
The jsbn is a pure JavaScript implementation of arbitrary-precision integer arithmetic. Basic
library (jsbn.js) contains BigInteger implementation which is just enough for RSA encryption
and not much more. The rest of the library (jsbn2.js) include most public BigInteger methods.
41

45. function. It is important to notice that the message argument is also a BigInteger
object. This was useful since all the random values used in circuit were already
represented as a BigInteger object.
Its performance was the most important point since overall time increases linearly
with time necessary to compute hash function. This time cannot be neglected when
a circuit size increase to, and exceed, 60 000 gates. In performance comparison
with the other, well known, open source SHA-1 libraries (available on Internet) this
library had the best performance.
4.2.2 Oblivious Transfer
Theory. An important primitive in SMC is Oblivious Transfer (OT) introduced
by Michael O. Rabin in 1981.12 The OT is a widely used primitive in many secure
computation protocols. For example, in Yao’s garbled circuits (section 4.2.3), in
the Fairplay system by Malkhi [7] as well as in the multi-party version of Fairplay,
FairplayMP [1]. Both Fairplay systems enhance the Yao‘s original construction.13
In this case the most basic set-up is used. In general description, Bob has two
bits(messages) m0 and m1 , while Alice has a bit of choice b. Evaluating the protocol
will reveal mb to Alice, but nothing is learned about m¬b and Bob didn’t learn
the Alice’s secret input b. Used oblivious transfer scheme is based on the RSA
cryptosystem, as can be concluded from the following paragraph.
Consider a party P1 eager to send k of its n inputs to party P2 while resting
assured that P2 cannot learn anything about the other n − k values. Furthermore,
P2 is unwilling to reveal to P1 which k of the n inputs has been choose to receive.
Even at [23] is presented the first 1 − 2 oblivious transfer scheme14 , which can be
generalized to 1 − n and k − n OT schemes, [16] and [9] respectively. Plenty of
research has been conducted on efficient and secure OT protocols. Naor and Pinkas
[17] significantly improve their earlier 1 − n approach, but they were surpassed by
the OT scheme of Tzeng [26], who also devises enhanced k − n OTs [5].
The Chu and Tzeng [5] OTn protocol of will be presented. Required protocol’s
k
system parameters (g, h, Gq) where g and h are generators of the Gq group of prime
order q, subgroup of Z∗ .
q
1. P2 choose k inputs he want to retrieve, denoted σ1 . . . σk , and constructs a
12
Rabin’s form was improved later by Shimon Even, Oded Goldreich and Abraham Lempel[3], in
order to build protocols for secure multiparty computation. It is generalized to 1-out-of-n OT
13
Yao original construction is described in [29].
14
One out of two oblivious transfer scheme, also denoted OT21
42

46. polynomial f (x) = b0 + b1 x + . . . + bk−1 xk−1 + xk , such that f (x) = 0 if
x ∈ σ1 . . . σk . Additionally, they choose a polynomial f (x) = a0 + a1 x + . . . +
ak−1 xk−1 + xk , where ai being uniformly random in Zq , to mask f (x) by
Ai = g ai hbi .
2. P1 receives kAi s from P2 and computes
k−1 k
Bi = g f (i) hf (i)
= A0 Ai . . . Ak−1 (gh)i mod p
1
i
k
where Bi is used as a public key to encrypt each message mi , ci = (g ki , mi Bi i )
and ki is sampled uniformly randomly from Z∗ .
q
3. P1 sends the nci s to P2 . Since Bi = g f (i) hf (i) = g f (i) h0 = g f (i) , mi can be
decrypted by P2 , using a secret key f (i), if i ∈ σ1 . . . σk . 15
Execution of such a protocol multiple times can allow to Alice to secretly choose
vector of bits, or in other words, e.g. secret integer input.16 It has been developed
1-out-of-n OT where n will be replaced with the number in the protocol. In this
work n = 2 has been used, since messages are binary values. The implementation
described by Naor and Pinkas [17] is a best-known implementation that allows both
extensions to be efficiently incorporated (with limited scalability).
The inclined reader is referred to Goldreich [10] for further deliberations on OT.
Practice. This is a vital part of the Yao’s protocol and its performed before the
evaluation step. Here occurs an exchange of encrypted binary values between host
and guest. These values are used for as guest’s input to the binary circuit, but
without reveling to host the actual input value. This part of the protocol has to
be repeated for every guest’s input bit. More precise, for every input bit the OT
process has to be repeated until pj reveals the input y necessary for the evaluation.
The pj has a vectorial input and it is going to be transfered in ”parallel”, in one
message.
The parallelization of the OT protocol will increase efficiency of the load in
TCP/IP package. Required data to transfered in one OT process is trivial. E.g.
instead of sending a 32 TCP/IP packages for a 32 bit input, only one TCP/IP
package will be sent that contains all data in one ”parallelized” OT message. This
message is actually a string which describes an object in JSON format. This also
satisfies a message box limitation where limx→∞ l = 1 mentioned in section 4.1.2.
15 Vσi
Let ci = (Ui , Vi ), then mσi = f (σ )
Uσ i i
16
Furthermore, such a protocol can be extended to choosing among more than two options.
43

47. In this work the 1-out-of-n Oblivious Transfer technique has been used. This
technique is designed for only 2 parties. These two parties will be called host and
guest. The host is offering n messages mi , where i ∈ {0, . . . , n − 1} and n ≥ 2.
The guest uses his choice value c to discover one, and only one, message mc without
reveling c to the host. The value of n in this work will be n = 2 for only two bits
m0 and m1 .
The functions for serialization and deserialization of private key and public key
have to be provided. A public key will be generated from a dedicated function of
private key object. This public key has to be transmitted over the network to a guest.
Once oblivious transfer start, the guest should own a public key and cipher for every
message. All this data is stored in a public key object and the idea is to transfer
serialized objects (except actual private key) in JSON format. This ability has to be
provided for further development i.e. trying to make smoother data communication
between two different types of systems.
To bring this into practice the oblivious transfer scheme must be followed. It
relies on the RSA cryptosystem, thus private and public key objects were developed.
All objects from following listing are used to contrive oblivious transfer process to
run. This library’s path is crypto/ot and its also a JavaScript library where every
object contains ”ot” prefix:
• otPrivateKey.js is used to create OT private key object
• otPublicKey.js is used to generate OT public key object out of specific pri-
vate key
• otHost.js is an OT host object which provide messages
• otGuest.js is an OT guest object which should choose a message
• crypto/ot/par is OT parallelization library
– otHostPar.js is similar to an array of otHost objects
– otGuestPar.js is similar to an array of otGuest objects
where objects from crypto/ot/par package were developed as an expansion to
crypto/ot objects. From this libraries it can be clearly noticed that technique relies
on RSA cryptosystem. The cryptosystem instances are automatically used by inner
functions in the host/guest objects. All previously listed objects from crypto/ot
package are developed as the part of this work.
Key objects for an application are OTHost whose constructor requires an array
of messages to be chosen, as
44

48. function OTHost(messages, csr),
and OTGuest whose constructor requires a choice index, as
function OTGuest(choice, csr),
from the messages array in the OTHost constructor. Both cases require a csr argu-
ment as well. This argument is a CSRandom object internally used as a cryptograph-
ically secure random number generator17 . The messages array m0 , . . . , mn−1 is an
array of BigInteger objects, while the choice c is an integer value. Reason to chose
a BigInteger object as a message will be explained later on in section 4.2.3.
To provide parallelization there were introduced additional JavaScript objects
OTHostPar and OTGuestPar. These classes contain the same constructors as OTHost
and OTGuest classes, but with arrayed requested arguments. That is a matrix of
messages mji in OTHostPar object and an array of choice values cj in OTGuestPar
object, where j is the OT index. The inner functions are also the same, the only
deference is that parallelized object will have an array to process instead of only one
object. E.g. private/public key generation for only one OT process i.e. every input
bit will require private/public key.
In next listing the ”oth” and ”otg” OT functions are sorted by steps in execution
process (refereed to host/guest):
1. OTHost’s function othGetPublicKey() returns public key intended to guest
2. OTGuest’s function otgSetPublicKey(otPubKeyString) stores public key out
of string received from host
3. OTGuest’s function otgEncodeChoice(toJson) return guest’s encoded choice
intended to host, where toJson is a boolean value used to request response in
stringified JSON format
4. OTHost’s function othCreateCiphers(encodedChoice, toJson) creates mes-
sages ciphers out of guest’s encoded choice
5. OTGuest’s function otgDecryptChoice(ciphers, cipherRandom) decrypts cho-
sen message from received ciphers18
17
A cryptographically secure random numbers are crucial in cryptography and therefore a
CSRandom class is ”imagined” as their generator. The CSRandom is an important object and it
is described in appendix A.
18
A inclined reader is refereed to [17] for description of cipherRandom value.
45

49. Listed functions are designed to be used in single OT execution, dough OTHostPar
and OTGuestPar from crypto/ot/par library use same functions but for multiple
OT executions.
The functions for serialization of the OTPrivateKey data and OTPublicKey ob-
ject in JavaScript have been provided. A BigInteger number is transformed into the
string, rather than transmitting entire BigInteger object. The deserialization pro-
cess is exactly opposite, therefore with an exception on creation of the BigInteger
objects from strings. A BigInteger is indispensable in RSA cryptography, hence
all this deserialized objects will used for all further computations.
4.2.3 Garbled Circuits
Theory. Before elaborating on specific protocols for SMC we need to formalize
the notion of security and define allowed adversely behavior. Any secure function
evaluation (SFE) has to privately compute the correct outputs [Canetti [3], p. 151].
A private computation reveals no input or output data of any party, except what
each party can infer from his own input and output. The computation is performed
correctly if Pi party receives his output yi , such that y1 , . . . , yn = f (x1 , . . . , xn ) is
calculated on all consistently submitted inputs.
The first general SFE protocol for functions represented as one-pass boolean
circuit was introduced by Yao [29] and has been adapted to manifold applications.
The original protocol could only be employed in a two-party setting with semi-honest
parties19 , but was extended to to be suitable for multi-party SFE applications by
Beaver [6].20 In the two-party setting the protocol to securely evaluate (yA , yB ) =
f (xA , xB ) can be outlined as follows [7]:
1. Alice and Bob agree on a circuit C(xA , xB ) = (yA , yB ) to evaluate f . There-
after, Bob constructs the encrypted circuit
EC(EiA (xA ), EiB (xB )) = (EoA (yA ), EoB (yB ))
and sends it to Alice, along with his input EiB (xB ) and the key for Alice‘s
output oA .
The construction of EC requires several steps [13]. Assume that circuit C
comprises gate g, with two input wires wi1 and wi2 as well as one output wire
wo . For each wire, two random keys t0 and t1 are generated to mask wire value
i i
0 and 1, respectively. The wire keys are only known to Bob. Alice, who will
19
A rigorous security proof is presented by Lindell and Pinkas [13].
20
Or the presence of active adversaries by Goldreich [11]
46

50. Figure 4.3: Steps to create the Permuted Encrypted Garbled Truth Table
0 1
be evaluating EC, can not distinguish between wi and wi , thus remaining
oblivious of the wire value. To hinder Alice from gaining knowledge of all
σ κ θ
output wire keys of gate g and limiting their to obtaining wo = g(wi1 , wi2 )
where σ, κ, θ ∈ 0, 1, the truth table (TT) of g needs further processing. For
κ θ σ κ
each entry (wi1 , wi2 ) the corresponding output value wo is encrypted using wi1
σ
and wi2 as keys, hence, Alice can only decrypt a single entry of the TT for
further circuit evaluation. Concludingly, Bob permutes the entries in the TT,
yielding the permuted encrypted garbled truth table (PEGTT), wherein the
position of a specific entry reveals no information about the actual wire values
as in figure 4.3. A more formal construction of the PEGTT can be found in
Catrina [4]. Malkhi [7] propose a cut-and-choose enhancement to this step.
Bob constructs m encrypted circuits ECi and sends all of them to Alice, who
chooses one ECη to be evaluated. Bob reveals the secrets of the other ECi
where i = η to Alice, enabling her to verify the construction of them, since C
is known to both. Therefore the probability for Bob to successfully cheat by
1
constructing tampered circuits is reduced to m.
2
2. Alice obtains EiA (xA ) from Bob, without revealing xA . A OT1 protocol is
employed |xA | times, in order to provide Alice with the appropriate wire keys
wi i for xA [i] = σi , without disclosing wi¯i .
σ σ
3. Than Alice calculates (EoA (yA ), EoB (yB )) from EC(EiA(xA), EiB(xB )) and
sends EoB (yB ) to Bob. Both parties decrypt their respective inputs and con-
clude the SFE.
47

51. Figure 4.4: An overview of Yao protocol.
In this work a shorter version of the Yao protocol has been accepted. This version
skips cheat probability step and assumes that Bob is already trusted party. Since, in
a real-world scenario cheating leads to bad reputation, this can be sufficient motive
to adopt short version of the Yao protocol.
The basic symmetric cryptographic function used for a circuit encoding(garbling)
is SHA-1, which has been described in the section 4.2.1. The encoding of the circuit
can be implemented using a pseudo-function (as is described in detail, for example
in [15]), where the output of the function is used as a one-time pad21 that masks the
values in the truth table representing a gate in the circuit. There has been used the
masking values SHA-1(wi ||k||x||y), SHA-1(wj ||k||x||y) for entry (x, y) of the table of
gate number k, whose input wires are i and j.22 The underlying security assumption
is that SHA-1 is pseudo-random function keyed by wi or wj and applied to other
parameters.
Following enumeration shall clarify the steps to evaluate the Yao protocol from
figure 4.4 in more details:
1. Translate the common functionality f into a circuit C as described at the
beginning of the section.
2. Bob runs the circuit encryption algorithm on C (see figure 4.4).
3. The output is a vector g of n (garbled, keyed, encrypted and sorted) gates
g1 , . . . , gn (with references to the input gates or wires).
21
In cryptography, the one-time pad is an encryption algorithm in which the plaintext is combined
with a secret random key or pad, which is used only once.
22
Note that wires i and j could be input into multiple gates.
48

52. 4. Bob sends g , the keys for his garbled inputs and the random (garble) bits for
all output wires to Alice.
0 1
5. Bob prepares Alice’s garbled input bits kwA and kwA .
x
6. Alice obtains via oblivious transfer all encrypted kwA .
A
7. Alice executes the garbled circuit. The result is a vector of output bits y .
8. Alice sends y to Bob.
There are many other SC schemes for general purposes and specific tasks that
goes beyond the Yao‘s protocol. Those have been proposed in the literature.
Practice. As can be concluded from the theory, the main objective is to develop
libraries to support evaluation of the Yao protocol. Firstly, a main JavaScript li-
brary has to be developed in which functions can be used for Yao protocol execution,
excluding OT protocol. This library has to provide functions for a circuit wire cod-
ing, PEGTT generation, Output Translation Table23 (OTT) generation and circuit
evaluation. Secondly, two JavaScript objects have to be developed intended to host
and guest, or Bob and Alice respectively. These classes should use functions from
the main library to accomplish their protocol requirements. The guest will evaluate
the circuit will expect from host to send encrypted (garbled) circuit, host’s garbled
inputs and decryption key for the output bits, or OTT.
For example, host object has to be able to create encrypted circuit out of BCDL
object and to pack all necessary data in order to transfer to guest Yao object. From
here Yao guest object should be able to unpack the received data and to evaluate
the garbled circuit once OT process is completed.
This system requires, as mentioned in previous chapters, a symmetric crypto-
graphic function library (section 4.2.1) used for a circuit garbling and a library for
oblivious transfer feasibility (from section 4.2.2). Of course, whole system relies on
browser to browser exchange subsystem presented in this chapter under section 4.1.
Both players should run this application from their web browsers, hence the usage
of this system is inevitable for Yao protocol and oblivious transfer data exchange.
All objects from the following listing are used to accomplish specific Yao protocol
tasks. The libraries path is crypto/yao where every instance contains ”yao” prefix.
There is a one JavaScript library and two JavaScript objects:
23
Output Translation Table is some sort of decryption key for the circuits output bits. This
information is obligate, since guest should decrypt circuit’s output after evaluation. This was
already pointed out in the theory paragraph.
49

53. • yaoGarbledCircuit.js is a main library with dedicated functions used to
garble and evaluate the circuit.
• yaoHost.js is an object intended to the host with all the necessary functions
used to accomplish host’s part of the protocol
• yaoGuest.js is an object intended to the guest in a Yao application
where host/guest object are developed to have benefit from yaoGarbledCircuit.js
library. This library deals with a BigInteger objects in more that 90% of its content.
Thus, inner functions use BigInteger predefined functions for power, module, shift,
AND, OR and XOR operations. The entire crypto/yao package is developed as the
part of this work.
Key objects for an application are YaoHost whose constructor requires an array
of chosen circuit inputs, BCDL object and CSRandom object, as
function YaoHost(input, circuit, csr),
and YaoGuest whose constructor requires array of the chosen inputs and BCDL
object, as
function YaoGuest(input, circuit),
where circuit argument is BCDL object they’ve agreed upon.Only YaoHost require
a csr argument. This argument is a will be used internally as a cryptographically
secure random number generator used to garble the circuit24 .
In next listing the ”yaoh” and ”yaog” protocol functions are sorted by steps in
execution process (refereed to host/guest):
1. YaoHost’s function yaohCreateWireCodes() returns encrypted wi codes for
all wires in the circuit
2. YaoHost’s function yaohCreatePEGTT() will return circuit’s Permuted En-
crypted Garbled Truth Table
3. YaoHost’s function getOTT(gates, wireCodes, outputWires) return Out-
put Translation Table before evaluation
4. YaoHost’s function yaohPackData() returns packed data ready to be trans-
fered to the YaoGuest object
24
Same as in host/guest constructors in Oblivious Transfer library from section 4.2.2.
50

54. 5. YaoGuest’s function yaogUnpackData(dataString) shall unpack and store
the data received from the YaoHost object
6. YaoGuest’s function yaogEvaluateCircuit() will evaluate the circuit, once
guest has all necessary data, and return the result25
As mentioned, the listed functions from JavaScript objects are designed to use func-
tions from yaoGarbledCircuit.js library, in order to accomplish Yao protocol and
to facilitate data exchange between the YaoHost and YaoGuest instances.
4.3 Web Yao Application Structure
Infrastructure of application has to be designed to use entire crypto package de-
scribed in section 4.2. Even if the all necessary functions have been provided in this
package, there is also a necessity for work flow of those subsystems. Therefore, an
application work flow package has to be developed. This package has to provide work
flows for message exchange session, oblivious transfer and yao protocol subsystems.
A web application have to be separated in two smaller applications, host and
guest specific applications. Both these applications should contain objects from
crypto package in order to go through all necessary processes, until circuit result is
revealed to both parties. E.g. even if oblivious transfer is a part of the Yao protocol
the libraries were separated, but still both libraries have to be employed.
As such, both main web applications objects will contain three sub-library ob-
jects. The first object will open and activate a obligate browser to browser message
exchange session. The second one will start first part of Yao protocol. The second
section will finish, in its second part, after the oblivious transfer. The third ob-
ject will provide the application for OT protocol. Exact application steps will be
explained later in this section.
One of key requirements was to automatize the entire web application flow, hence
a JavaScript /app package has been developed. With this package the application
flow is fully automatized, once player inserts his input data and starts with execution.
In following listing describes all package libraries and objects from figure 4.5:
• appAjaxReq.js library is used to facilitate usage of an AJAX GET/POST
request in a web application
• appBw2bw.js object was written to follow step execution in a browser to
browser exchange session to effectuate an active session
25
A inclined reader is refereed to [17] for description of cipherRandom value.
51

55. Figure 4.5: Web application structure objects
• appHost.js is a work flow object for every host’s step until application exe-
cution is over
• appGuest.js is a work flow object for every guest’s step until application
execution is over
• app/ot package contains OT work flow objects
– appOtHost.js is a JavaScript object used for host’s OT execution
– appOtGuest.js is an object used for guest’s OT execution
• app/yao package contains Yao protocol work flow objects
– appYaoHost.js object contains 2 parts for a host’s Yao protocol execution
– appYaoGuest.js is a 2 part JavaScript object for a guest’s Yao protocol
execution
All listed objects are previously mentioned application objects, with exception on
appAjaxReq.js which is a facility library for AJAX requests. All the application
objects are closed in a their step execution function. This function shall be invoked
in order to proceed to a next application’s step. It will automatically check a sub-
application’s inner state value and regarding to that value the function shall decide
which command to execute. Once application arrives to predefined lastState value,
it will move on to the next sub-application until the main application steps are
completed. Thus, application steps are limited by its final state hard coded in
lastState variable, while current state can be read from state variable.
These functions are developed for web application functions with the ”mb” prefix
from the JavaScript library app/appAjaxReq.js:
• mbGetMsg(url, destObject) get a message from the box
• mbDelMsg(url, destObject) delete a message in the box
52

56. • mbReqSend(url, destObject) check a message can be sent
• mbSendMsg(url, message, destObject) send a message
where url is URL of the ServletME class and detsObject is an object to receive
a response value. It is obvious that all these functions are valueless except the last
one, where a message argument is a pointer to the message to be sent. This function
calls the ajaxDoPost function, while all the others invokes the ajaxDoGet function
from the appAjaxReq.js library already mentioned in the section 4.1.
The browser to browser message exchange sub-application for host and guest
are the same. This object is named AppBw2bw and it contains only one application
step. It is already mentioned that the message exchange session will be inactive
until all players join the session. Thus, this step will constantly test the statement
of the exchange session. Once session becomes active the application will move on
the AppYaoHost/AppYaoGuest object in the first part of Yao application.
Both, the host and the guest, Yao sub-applications are divided in 2 parts. First
part shall be executed before OT step of the Yao protocol (figure 4.4). The second
part shall be executed once the OT process in accomplished. Hence, the two parts
of the host/guest Yao protocol in a web application contain fallowing states:
• Host - Supplier (part 1)
1. Create wire codes for entire circuit
2. Create Permuted Encrypted Garbled Truth Table (PEGTT)
3. Create Output Translation Table (OTT)
4. Garble Host’s inputs used for evaluation
5. Pack data necessary for the encrypted (garbled) circuit evaluation
6. Send request to transmit data to guest’s message box
7. Acknowledge of data reception
• Guest - Buyer (part 1)
1. Check in message box for garbled data transmitted by host
2. Store data in YaoGuest object
3. Delete received data message from message box
• Host - Supplier (part 2)
1. Wait to receive the circuit evaluation result from guest
53

57. • Guest - Buyer (part 2)
1. Prepare host’s and guest’s garbled inputs and evaluate the circuit
2. Send request to transmit the circuit evaluation result
3. Acknowledge of result reception
A reader can notice that there is no single lastState value for this object. Instead
this object has lastState1 and lastState2 values. This is exactly the same ap-
proach as in the other applications, it can be rather considered as two separated
sub-applications. Once application arrives to predefined lastState1 value, it will
move on to the OT sub-application. On the lastState of OT sub-application the
main application will execute once again the Yao sub-application (2nd part). It will
start from lastState1 until it reaches the lastState2 inner state value.
As said, after the first part Yao sub-application the main application will proceed
to OT sub-application. The final application will use only crypto/ot/par package,
the OTHostPar and OTGuestPar objects. This can be seen in following host/guest
state listing of the oblivious transfer work flow in a web application:
• Host - Supplier
1. Create public keys for Guest
2. Send request to transmit public keys
3. Acknowledge of public keys reception
4. Wait to receive encoded choice of message from Guest
5. Create encoded choice ciphers
6. Send request to transmit ciphers
7. Acknowledge of ciphers reception
8. Delete Guest’s encoded choice message from message box
• Guest - Buyer
1. Read public keys submitted by Host
2. Setup public keys
3. Delete Host’s public keys message from message box
4. Encode circuit input choices
5. Send request to transmit encoded choices
6. Acknowledge of encoded choices reception
7. Wait to receive ciphers for each message
54

58. Figure 4.6: Web Yao application layered communication between host and guest
8. Decode chosen messages
The parallelization is obvious since host is creating multiple keys in first OT step.
Each key is going to be used for one OT process i.e. one key for every guest’s input
bit. Also in this listing can be noticed that in this process there is a lot of interaction
between players. This interaction relies on the previously mentioned appAjaxReq.js
library.
The key objects in main application are AppHost and AppGuest, located in the
app package. These objects are fully automatized. From this point, in any custom
web application a constructor of the JavaScript object AppHost shall be called with
function AppHost(input, circuit, csr, urlMsgBox)
which require four arguments. It requires desired host’s input to the circuit, cir-
cuit itself as BCDL object, cryptographically secure random generator and URL to
browser to browser message exchange web server26 . After the AppHost initialization
the AppYaoHost and AppOtHost objects will be generated internally.
As has been said, once the AppHost object is generated all the steps should be
executed with only one function. Since there are multiple sub-applications, there has
to be provided additional function to check internal sub-application state. Mentioned
functions, for AppHost, are the following:
• apphExecute() will return current application state after the application step
execution
• function apphIsLastState() returns boolean value that says if application
has reached its last state
26
The URL value shall be direct link to the ServletME, as described through example in section
4.1.1.
55

59. Figure 4.7: Entrance portal for the web SBC application
Of course, the AppHost object will call this sub-application functions automatically.
Thus, every sub-application has this functions, even AppHost. After execution step
the execution function shall return application current status value. This values is
going to be used to visualize steps in an application GUI, in client’s browser.
In this listings were only presented host’s application functions with ”apph”
prefix. The AppGuest object have the same functions (even constructor arguments)
as AppHost, but with prefix ”appg”.
4.4 Graphic User Interface Design
It has been said, and showed, in the section 2 that the final web SBC application
starts with an internet portal. On this portal a player can host a SBC and invite the
guest to join. This section will only provide additional information by explaining a
scenario from 4.7 and 4.8 figures.
Once player enters the portal he can expect a few input requests. On the left
side of the figure 4.7, a player should choose preferred function to compute with
his business partner. When partner chooses the evaluation function, than he should
input required emails into text boxes. After that he should just press ”Host SBC”
button that will despatch player’s request to invite guest (or buyer) to join the newly
created SBC session.
From that point, player is automatically redirected to the host (or supplier) SBC
56

60. Figure 4.8: The web SBC application in the middle of an evaluation
application and his invitation mail will be sent to the guest from the hosting web
server. Now, the host can input the requested data and initiate the SBC execution.
This event will take block player’s inputs and than player has to wait until the guest
joins. When player receives the join link he is going to be redirected to the buyer’s
application. Once both players have started with application execution than they
can see the visual status of their secure business computations, as on the left side of
the figure 4.8.
Application tends to check all check boxes, until the SBC is completed and
result is computed (for guest) or receved (for host). This result will be shown in
SBC output text box, as shown on the right side of the figure 4.8. Of course, this
completes the secure business computation and now they may start another one.
57

61. Chapter 5
Evaluation
The Secure SCM project will apply secure multi-party computation protocols to
collaborative Supply Chain Management (SCM). The privacy guarantees of secure
multi-party computation, i.e. the confidentiality of the inputs, fully remove the
data sharing risks, i.e. no supply chain participant has to reveal its data. Nev-
ertheless, the resulting globally optimized supply chain, has clear cost advantages
over currently available solutions with local decision making. These advantages will
provide a new perspective to collaborative supply chain management extending its
scope to a number of application domains including manufacturing, logistics, design
outsourcing, and others.
Improvement of SCM is a Secure SCM project funding, but this work shows an
example of secure collaboration. Therefore, in this chapter briefly introduces a Joint
Economic Lot Size (JELS) function used in the collaborative SBC model.
5.1 Joint Economic Lot Size
In a simple supply chain setting there is a single buyer (party A) and a single supplier
(party B) of a specific product. The buyer and the supplier have negotiated a fixed
supply quantity of d units per period. Without loss of generality it is assumed that
the buyer decides upon his order quantity, denoted by qA , and the (corresponding)
number of orders d/qA which he places to the supplier. It is assumed that the
supplier has sufficient capacity to fulfill the buyer’s orders and that the supplier’s
lead time is zero. The buyer’s total relevant costs T RCA (qA ) are given by
d · fA qA
T RCA (qA ) = + · hA
qA 2
58

62. Figure 5.1: Periodic progressions of the supplier’s and buyer’s inventories under a
lot-for-lot production policy.
where fA denotes the buyer’s fixed cost per order and hA his inventory holding cost
per unit and period. The first term in this expression represents the fixed ordering
costs and the second term the inventory holding cost. Under the given assumptions,
qA
the average inventory per period is 2 (see figure 5.1). The buyer’s economic order
∗
quantity (EOQ), denoted by qA , can then be expressed as
∗ 2 · d · fA
qA =
hA
It is assumed that the supplier follows a lot-for-lot production policy. He cannot
accommodate lot-streaming and delivers the entire production batch after its com-
pletion. The supplier’s total relevant costs T RCB (qB ) are
d · fB d · qB hB
T RCB (qB ) = + ·
qB 2 c
where qB denotes the supplier’s production lot size, c the production capacity per
period, fB the setup cost per production lot and hB his inventory holding cost per
unit and period.
∗
The supplier’s economic lot size, denoted by qB , can be expressed as
∗ 2 · c · fB
qB =
hB
Under the assumption of a lot-for-lot production policy, the lot size of the supplier
will correspond to the order size of the buyer, i.e. qB = qA . The inventories of the
59

63. Figure 5.2: Supply chain’s costs versus lot size
supplier and buyer will have the periodic progressions as depicted in figure 5.1. If
there is no joint decision making between the buyer and the supplier, both parties
∗ ∗
would like to realize their individual optimal quantities qA and qB . In this work it is
∗
assumed that the buyer places orders of size qA and that the supplier has no means
∗
to influence the buyer’s decision. In this case qB = qA , resulting in total joint costs
of
∗ ∗ ∗
JT RC(qA ) = T RCB (qA ) + T RCA (qA )
Based on these results it is easy to explain the underlying rationale of the JELS
∗ ∗
model: for any setting in which qA = qB there will be a ”Joint Economic Lot
Size” (JELS) that leads to minimal joint costs of the buyer and supplier such that
∗ ∗ ∗
JT RC(qJ ) < JT RC(qA ). The JELS, denoted by qJ , can be expressed as:
∗ 2 · d · (fA + fB )
qJ = hB
d· c + hA
∗
The figure 5.2 depicts the supply chain’s costs versus lot size. Obviously, qJ lies
∗ ∗
between qA and qB .
5.2 Setup
Based on the general description of secure two-party computation provided in the
previous chapters now it will be shown how a secure protocol for the JELS model
60

64. Figure 5.3: JELS circuit
can be implemented. Thus, in the following text first propose the relevant JELS
∗
circuits for computing qJ . Thereupon it must be specified what the building blocks
are used for the development of a BCDL object for the JELS model.
Given a secure protocol, two supply chain parties can engage in collaborative
planning without having to reveal any private data in the process of calculating the
∗
joint result. In order to implement a secure protocol for computing qJ based on
Yao’s protocol we thus need to construct the corresponding boolean circuit BCDL
∗
object for qJ . It is emphasized that the necessary boolean circuits are one-pass, i.e.
they may not contain feedbacks, registers nor similar constructions. To reduce the
complexity of the circuits, it should compute qJ 2 instead of qJ . This significantly
∗ ∗
reduce the number of necessary gates, i.e. root computation is saved in the circuit
for qJ 2 . Instead, qJ 2 can be used locally and non-securely to compute qJ without
∗ ∗ ∗
any loss of privacy, since both values can be transformed into their counterpart by
a simple arithmetic operation.
A qJ 2 formula can be represented as concatenations of basic arithmetic opera-
∗
tions. It can therefore directly compile the boolean circuits from the formulas given
that we have building blocks for the basic arithmetic operations (in terms of sub
circuits). Figure 5.3 depict the composition of basic arithmetic operations into a
boolean circuit according to the formula of qJ 2 . It is assumed that all input and
∗
output values are within a jointly agreed domain D = [0; 2l − 1]. In figure 5.3 gray
values on the left denote the private part of the buyer’s input to the circuit, while
gray values on the top denote those of the supplier.
61

65. Firstly, a Boolean Circuit Description Language (BCDL) object has to be gen-
erated before evaluation. It can be described with a SBCL1 , which will be parsed
to In-memory formula2 object and then compiled to BCDL object, as described in
section 3.3. Once BCDL object is created, the next step would be to deploy browser
to browser message exchange system, and to upload the JELS BCDL object together
with the web application onto the web server.
In this work a demo web application stands behind a GUI where host (Supplier)
is asked to insert his email address and guest’s (Buyer) email address in order to
start SBC. Once supplier executes the SBC session the system will automatically
send invitation email to the buyer. In this invitation the buyer can see who hosted
the SBC session. If buyer is willing to execute the SBC with supplier he should click
on direct link, written in email, to join SBC session. When buyer joins the session
he should insert his private data and start the computation. Now both players can
only wait until protocol is evaluated.
In order to speed up secure computation all circuit input variables shall be pre-
calculated values, otherwise the circuit size will increase which will linearly increase
the computation time. Following code demonstrates JELS model described with
SBCL for precalculated input values:
1: default-bits:32
2:
3: _2dfA:Bob
4: hA:Bob
5: _2dfB:Alice
6: dhB_c:Alice
7: qJstar2:Bob, Alice
8:
9: qJstar2=(_2dfB+_2dfA)/(dhB_c+hA)
In this formula Bob is a supplier and Alice is a buyer. An example of precalculated
value is 2 · d · fA required to be inserted by Bob. He can’t input all three values if
desire is to minimize the circuit, because otherwise three building blocks has to be
used. Detailed description of the SBCL language can be found in section 3.1.2.
Previously described SBCL object will be parsed to in-memory formula and then
compiled to BCDL. A final JELS BCDL object, with 32 bit input size, exported to
JSON JavaScript variable looks like following:
1
Secure Business Computation Language is described in section 3.1.2
2
In-memory formula is described in section 3.1.
62

66. Figure 5.4: Number of gates in JELS circuit, respect to input size
var circuit = {
"input":[[{"wires":[0,...,31],"name":"2*d*fa"}...
"tt":[[0,1,1,0],[0,0,0,1],[0,1,1,0],...
"output":[[{"wires":[24009,24010,24011,24012,24013,...
"gates":[[0,32,128],[0,32,129],[1,33,130],[130,129,131],...
}
This circuit weights 23914 gates and 24042 wires, while its memory size is 676.006
bytes, or 660KB. These from all gates there are 2 ∗ 158 = 314 for 32 bit addition
and 23599 for 33 bit division. There can bi noticed that one gate is missing and this
is a zero gate that is static for entire circuit, thus it will be reused whenever there
is a necessary for binary zero value.
Once the BCDL object is ready the web based SBC application, from section 4.3,
should be tested. These testings were run in a test environment and as such cannot
be considered relevant to real business application. But yet, all the data from test
can be used in a consideration for ”minimum” time required for entire flow of the
application.
The tests were run on one work station which runs 32-bit operating system
Windows Vista Enterprise with Service Pack 1 on Intel Core Duo T7300 2.0GHz
with 2.00GB of RAM memory. This work station runs a web server on Apache
Tomcat 5.5 required for the ”browser to browser” message exchange subsystem and
the web SBC application with its libraries. As testing browsers there have been used
Mozilla Firefox 3.6 and Google Chrome 4.0, the latest available versions at the time.
It is important to mention that every instance (or process) runs on one Intel core,
63

67. by affinity settings in Windows Task Manager.
While there was a support in Mozilla Firefox to run a two separated instances,
there was none for Google Chrome. For that reason, there has been installed a
VMware Player 3.0 to run a Linux Ubuntu 8.4 virtual machine. The virtual machine
was set to use one, previously mentioned, Intel core and 512MB of RAM memory.
In particular, this virtual machine was used to compare evaluation performance for
two different instances of Google Chrome browsers.
Running two different instances is important for comparison equality. But, the
key solution was to use two instances which will use a separate memory space for their
cache operations i.e. cookie storage. Thus, an instance require its own JSESSION
cookie in order to run message exchange session, which is inevitable for the web SBC
application.
All the tests start its execution once the application runs on both parties. But
still, the application start its execution with confirmation of an exchange session
activation. If one party executes the application before activation of the message
exchange session, it would have to wait until the other party joins the exchange
session. This will increase overall time of the execution.
5.3 Results
Results are represented rispect to their effective time and their wait time, in seconds.
The actual timing of effective or wait time is not present on the chart, instead they
are presented by section. In total there is four sections: browser to browser message
exchange activation, first part of Yao’s protocol, OT protocol and secong part of
Yao’s protocol. All these web SBC sections are sorted on the charts in down up
order, as presented in section 4.3.
All the timings are related to execution of the AppHost, and AppGuest, step
execution function apphExecute() described in the section 4.3. The effective time
means that application has changed its state after performing an execution on sec-
tional objects e.g. AppOtHost, AppYaoHost, etc. Everything else counts as the
waiting time in overall time of the web SBC application execution. Since most im-
portant time is their wait efficient time, the following text will focus mostly onto
it.
Referencing to the figure 5.5, it can be seen how two Mozilla Firefox 3.6 per-
formed on the same work station, where each had one dedicated Intel core. Im-
portant notation is that the host had more efficient time in the first part of Yao’s
64

68. Figure 5.5: The web Yao application benchmark for two instances of Mozilla Firefox
3.6 on the same work station
protocol, while in the second part he had only mostly wait (inefficient) time. This
follows in relation to the exactly opposite result of the guest party.
In the figure 5.5 host performed first part of Yao’s protocol in 85s, while gest
performed the second part of Yao’s protocol in 226s. The approximate total web
SBC application run time was 323 seconds.
The figure 5.6 shows comparison between Google Chrome 4.0 and Google Chrome
4.0 that runs on virtual machine. They both performed on the same work station,
where each had one dedicated Intel core. It is important to notice that Linux Ubuntu
8.4 virtual machine performed extremely fast, comparing to Windows Vista SP1.
It can be noticed in the figure 5.6, for the first case, that the host performed first
part of Yao’s protocol in 44s, while gest performed the second part of Yao’s protocol
in 79s. The approximate total web SBC application run time was incredible 129
seconds. In the second case, the host performed first part of Yao’s protocol in 20s,
while gest performed the second part of Yao’s protocol in 272s. The approximate
total web SBC application run time was 297 seconds.
These results are extremely different respect to the previously discussed from
figure 5.5. It is obvious that Google Chrome 4.0 on Linux Ubuntu virtual machine
performed more than twice as fast, as one that runs on Windows Vista, for the first
65

69. Figure 5.6: The web Yao application benchmark between Google Chrome 4.0 and
Google Chrome 4.0 that runs on virtual machine
part of Yao protocol. In second part of the Yao protocol the Linux Ubuntu virtual
machine performed more than three times faster. While there is still a big question
regarding this results it was obvious that Linux Ubuntu 8.4 performed better, in
this particular case.
The figure 5.7 shows comparison between instance of Google Chrome 4.0 and
instance Mozilla Firefox 3.6 that runs on the same work station, where each had
one dedicated Intel core. It is important to notice that Linux Ubuntu 8.4 virtual
machine performed extremely fast, comparing to Windows Vista SP1.
From the chart 5.7, in the first case, the host performed first part of Yao’s
protocol in 87s, while gest performed the second part of Yao’s protocol in 274s.
The approximate total web SBC application run time was poorly 380 seconds. For
the second case, the host performed first part of Yao’s protocol in 42s, while gest
performed the second part of Yao’s protocol in 193s. The approximate total web
SBC application run time was 245 seconds.
These results are satisfying and similar to some previously discussed results from
figures 5.5 and 5.6. It is shown that Google Chrome 4.0 on Windows Vista performed
in the first part of the Yao protocol, while Mozilla Firefox 3.6 on Windows Vista
performed in the second part.
66

70. Figure 5.7: The web Yao application benchmark between Mozilla Firefox 3.6 and
Google Chrome 4.0 on the same work station
VF VF VC UC UC VC VF VC VC VF
Yao1 / Yao2 85 226 44 79 20 272 87 274 42 193
Total 323 129 297 380 245
≈ in seconds
Host is left; V - Vista, U - Ubuntu VM; F - Firefox, C - Chrome
Table 5.1: The web Yao application benchmark. Results form effective Yao and
total evaluation run time
Of course that there could be some performing variations, but these values are
measured multiple times and only the best performed were chosen. But these vari-
ations are almost irrelevant, like e.g. first and fourth test where Mozilla Firefox
performed wiht variance of ≈ 2%, as shown in table 5.1 Additionally, these results
don’t (almost) have any network delay, but it should be considered that the delay
time directly effect overall execution time. Yet, effective time can be counted as
definite, since most of it is spent on computation.
67

71. Chapter 6
Conclusion and Future Work
Applied SBC on the JELS model is extremely relevant from an industry perspective.
It exhibits numerous features that makes it very attractive for secure multi-party
computation in a supply chain context. The practical obstacles related to the JELS
model implementation has been shown: improving supply chain efficiency through a
joint economic lot size between a buyer and a supplier is inhibited by need to reveal
sensitive private cost and capacity data. It is assumed that in most supply chain
settings neither one of the parties would want to share this data. Secure two-party
computation is seen as a viable measure to overcome these obstacles.
The main objective was to provide web based generic secure function evaluation
system. The work was separated in two parts. First part required to develop high-
level secure economic function description language SBCL. The second task was to
parse SBCL and to compile BCDL object. Additional tasks were to minimize number
of gates in the boolean circuit. In the second part the first obstacle was to make
possible communication in between two internet browsers. The second one was to
develop all the cryptographic libraries indispensable for the SBC application, while
time limits have to be satisfied. And third task was to develop libraries intended
to enable the web SBC application flow smoothly and automatically. An additional
task was to prepare demo version which will be presented to future partners. The
result is the fully operational application presented in chapter 4. It can be concluded
that all objectives of this thesis work were accomplished.
This work benefits from cutting edge technology in security models and proto-
cols. Learning them were interesting experience, especially in a highly professional
working team. An interesting fact was that boolean circuits were modeled in soft-
ware, evaluated in an internet browser and all for business purpose. These extremes
are interesting since they all appertain to the information engineering topic, so as
68

72. the course of my university. In conclusion, the overall work was really good planed,
professionally supported and I would estimate this work as an excellent carrier ex-
perience.
After this research work the ideas continue to be developed even further. In
fact, the current implementation of the secure two-party computation system can
be extended in many ways. Some considered future work ideas follow up in text.
Preliminary analysis suggests that the protocol’s performance significantly de-
pends on the division operation. Thus, future work can be dedicated to finding
improvements for building blocks of the protocols.1 Finding new improved building
blocks for division is likely, and thus it will be of low priority. This could lead to two
further contributions to the state-of-the-art: a prototype of the JELS model soft-
ware for future demonstration and an analysis of the performance characteristics of
different secure (two-party) division protocols and other future protocol design.
Currently there is no implementation can prevent a malicious party from abort-
ing the protocol prematurely(unfair termination) e.g. after learning its output and
before the other party learns its output.2 There is no perfect solution for this pro-
tocol issue and existing solutions are complex, but some can be implemented [20].
One of interesting future improvements is BCDL circuit compiler integration in
L1 language. This language is used for faster development and benchmarking of
cryptographic protocols described in Schr¨pfer [24]. It already supports evaluation
o
of circuits, but has no circuit generation component.
While the generic construction of Yao can be used to implement any function-
ality, more efficient constructions can be designed for specific tasks, e.g. computing
comparisons or intersections, evaluating polynomials or querying a database. A se-
cure protocol for a more complex tasks can use a circuit whose inputs are results of
specialized constructions. For example, the protocol in [21] runs a circuit that com-
putes statistical data based on the secure database queries results, or the protocol
in [13] runs a circuit that uses the results of oblivious polynomial evaluation.
This system is built for secure business computation between two parties. There
is also a large body of research on SMC, for either combinatorial or algebraic circuits,
with different trust assumptions (see e.g. [11, 14, 6]). A natural future step is
to implement the SBC paradigm in the multi-party scenario. An additional open
challenge is to devise fair termination protocol techniques even for SMC.
1
Proposed division block by Kerschbaum and Schr¨pfer has significantly reduced the size [19].
o
2
On the other hand, a premature termination of the protocol by one party is detected by the
other party, which in many scenarios can then take measures against the corrupt party.
69

73. Appendix A
Cryptographically Secure
Random Number
Random numbers are crucial in cryptography. Typically, they are added to the
input data as padding to ensure the uniqueness when generate secure cryptographic
keys. The security of these cryptographic procedures relies on random number that
cannot be predicted.
A true random number should not be influenced by external conditions, therefore
some computers use a hardware-based random number generator, which measures
an unstable electronic circuit or radioactive decay or other random physical process
and thus can achieve independence of external effects. This is the case where such
a hardware may not be practical, and computers have to fall back on software algo-
rithms. Pseudo-random number generators use deterministic algorithm to generate
random numbers, they are initialized, or ”seeded”, using a random number such as
the current time.
There was an obvious necessity for Cryptographically Secure Random number
generator. That is why a CSRandom class has been provided. This class doesn’t offer
cryptographically secure random numbers, instead it is designed as an option for
future development since at the moment there were no libraries available that can
handle the problem. Otherwise the possibility to track down the random number
generator can put entire system to risk. For example, ff the algorithm and the initial
seed values are known, the random numbers can be predictable. That is why these
random number generators are termed pseudo-random number generators.
In the final web SBC application CSRandom class is used for the pseudo-random
number generation. It is used in all, previously mentioned, cryptographic libraries
from crypto package. Thus it is meant to benefit from the dedicated CSRandom
70

74. object function in order to provide OT and Yao cryptographic steps with crypto-
graphically secure random number generator. This function is
function getCSRandom(bits, prime)
where the requested arguments are integer random number bit size and request for
boolean value, if prime number is requested. Return value is meant be BigInteger
number from JavaScript Big Number library, or jsbn.js library.
71

75. Bibliography
[1] N. Nisan A. Ben-David and B. Pinkas. Fairplaymp: a system for secure multi-
party computation. In Proceedings of the 15th ACM Conference on Computer
and Communications Security, pages 257–266, New York, NY, USA, 2008.
ACM.
[2] G.R. Blakley. Safeguarding cryptographic keys. In Proceedings of the 1979
AFIPS National Computer Conference, pages 313–317, Monval, NJ, USA, 1979.
AFIPS Press.
[3] R. Canetti. Security and composition of multiparty cryptographic protocols.
Journal of Cryptology, 2000.
[4] O. Catrina. Cryptographic aspects - secure computation models and frame-
works. Technical report, SAP AG and Technische Universiteit Eindhoven and
International University in Germany, 2008. SecureSCM Deliverable D9.1.
[5] C.-K. Chu and W.-G. Tzeng. Efficient k-out-of-n oblivious transfer schemes
with adaptive and non-adaptive queries. In PKC 2005: Proceedings of the 8th
International Workshop on Theory and Practice in Public Key Cryptography,
pages 172–183, Berlin, Heidelberg, 2005. Springer.
[6] S. Micali D. Beaver and P. Rogaway. The round complexity of secure proto-
cols. In Proceedings of the twenty-second annual ACM symposium on Theory
of computing, pages 503–513, New York, NY, USA, 1990. ACM.
[7] Benny Pinkas Dahlia Malkhi, Noam Nisan and Yaron Sella. Fairplay - a secure
two-party computation system, 2004.
[8] Funke Daniel. Secure evolutionary algorithms for collaborative supply chain
planning. Master’s thesis, Baden-W¨rttemberg Cooperative State University,
u
2009.
72

76. [9] C. Crepeau G. Brassard and J.-M. Robert. All-or-nothing disclosure of secrets.
In Proceedings on Advances in cryptology, pages 234–238, London, UK, 1987.
Springer.
[10] O. Goldreich. Volume 2: Basic applications. In Foundations
of Cryptography, Cambridge, UK, 2004. Cambridge University Press.
http://books.google.com/books?id=Cy1wnNUT3DYC.
[11] O. Goldreich, S. Micali, and A. Wigderson. How to play any mental game
or a completeness theorem for protocols with honest majority. In STOC ’87:
Proceedings of the nineteenth annual ACM conference on Theory of computing,
pages 218–229, New York, NY, USA, 1987. ACM.
[12] A. Karatsuba and Y. Ofman. Multiplication of many-digital numbers by au-
tomatic computers. In Proceedings of the USSR Academy of Sciences, pages
293–294, 1962.
[13] Y. Lindell and B. Pinkas. A proof of yao’s protocol for secure two-party com-
putation. Technical report, Cryptology ePrint Archive, 2004.
[14] S. Goldwasser M. Ben-Or and A. Wigderson. Completeness theorems for non
cryptographic fault tolerant distributed computation. In Proceedings of 20th
Annual Symposium on the Theory of Computing (STOC), pages 1–9, 1988.
[15] B. Pinkas M. Naor and R. Sumner. Privacy preserving auctions and mechanism
design. In Proceedings of the 1st ACM conf. on Electronic Commerce, 1999.
[16] M. Naor and B. Pinkas. Oblivious transfer and polynomial evaluation. In
Proceedings of the thirty-first annual ACM symposium on Theory of computing,
pages 245–254, New York, NY, USA, 1999. ACM.
[17] M. Naor and B. Pinkas. Efficient oblivious transfer protocols. In SODA ’01:
Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algo-
rithms, pages 448–457, Philadelphia, PA, USA, 2001. Society for Industrial
and Applied Mathematics.
[18] Flynn Michael J. Oberman, Stuart F. Division algorithms and implementations.
In Proceedings of IEEE Transactions on Computers, pages 833–854, 1997.
[19] R. Piberbik, F. Kerschbaum, and A. Schr¨pfer. On the computation of secure
o
economic joint lot sizes. In To be published., pages 1–20, 2010.
[20] B. Pinkas. Fair secure two-party computation. In Proceedings of Eurocrypt 03,
LNCS 2656, pages 87–105. Springer-Verlag, 2003.
73

77. [21] R. Kumar M. Reiter R. Rubinfeld R. Canetti, Y. Ishai and R. Wright. Selective
private function evaluation with applications to private statistics. In Proceed-
ings of Twentieth ACM Symposium on Principles of Distributed Computing
(PODC), 2001.
[22] N. P. Redkin. On the minimal realization of a binary adder. In Proceedings of
Probl. Cybern, pages 181–216, 1981.
[23] O. Goldreich S. Even and A. Lempel. A randomized protocol for signing con-
tracts. Communications of the ACM, 1985.
[24] A. Schr¨pfer, F. Kerschbaum, D. Biswas, S. Geißinger, and C. Sch¨tz. L1 - faster
o u
develop-ment and benchmarking of cryptographic protocols. In Proceedings of
ECRYPT Workshop on Software Performance En-hancements for Encryption
and Decryption and Cryptographic Compilers (SPEED-CC ’09), 2009.
[25] A. Shamir. How to share a secret. In Proceedings of Communications of the
ACM, pages 612–613, 1979.
[26] W.-G. Tzeng. Efficient 1-out-n oblivious transfer schemes. In PKC ’02: Pro-
ceedings of the 5th International Workshop on Practice and Theory in Public
Key Cryptosystems, pages 159–171, London, UK, 2002. Springer.
[27] Heribert Vollmer. Introduction to Circuit Complexity: a Uniform Approach.
Springer Verlag, 1999.
[28] Andrew Chi-Chih Yao. Protocols for secure computations (extended abstract).
FOCS, 1982.
[29] Andrew Chi-Chih Yao. How to generate and exchange secrets. In Proceedings
of the 27th Annual Symposium on Foundations of Computer Science, pages
162–167, Washington, DC, USA, 1985. IEEE Computer Society.
74