University of TriesteItaly

Master of Science in Computer Engineering

Master Thesis

Secure Business Computationby using Garbled Circuits in a Web Environment

by ILIC Dejan

UNITS Supervisor

DR. BARTOLI Alberto

Piazzale Europa 1

34127 Trieste, Italy

SAP Supervisor

M.Sc. SCHROPFER Axel

Vincenz-Prießnitz-Straße 1

76131 Karlsruhe, Germany

March 5, 2010

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 Schropfer,

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

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 e focalizzato in particolare sulla funzione Joint Economic Lot Size.

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.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Conclusion and Future Work 68

A Cryptographically Secure Random Number 70

2

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.

1Security&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

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

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

oblivious transfer (OT 21 ) 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

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

1An simple economic function is expected that can be built with four basic arithmetical operators.

6

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

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

1Depth of a circuit, denotes the maximum distance from an input to an output.

8

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

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

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

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

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

g(i, j) =

{i+ 1 i ≥ jj + 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

2Subtraction returns minuend’s bit size because of arithmetic block limits to only positive integer

numbers.3For a detailed description refer to the section 3.3.

13

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

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

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 ≤ la 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

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,1tk,0s0,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

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 Schropfer has

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.

4Detailed explanation of the circuit will be published in WP2 deliverable for Secure SCM project.

18

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.

Each element gs inside this array is a gate composed of multiple inputs wgsi

and one output wgso , where i 6= 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

inputs wgs0 and wgs1 ) and the last wire (wgs2 ) is an output wire. In this thesis

work, each gate is a two input gate5.

5The security of the Yao protocol is still not prove for more than two inputs per gate.

19

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 tgsh from a gate gs depends on the binary representation of the

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 tgs01 = 0. Thus, there

is an obvious link between gate input size and truth table size, while output

values tgsh have to be inserted respect to required gate.

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

output is an array of the output wires for specific gates wgso .

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.

6JSON is a light weight markup language suitable for data representation in the JavaScript

scripting language.

20

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 6= 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

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 6= 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

7Discussed as a future development in chapter 6.

22

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 tgoh = 1 independently

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

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

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

8Refer to figure 3.2 for detailed explanation of the tree.arithmetic package.

25

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

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 Schropfer has

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.

9Abbreviation of the JELS stands for Joint Economic Lot Size explained later in chapter 5.

27

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

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

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

1Confidentiality ensure privacy, it prevents unauthorized represent of the secret data.2Integrity ensures correctness, the original data cannot be changed or substituted.

30

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

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.

3Push 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.4Pull 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

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

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

5RFC 2616, ”Hypertext Transfer Protocol – HTTP/1.1,” does not specify any requirement for

URL length.

34

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.

6One parameter rule is present for subproject simplicity.

35

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

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 6= j, firstly he should send a ”request to

37

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 6= 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

7Oblivious Transfer(OT) is a cryptography technique described later in chapter 4.2.2

38

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

In order to determine who is richer they should evaluate a following protocol

f(i, j) =

{1 i ≥ j0 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 6= 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.

8In 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

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

9In cryptography, a block cipher is a symmetric key cipher operating on fixed-length groups of

bits, called blocks.10Internal state means the internal hash sum after each compression of a data block.11The 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

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] OTnk protocol of will be presented. Required protocol’s

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

12Rabin’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 OT13Yao original construction is described in [29].14One out of two oblivious transfer scheme, also denoted OT2

1

42

polynomial f ′(x) = b0 + b1x + . . . + bk−1xk−1 + xk, such that f ′(x) = 0 if

x ∈ σ1 . . . σk. Additionally, they choose a polynomial f(x) = a0 + a1x+ . . .+

ak−1xk−1 + xk, where ai being uniformly random in Zq, to mask f ′(x) by

Ai = gaihbi .

2. P1 receives kAis from P2 and computes

Bi = gf(i)hf′(i) = A0A

i1 . . . A

ik−1

k−1 (gh)ik

mod p

where Bi is used as a public key to encrypt each message mi, ci = (gki ,miBkii )

and ki is sampled uniformly randomly from Z∗q .

3. P1 sends the ncis to P2. Since Bi = gf(i)hf′(i) = gf(i)h0 = gf(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.

15Let ci = (Ui, Vi), then mσi =Vσi

Uf(σi)σi

16Furthermore, such a protocol can be extended to choosing among more than two options.

43

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

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

17A 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.18A inclined reader is refereed to [17] for description of cipherRandom value.

45

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 t0i and t1i are generated to mask wire value

0 and 1, respectively. The wire keys are only known to Bob. Alice, who will

19A rigorous security proof is presented by Lindell and Pinkas [13].20Or the presence of active adversaries by Goldreich [11]

46

Figure 4.3: Steps to create the Permuted Encrypted Garbled Truth Table

be evaluating EC, can not distinguish between w0i and w1

i , 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 wσo = g(wκi1 , wθi2

)

where σ, κ, θ ∈ 0, 1, the truth table (TT) of g needs further processing. For

each entry (wκi1 , wθi2

) the corresponding output value wσo is encrypted using wκi1and wσi2 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 6= η 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

constructing tampered circuits is reduced to 1m .

2. Alice obtains EiA(xA) from Bob, without revealing xA. A OT 21 protocol is

employed |xA| times, in order to provide Alice with the appropriate wire keys

wσii for xA[i] = σi, without disclosing wσii .

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

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

g′1, . . . , g′n (with references to the input gates or wires).

21In 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.22Note that wires i and j could be input into multiple gates.

48

4. Bob sends ~g′, the keys for his garbled inputs and the random (garble) bits for

all output wires to Alice.

5. Bob prepares Alice’s garbled input bits k0wA

and k1wA

.

6. Alice obtains via oblivious transfer all encrypted kxAwA .

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:

23Output 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

• 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

24Same as in host/guest constructors in Oblivious Transfer library from section 4.2.2.

50

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

25A inclined reader is refereed to [17] for description of cipherRandom value.

51

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

• 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

• 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

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 state26The URL value shall be direct link to the ServletME, as described through example in section

4.1.1.

55

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

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

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 TRCA(qA) are given by

TRCA(qA) =d · fAqA

+qA2· hA

58

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,

the average inventory per period is qA2 (see figure 5.1). The buyer’s economic order

quantity (EOQ), denoted by q∗A, can then be expressed as

q∗A =

√2 · d · fAhA

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 TRCB(qB) are

TRCB(qB) =d · fBqB

+d · qB

2· hBc

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 q∗B, can be expressed as

q∗B =

√2 · c · fBhB

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

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 q∗A and q∗B. In this work it is

assumed that the buyer places orders of size q∗A and that the supplier has no means

to influence the buyer’s decision. In this case qB = q∗A, resulting in total joint costs

of

JTRC(q∗A) = TRCB(q∗A) + TRCA(q∗A)

Based on these results it is easy to explain the underlying rationale of the JELS

model: for any setting in which q∗A 6= q∗B there will be a ”Joint Economic Lot

Size” (JELS) that leads to minimal joint costs of the buyer and supplier such that

JTRC(q∗J) < JTRC(q∗A). The JELS, denoted by q∗J , can be expressed as:

q∗J =

√2 · d · (fA + fB)

d · hBc + hA

The figure 5.2 depicts the supply chain’s costs versus lot size. Obviously, q∗J lies

between q∗A and q∗B.

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

Figure 5.3: JELS circuit

can be implemented. Thus, in the following text first propose the relevant JELS

circuits for computing q∗J . 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 q∗J based on

Yao’s protocol we thus need to construct the corresponding boolean circuit BCDL

object for q∗J . 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 q∗J2 instead of q∗J . This significantly

reduce the number of necessary gates, i.e. root computation is saved in the circuit

for q∗J2. Instead, q∗J

2 can be used locally and non-securely to compute q∗J without

any loss of privacy, since both values can be transformed into their counterpart by

a simple arithmetic operation.

A q∗J2 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 q∗J2. 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

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:

1Secure Business Computation Language is described in section 3.1.22In-memory formula is described in section 3.1.

62

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

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

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

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

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

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

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 Schropfer [24]. It already supports evaluation

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.

1Proposed division block by Kerschbaum and Schropfer has significantly reduced the size [19].2On 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

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

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

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-Wurttemberg Cooperative State University,

2009.

72

[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. Schropfer. On the computation of secure

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

[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. Schropfer, F. Kerschbaum, D. Biswas, S. Geißinger, and C. Schutz. L1 - faster

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