Distributed RSA Key Generation - SourceForgedistrib-rsa.sourceforge.net/dipl_lippold.pdf · Boneh...

Universitat BremenFaculty of Mathematics and Computer Science

Distributed RSA Key Generation

An Implementation for the Two-Party Scenario

Diploma Thesis

by

Georg Lippold

August 19th, 2006

Prof. Dr. Michael Hortmann

Prof. Dr. Hans-Jorg Kreowski

2

Abstract

Standard digital certificates bear only one signature. This is a single pointof failure, since this signature is usually generated by one person on onecomputer. If the secret key in the signature generator is compromised, thecomplete chain of trust for all certificate holders is broken. A very commonasymmetric cipher used for certificates is RSA, as described in Kalinski andStaddon [KS98].

To avoid a compromise of the signature generator, secret keys used insensitive environments like trust centers are usually distributed between dif-ferent entities. This is most easily done by a trusted dealer generates keyshares. But this is only a shift of the problem: If the dealer is compromised,so is the trust in the key.

Boneh and Franklin [BF97] developed distributed RSA key generation fork parties using the protocol described in Ben-Or et al. [BOGW88]. The re-sulting shared RSA key is bk−1

2c private. Later, Gilboa [Gil99] introduced two

party distributed RSA key generation that is k − 1 private. In 2003, Straub[Str03] partially improved Gilboa’s protocol by generating multi-prime RSAkeys for two parties.

In this thesis, we implement Gilboa’s protocol, which uses parts of theoriginal protocol developed by Boneh and Franklin.

For this, an implementation of the Benaloh cryptosystem [Ben94] and theGoldwasser-Micali cryptosystem [GM] had to be done, since there are (tomy knowledge) no public implementations available. Furthermore, ObliviousTransfers as described in Even et al. [EGL85] were implemented. They areused to compute the private exponent of the RSA key from the generatedshares of the RSA modulus.

3

4

Contents

1 Introduction 7

2 Mathematical Preliminaries and Tools 92.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Fast Exponentiation . . . . . . . . . . . . . . . . . . . . . . . 102.3 Euclidean Algorithm . . . . . . . . . . . . . . . . . . . . . . . 102.4 Extended Euclidean Algorithm . . . . . . . . . . . . . . . . . 112.5 Chinese Remainder Theorem . . . . . . . . . . . . . . . . . . . 122.6 Fermat Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Legendre Symbol . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Jacobi Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.9 Twisted Group of ZN . . . . . . . . . . . . . . . . . . . . . . . 15

3 Cryptosystems 173.1 RSA Cryptosystem . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Goldwasser-Micali Cryptosystem . . . . . . . . . . . . . . . . 20

3.2.1 General Description . . . . . . . . . . . . . . . . . . . . 203.2.2 System Setup . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Benaloh Cryptosystem . . . . . . . . . . . . . . . . . . . . . . 223.3.1 General Description . . . . . . . . . . . . . . . . . . . . 223.3.2 System Setup . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Naccache-Stern Cryptosystem . . . . . . . . . . . . . . . . . . 253.4.1 General Description . . . . . . . . . . . . . . . . . . . . 253.4.2 System Setup . . . . . . . . . . . . . . . . . . . . . . . 25

4 Constructing a Shared RSA Key 294.1 Preliminary Remarks . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Implementation Details . . . . . . . . . . . . . . . . . . 304.2 Gilboa’s Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Program Design . . . . . . . . . . . . . . . . . . . . . . 33

5

6 CONTENTS

4.2.3 Generation of N . . . . . . . . . . . . . . . . . . . . . . 344.2.4 Primality Test . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Oblivious Transfers . . . . . . . . . . . . . . . . . . . . . . . . 404.3.1 Converting Shared Secrets . . . . . . . . . . . . . . . . 41

4.4 Computing the Public and the Private Exponent . . . . . . . 43

5 Results 495.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Usability with Existing RSA Software . . . . . . . . . . . . . . 51

6 Summary 536.1 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Bibliography 57

A Appendix: Source Code 61A.1 Mathematical Tools . . . . . . . . . . . . . . . . . . . . . . . . 61A.2 Cryptosystems . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Chapter 1

Introduction

The motivation for the development of techniques for distributed RSA keygeneration is clear: In sensible areas concerned with computer security, thereis a need to impose a multi-eye principle. The RSA cryptosystem was devel-oped by Ron Rivest, Adi Shamir, and Len Adleman and bears their initialsas an identifier. It is a widely adopted standard (see Kalinski and Staddon[KS98]) that is used by many programs. Usually, RSA keys for sensitive en-vironments are built by a trusted dealer who generates a standard RSA keyand then splits it into multiple parts.

The problem with a trusted dealer is that there is again a single point offailure: If the dealer is compromised, so is the key. So there arises a need tosecurely compute a shared RSA key such that neither party ever has the fullkey or is able to reconstruct the full key from the communication protocol.

Starting with Boneh and Franklin [BF97] in 1997, there was a develop-ment of techniques to jointly generate shared RSA secret keys. Boneh andFranklin developed a scheme that allowed k ≥ 3 parties to jointly gener-ate a key for that any coalition of at most bk−1

2c parties cannot recover the

complete key. They used the BGW protocol (see Ben-Or et al. [BOGW88])to compute the sharing. For the Boneh-Franklin protocol an open sourceimplementation is available from the ITTC website (see [Bon99]).

There exist a few papers about two-party RSA key generation but untiltoday no open source software for the two party scenario is available. To ver-ify the claims made by the authors an open implementation is both necessaryand useful.

In the course of this thesis such an implementation is developed. Inchapter 2 on page 9 the mathematical tools needed are proven and an exampleimplementation for the algorithms is given where applicable.

Chapter 3 on page 17 deals with the cryptosystems used in the processof generating a shared RSA key. I explain the underlying principle for each

7

8 CHAPTER 1. INTRODUCTION

cryptosystem, show how the system is set up for two parties and give a sampleimplementation – except for the RSA cryptosystem which has several openimplementations.

Implementation-specific details and the complete process of the genera-tion of a shared RSA key are explained in chapter 4 on page 29. First, ashared RSA modulus N is constructed. A specially designed bi-primality testverifies that the modulus is not composed of more than two primes. Modulithat consist of more than two primes are detected with probability at least12

in each run of the test. The technique of Oblivious Transfers is explainedwhich is in turn used to compute the private exponent d of the RSA key.The chapter finishes with the computation of the private exponent.

The experimentally verified results are presented in chapter 5 on page 49.Here, a performance analysis and a statistical verification of the process isgiven. The outcome is compared to the claims of Gilboa in [Gil99] andevaluated for compatibility with off-the-shelf software.

A short outlook on what could be implemented in further steps of thesoftware is given in chapter 6 on page 53. A classification into the scientificcontext concludes the thesis.

At the end of every entry in the bibliography is a back reference of thepages on which the entry is cited. Furthermore, the bibliography containsreferences that are only available online and are not printed. Thus, they maybe subject to change with time and the status in which I viewed them may notbe recoverable (although the Way Back Machine on http://www.archive.

org may be able to). To prevent this, and to faciliate the recapitulation ofthe current work, all literature used is also on the accompanying CD in thefolder DiplomaThesis/literature.

http://www.archive.org

http://www.archive.org

Chapter 2

Mathematical Preliminariesand Tools

In the course of this thesis, there are some mathematical recipes used thatmay or may not be known to the reader. I give a short introduction into themost commonly used techniques throughout this thesis. Not all functionsdescribed here are implemented in the standard Java API, with which theaccompanying application is programmed. Therefore I give example imple-mentations where applicable.

2.1 Notations

There are some symbols used in the calculations, a short overview of theirmeaning is given in table 2.1.

condition:equation equation holds for condition∏ji Product from index i to index j∑ji Sum from index i to index j

x← N x uniformly at random from N∀ For all∈ Element ofZp The field of x mod p with p prime for all x ∈ N

Table 2.1: Mathematical Symbols

9

10 CHAPTER 2. MATHEMATICAL PRELIMINARIES AND TOOLS

2.2 Fast Exponentiation

Exponentiation is widely used throughout the thesis. The reader may thinkthat exponentiation is a rather expensive operation because it involves manymultiplications. But we can use a shortcut by defining

Power(x, n) =

x if n = 1

Power(x2, n/2) if n mod 2 = 0

x · Power(x2, n− 1/2) if n mod 2 = 1.

For more algorithms on exponentiation, please see Menezes et al. page613 – 618 [MvOV96].

2.3 Euclidean Algorithm

The Euclidean Algorithm (see also Menezes et al. page 66 [MvOV96] andWikipedia [Wik06b]) determines the greatest common divisor of two numbersa and b without the need to factor them. In this thesis it is used as gcd(a, b).

Without loss of generality, if a > b we can write

r0 = q1r1 + r2

with r0 = a and r1 = b. q1 is the quotient of the division of r0 by r1 andr2 is the remainder. Since r2 = r0 − q1r1, any divisor of r0 and r1 is also adivisor of r2:

If there is a common divisor d of r0 and r1, then we have r0 = dx andr1 = dy, thus r2 = dx− q1dy = d(x− q1y). Since r2, r0 and r1 have the samedivisor, we can continue the search with the smaller two of them, r1 and r2.

Eventually, it will be found that rn−1 = qn · rn + 0, now rn is the greatestcommon divisor of r0 = a and r1 = b.

The algorithm is a very nice recursion:

int gcd (a , b){i f (b == 0){

return a ;

}5 return gcd (b , a mod b ) ;

}

The Euclidean Algorithm is implemented in the standard Java class Big-Integer. The method is named gcd().

2.4. EXTENDED EUCLIDEAN ALGORITHM 11

2.4 Extended Euclidean Algorithm

The Extended Euclidean Algorithm is basically the Euclidean Algorithm withbookkeeping. It determines ax+ by = gcd(a, b).

ax+ by = gcd(a, b)mod a⇒ 0 + by = gcd(a, b) ( mod a)mod b⇒ ax+ 0 = gcd(a, b) ( mod b).

Thus, if gcd(a, b) = 1 (a and b are coprime), then y is the multiplicativeinverse of b in Za and x is the multiplicative inverse of a in Zb.

As we have seen in section 2.3 on the facing page, the Euclidean Algorithmis

rk+1 = rk−1 − qkrk. (2.1)

Let us take two additional terms of the same form, namely

sk+1 = sk−1 − qksk

tk+1 = tk−1 − qktk.

With s0 = 0, s1 = 1 and t0 = 1, t1 = 0 we can write

rk = skr0 + tkr1. (2.2)

The following proof shows this by induction over k:

k = 0 : r0 = 1 · r0 + 0 · r1k = 1 : r1 = 0 · r0 + 1 · r1.

(2.3)

Now observe rk+1 for k ≥ 1:

rk+12.1= rk−1 − qkrk

2.2 & 2.3= sk−1r0 + tk−1r1 − qk(skr0 + tkr1)

= (sk−1 − qksk)︸︷︷︸=sk+1

r0 + (tk−1 − qksk)︸︷︷︸=tk+1

r1 = sk+1r0 + tk+1r1.

Since r0 = a and r1 = b and rk = gcd(a, b) we now have an algorithmthat finds x and y as stated above.


2.5 Chinese Remainder Theorem

The Chinese Remainder Theorem (see also Menezes et al. page 68–69 and611–613 [MvOV96] and Wikipedia [Wik06a]) was developed by the mathe-matician Sun Tsu Suan-Ching in the 4th century A.D. It is applied to re-compose an integer x from its residues modulo pairwise coprime integersp1, p2, . . . pn. Pairwise coprime means that for two integers pi, pj, pi 6=pj : gcd(pi, pj) = 1.

Thus, we want to find an x for that

x mod pi = ai. (2.4)

With N =∏n

i=1 pi and gcd(pi,Npi

) = 1 by construction, we can use the

Extended Euclidean Algorithm (see section 2.4 on the page before) to solve

x · pi + y · Npi

= 1. (2.5)

If we take 2.5 modulo pi we get

y · Npi

mod pi = 1

and modulo pj

∀pj 6= pi : y · Npi

mod pj = 0.

Thus, to reconstruct an x that fulfills equation 2.4 we have with ei = y ·Npi

:

x =n∑

i=1

aiei ( mod N).

Other solutions are x+ q ·N for q = 1, 2, . . .The Java code for the Chinese Remainder Theorem is in listing A.1 on

page 61.

2.6 Fermat Test

The Fermat Test is also known as Fermat’s Little Theorem (see also Weisstein[Wei04]). It is based on the observation that for any natural number a andany prime p the following condition holds true:

2.6. FERMAT TEST 13

ap mod p = a mod p

⇒ (ap − a) mod p = 0

This can be proved by induction over a. The anchor is (1p−1) mod p = 0for a = 1. Now consider

(a+ 1)p − (a+ 1).

Using the binomial theorem, (a+ 1)p expands to

(a+ 1)p = ap +

(p1

)ap−1 +

(p2

)ap−2 . . .+

(p

p− 1

)a+ 1

⇒ (a+ 1)p − ap − 1 =

(p1

)ap−1 +

(p2

)ap−2 . . .+

(p

p− 1

)a.

If p is prime, p divides(p1

)ap−1 +

(p2

)ap−2 . . .+

(p

p− 1

)a.

Thus, p also divides

(a+ 1)p − ap − 1

and therefore p also divides

(a+ 1)p − ap − 1 + (ap − a)

since (ap − a) is divisible by p as proved in the anchor. Now we have:

(a+ 1)p − ap − 1 + (ap − a) = (a+ 1)p − (a+ 1)

and thus the induction holds for any a.If p does not divide a, we can divide (ap− a) mod p = 0 by a mod p and

get

ap−1 − 1 mod p = 0.

This provides us with a primality test: If ap−1 mod p = 1 mod p, thenwe have a strong indication that p may be prime. If this test is done fordifferent a’s it is an even stronger indication that p may be prime. It isnot a complete primality test, since there are Carmichael Numbers for which


this test is always true. These numbers are of the form N = p1 · p2 · p3 =(6k + 1)(12k + 1)(18k + 1) = 1296k3 + 396k2 + 36k + 1, if p1 = 6k + 1 andp2 = 12k + 1 and p3 = 18k + 1 are prime. Thus, N − 1 is a multiple of 36kwhich is also the least common multiple of p1−1, p2−1 and p3−1. Since p1, p2

and p3 are prime, the equation apx−1 mod px = 1 mod px holds for each ofthem. Hence, since N is the product of the three primes, aN−1 mod N = 1.For further details about Carmichael Numbers, see also Weisstein [Wei05].

2.7 Legendre Symbol

With the Fermat Test (see 2.6 on page 12), we can now test any a in Zp

with p prime, as to whether it fulfills the condition that r2 = a. If such an rexists, it is said that a has “a quadratic residue modulo p”.

We define the Legendre Symbol as(

ap

)for any integer a and any prime

p. The Legendre Symbol has the following properties:

(a

p

)=

0 if p divides a

1 if a is a quadratic residue modulo p

−1 if a is not a quadratic residue modulo p.

The Fermat Test showed that for any prime p and any integer a

ap−1 mod p = 1 mod p.

For a = r2, we have

ap−12 mod p = (r2)

p−12 mod p = rp−1 mod p = 1 mod p.

Thus we can easily test for quadratic residues modulo p by computinga

p−12 .The Java source code for determining the Legendre Symbol is in list-

ing A.2 on page 61.

2.8 Jacobi Symbol

The Jacobi Symbol is a generalization of the Legendre Symbol. For anypositive odd integer q, the Jacobi Symbol is defined as

J(a, q) =

(a

q

)=

(a

p1

)b1

·(a

p2

)b2

· . . . ·(a

pn

)bm

2.9. TWISTED GROUP OF ZN 15

where q = pb11 · pb2

2 · . . . · pbmn is the prime factorization of q and

(apx

)is the

Legendre Symbol for prime px.

There are some shortcuts for the computation of(

aq

)(taken from page

4 in Froschler [Fl05]):

• If a = 0 return 0.

• If a = 1 return 1.

• If a > q return J(a mod q, q).

• If a mod 4 = 0 return J(a mod 4, q).

• If a mod 2 = 0 and (q mod 8 = 1 or q mod 8 = 7) return J(a/2, q).

• If a mod 2 = 0 and (q mod 8 = 3 or q mod 8 = 5) return −J(a/2, q).

• If a mod 4 = 1 or q mod 4 = 1 return J(q mod a, a).

• If a mod 4 = 3 or q mod 4 = 3 return −J(q mod a, a).

The Java source code to compute the Jacobi Symbol is in listing A.3 onpage 62.

2.9 Twisted Group of ZN

In the ring ZN [x](x2+1)

with N ≡ 3 mod 4, all elements are of the form ax + bwhere a and b are Elements of ZN . If we multiply two elements, we get aterm that contains x2. Since x2 + 1 shall always be zero, we set x2 = −1.This lets us calculate with the elements of ZN [x]

(x2+1)analogously to the complex

numbers if we simply eliminate x from ax+ b by using

(a, b) + (c, d) = ((a+ c), (b+ d))

(a, b) · (c, d) = ((ac− bd), (ad+ bc))

and reducing modulo ZN .ZN itself is then a sub ring of ZN [x]

(x2+1). This can be seen by setting (e, 0) for

any e ∈ ZN . All these elements behave in analogously to the native elementsof ZN .

The “Twisted Group” (the name is adopted from Straub [Str03, page

2]) of ZN now is the Group TN = ZN [x]x2+1

/ZN . In ZN [x]/(x2 + 1), we have(a, b)(a,−b) = (a2 + b2, 0). Thus, in TN , the multiplicative inverse of (a, b)is (a,−b) and all elements (a, 0) with a ∈ ZN are remapped to (1, 0).


Chapter 3

Cryptosystems

It is common knowledge that there are two kinds of encryption: The first arethe symmetric ciphers that encrypt a given plaintext into a ciphertext usinga key that is known to both parties. The same key is used for decryption byapplying it to the ciphertext.

Then, there are asymmetric ciphers that consist of a public key and pri-vate key. Both keys are constructed such that they do mathematically inverseoperations. In this thesis, only asymmetric ciphers are used.

For asymmetric ciphers, one can further differentiate between determin-istic and probabilistic encryption.

Deterministic asymmetric encryption encrypts the same plaintext alwaysto the same ciphertext.

Probabilistic encryption, also known as homomorphic encryption, hascharacteristics that are very useful for generating shared secrets:

• There are multiple encodings for the same message using the same keypair and algorithm. Thus, it is much harder to do chosen plaintextattacks.

• It is possible to apply arithmetical operations like addition, subtractionand multiplication to encrypted messages without the need to decipherthem.

• Upon encryption, the user gains a certificate with which he can provethat he encrypted the message. This certificate is not recoverable upondecryption.

A drawback is that homomorphic encryption has a very high expansionrate when converting plaintext into ciphertext.

17

18 CHAPTER 3. CRYPTOSYSTEMS

All operations in homomorphic encryption schemes are modulo N = p · qand usually there is a maximum plaintext message size that can be encryptedin a single step. Throughout this thesis the message limit is called r and onlymessages smaller than r can be encrypted. Thus, addition and multiplicationworks only for small messages that can be encrypted in one step. Operationscan be applied to larger messages by splitting the message into smaller partsso that the operation is transparently carried on. Then the operation isapplied to each part and the result is reconstructed from the modified parts.In this thesis, the Chinese Remainder Theorem is used to this end.

Addition of encrypted messages is achieved by multiplying the messages:

c((m1 +m2) mod r) = c(m1) · c(m2) mod N.

Multiplication is done via exponentiation, here the exponent has to be inplaintext

c((m1 ·m2) mod r) = c(m1)m2 mod N.

In the course of this thesis, multiple encryptions schemes are used toexchange messages between the two parties. Here is a short overview:

The first asymmetric cipher I would like to mention is the RSA cipher.It is widely used during the Oblivious Transfers (see 4.3 on page 40) and thegeneration of a shared RSA key pair is also the goal of this thesis.

In order to use the protocol described by Gilboa in [Gil99], the Goldwasser-Micali cryptosystem as first published by in [GM] as well as the Benaloh cryp-tosystem that was published in [Ben94] had to be implemented. Additionally,the Naccache-Stern cryptosystem as explained in [NS98] was implemented forlater optimizations.

In this chapter the similarities and differences between these systems willbe examined and a short explanation on the cryptographic mechanisms usedtherein will be given. In appendix A.2 on page 64 implementation detailsfor the systems are available. For a complete implementation please see theaccompanying source distribution.

In the folder

DistribRSA/src/de/uni bremen/informatik/lippold/cryptosystems

you will find the sources for the mentioned classes.

3.1. RSA CRYPTOSYSTEM 19

3.1 RSA Cryptosystem

The RSA cryptosystem is named after its developers Ron Rivest, Adi Shamir,and Len Adleman. It is based on the hardness of factoring the product oftwo large primes N = p · q with p 6= q. The RSA cryptosystem is probablythe most widely used deterministic asymmetric cipher today.

In a group G with order |G|, for every element a ∈ G there is a orderk = ord(a) so that ak = 1. It is obvious that k divides |G| since |G| must bethe least common multiple of all ki. Thus we can write ord(G) = ord(a) · q.

We now have

aord(G) = aord(a)·q = (aord(a)︸︷︷︸=1

)q = 1q = 1.

We are now interested in the order of ZN , |ZN | (see also Wikipedia[Wik06d] and Wikipedia [Wik06c]). Since N = p · q, we must remove allmultiples of p and q from ZN to get the order of ZN . For p we have theelements

0 · p, p, 2p, . . . , (q − 1)p

which are q elements, and for q we get likewise p elements that have tobe removed. Thus the order of ZN is N︸︷︷︸

=pq

−p− q + 1 = (p− 1)(q − 1) since

0 was counted twice. And thus in ZN we have ∀x ∈ ZN : x(p−1)(q−1) = 1 andtherefore x(p−1)(q−1)+1 = x(p−1)(q−1) · x = x.

This leads us to a cryptosystem:

• Let ϕ(N) = (p − 1)(q − 1). Choose an e that fulfills gcd(e, ϕ(N)) = 1(a widely used but potentially unsafe e is 216 + 1, for details pleasesee Fouque et al. [FKJM+06]). Compute d so that de = 1 mod ϕ(N).From the Extended Euclidean Algorithm (see section 2.4 on page 11)we know that we can find d and b such that

bϕ(N) + de = gcd(ϕ(N), e) = 1.

Taking this modulo ϕ(N), we get 0 + de ≡ 1 ( mod ϕ(N)) and thusde− 1 ≡ ϕ(N).

• Now we can encrypt an x ∈ ZN : Let y = xe be the encryption. Todecrypt, we simply compute yd = (xe)d = xed = x(de−1)+1 = xbϕ(N)+1 =(xbϕ(N))x = 1 · x = x.


Thus, we have an elegant cryptosystem: Encryption is done by com-puting y = xe and decryption by yd = x. If one publishes e and N andkeeps d secret, everybody can encrypt but only the person knowing d(which could be reconstructed from p and q) can decrypt. Thus, wehave established an asymmetric cipher system.

3.2 Goldwasser-Micali Cryptosystem

3.2.1 General Description

A description of the Goldwasser-Micali cryptosystem is given in [GM]. Thesecurity is based on two assumptions:

• It is not feasible to factor the product of two large primes N = p · q.This problem is known as integer factoring.

• If the Jacobi symbol for a given integer x < N is J(x,N) = 1, it is notdecidable whether x is of the form x = a · a so that J(x, p) = J(x, q) =1 ⇒ J(x,N) = 1 or of the form J(x, p) = −1 and J(x, q) = −1, soJ(x,N) = J(x, p) · J(x, q) = 1.

This problem is known as quadratic residue problem.

In Zp, there are p−12

quadratic residues, excluding zero. They stem from

the numbers 12, 22, . . . , (p−1)2

2. Evidently, there are also p−1

2quadratic non-

residues. In ZN with N = p · q, p prime, q prime and p 6= q, there areN − (p − 1) · (q − 1) divisors of zero. The elements with J(x,N) = 1 stem

from the p−12· q−1

2= (p−1)(q−1)

4quadratic residues in p and q with J(x, p) =

J(x, q) = 1 and the p−12· q−1

2= (p−1)(q−1)

4quadratic non-residues in p and q

with J(x, p) = −1 and J(x, q) = −1.

Thus we have (p−1)(q−1)2

elements with J(x,N) = 1. Analogously, we getp−12· q−1

2elements with J(p, x) = 1 and J(q, x) = −1 and again (p−1)(q−1)

4

elements with J(q, x) = 1 and J(p, x) = −1. Thus, we also have (p−1)·(q−1)2

elements x with J(x,N) = −1.Therefore, given that J(x,N) = 1, one cannot decide whether x is a

quadratic residue or not if one cannot factor N .Given the factorization of N , one can simply test if an integer x with

Jacobi symbol 1 is a quadratic residue: If J(x, p) = 1 and J(x, q) = 1, thenx is a quadratic residue.

Now, if there were a means to compute the root of a given square in N,the factorization problem would be solved:

3.2. GOLDWASSER-MICALI CRYPTOSYSTEM 21

Goldwasser-Micali cryptosystemPrivate key parameters

p primeq prime

Public key parametersN N = p · qy {y ∈ N | J(y,N) = 1 ∧

J(y, p) = J(y, q) = −1}

Plaintext m ∈ {0, 1} (1 bit)Ciphertext c(m) ∈ ZN

Random element u← ZN

Encryption u← ZN : u2 · ym mod NDecryption J(c(m), p) ∧ J(c(m), q) ≡ −1Expansion rate 1→ N

Table 3.1: Goldwasser-Micali parameters

Any element x ∈ ZN is composed of the two remainders modulo p andq. Thus, x can be written as xp · xq = xZN

. For any square x2 ∈ ZN , thereobviously exist the roots −xp · −xq,−xp · xq, xp · −xq and xp · xq (becausesquared all these integers lead to x2

px2q). If we could compute the root of

a given x2, the algorithm would either give all four possible roots, or withprobability 1

2a root that is not x and not −x, let us call it r.

In ZN , we have 0 = x2−r2 = (x+r)(x−r). Thus, N divides (x+r)(x−r).Now we can easily factor N , since gcd(x + r,N) and likewise gcd(x − r,N)gives a factor of N .

Thus, solving the quadratic residue problem is as hard as factoring N .A summary of the Goldwasser-Micali system is in table 3.1.

3.2.2 System Setup

Key generation

For a cryptosystem with strength k bit, Alice chooses two primes p and q,each of size k

2bit. She sets N = p · q. She then finds an integer y for which

J(y,N) = 1 but J(y, p) = J(y, q) = −1. and then publishes y and N butkeeps p and q secret. The Java code for the key generation is in listing A.4 onpage 64.


Encryption

Bob, who wants to send a message m which is represented as a bit string oflength n, encrypts each bit m[i] in the following way and sends it to Alice:

Bob chooses a random integer u ∈ ZN . He then computes u2·ym[i] mod N .Clearly, if m[i] = 0, then J(c(m), N) = J(u2, N) = 1. On the other hand,if m[i] = 1, then J(c(m), N) = J(u2 · y,N) = J(u2, N) · J(y,N) = 1. Thus,all messages that Bob sends to Alice have the same Jacobi symbol, and thecontent cannot be determined without knowing the factorization of N . TheJava code for Bob is in listing A.5 on page 64.

Decryption

Alice now decrypts the message:If c(m) is a quadratic residue modulo p and also a quadratic residue

modulo q, then Bob’s bit was 0, else it was 1. The Java code for Alice is inlisting A.6 on page 65.

3.3 Benaloh Cryptosystem


Benaloh explains his cryptosystem in [Ben94]. The security of this cryptosys-tem is based on two problems which are cryptographically hard:

1. The “higher residuosity” or “discrete logarithm” problem: “Given z, rand n of unknown factorization, there is no known polynomial timealgorithm to determine whether or not there exists an x such thatz = xr mod n.” (from Benaloh in [Ben94])

The inverse operation, the exponentiation, is feasible as shown in sec-tion 2.2 on page 10.

The same problem is also used in the Naccache-Stern cipher (see sec-tion 3.4 on page 25) and the popular Diffie-Hellman [Res99] cryptosys-tem.

2. The problem of factoring the product of two large primes.

The system consists of a modulus N = p · q with p, q prime and p 6= q, apublic base for exponentiation y, and the upper limit for exponents r whichis an odd integer chosen before system setup. In this system, the message isstored in the exponent. Then, p, q and y are generated as follows:

3.3. BENALOH CRYPTOSYSTEM 23

• r divides p− 1 and gcd(r, p−1r

) = 1

• gcd(r, q − 1) = 1

• N = p · q, thus r divides ϕ(N) = (p− 1)(q − 1) exactly once.

• gcd(y,N) = 1 and y(p−1)(q−1)

r mod N 6= 1

A message m < r is encrypted as c(m) = ym · ur mod N , where u isa random element in ZN . It is easy to compute the plaintext m, givenϕ(N) = (p− 1)(q − 1):∀x ∈ ZN : x(p−1)(q−1)+1 = x and x ∈ ZN : x(p−1)(q−1) = 1 as we have

seen in section 3.1 on page 19. Now we can compute m from c(m) (allcomputations modulo N):

c(m)(p−1)(q−1)

r = (ym · ur)(p−1)(q−1)

r = ym(p−1)(q−1)

r · ur(p−1)(q−1)

r︸︷︷︸=1

= ym(p−1)(q−1)

r .

Since we chose y in such a way that y(p−1)(q−1)

r 6= 1, there exists a canonical

value ym· (p−1)(q−1)r for every possible message m < r. If we pre-compute this

value for all possible messages {0, 1, . . . , r − 1}, we can then simply look itup in a table and retrieve the original message.

A short overview of the Benaloh system is in table 3.2 on the followingpage.

3.3.2 System Setup

Key Generation

Before generating her primes p and q, Alice has to decide two parametersinfluencing the key generation:

• An odd integer r > 2 that determines the maximum message size forher Benaloh system and

• the bit length of N .

Then, she generates p.Since p has to fulfill the requirement that r divides p − 1, and p−1

rand

p shall be coprime, it is wise to choose a prime p′ that has N/2 − r − x bitas a starting point, where x is a chosen value. Naccache and Stern [NS98]recommend that x has 24 bits. This is useful since it takes some time togenerate large primes with sufficient certainty.


Benaloh cryptosystemPrivate key parameters

p prime, r | (p− 1) ∧ gcd(r, p−1r

) = 1q prime, gcd(r, q − 1) = 1

Public key parametersN N = p · qy {y ∈ N | gcd(y,N) = 1 ∧

y(p−1)(q−1)

r mod N 6= 1}r The maximum message size

Plaintext m ∈ {0, 1, . . . , r − 1}Ciphertext c(m) ∈ ZN


Encryption u← ZN : ur · ym mod N

Decryption c(m)(p−1)(q−1)

r mod N and table lookupExpansion rate r → N

Table 3.2: Benaloh parameters

Once p′ is determined, Alice can generate a prime p with the desiredproperties by calculating p = 2 · r · p′ ·x+ 1 with x being a 24 bit prime. Shethen tests whether p is prime and if not, she just chooses a new x (which ismuch smaller than p′) until she finds a suitable prime that fulfills all criteria.This search is very fast compared to the brute force search.

Since q and y are generated according to the specification, there is notmuch to optimize if r is prime.

The Java code for the key generation is in listing A.7 on page 65.

Encryption

Encryption works like in the Goldwasser-Michali system with the only dif-ference being the message size.

The code for Benaloh encryption is in listing A.5 on page 64.

Decryption

For decryption, Alice computes c(m)(p−1)(q−1)

r mod N as described above. Shethen deciphers the message by looking up the correct value for m in theprecomputed table.

3.4. NACCACHE-STERN CRYPTOSYSTEM 25

The Java code for decryption is in listing A.8 on page 67.

3.4 Naccache-Stern Cryptosystem


The Naccache-Stern cryptosystem is an optimization of the Benaloh cryp-tosystem (see section 3.3 on page 22). It is described by Naccache and Sternin [NS98] and is based on the same cryptographic assumptions which lie atthe base of the Benaloh system.

For system setup a list P of small pairwise coprime odd integers (i.e.∀pi, pj ∈ P, pi 6= pj : gcd(pi, pj) = 1) is generated. This list has usually (butnot necessarily) an even number of entries k and is split into two halves, u

and v, where u =∏k/2

i=1 pi and v =∏k

i=k/2+1 pi. Two “large” primes a and bare generated in such a way that p = 2au+ 1 and q = 2bv+ 1 are prime andhave the desired bit length to compose N .

For N = p · q a base y is generated, such that ∀pi ∈ P : y(p−1)(q−1)

pi 6= 1(analogously to the Benaloh cryptosystem in section 3.3 on page 22). Nat-urally, encryption is likewise performed by encrypting a message m <

∏pi

as c(m) = ym mod N . Optionally, the encrypted value can be obfuscatedby setting c(m) = ym · u

Qpi mod N with u ∈ ZN uniformly at random.

However, this is not necessary here since the message space is much largercompared to the Benaloh cryptosystem (usually > 160 bit), so it cannot besearched.

Decryption works analogously to the Benaloh system, with the differencethat here many Benaloh systems are used at once: For each pi ∈ P , the value

of mpi= c(m)

(p−1)(q−1)pi is computed and the cleartext value is looked up in

the table of pi. By means of the Chinese Remainder Theorem (see 2.5 onpage 12) the original value of m can be restored: Clearly, m is CRT (mi, pi).Thus, the message m is decrypted.

A quick reference sheet for the Naccache-Stern cryptosystem is in ta-ble 3.3 on the next page

3.4.2 System Setup

Key Generation

Naccache-Stern key generation can be optimized by using threads, sincep and q can be generated independently from each other. After p and qare generated, y can be generated modularly for every prime pi by finding


Naccache-Stern cryptosystemPrivate key parameters

u, v list of coprime integersa, b “large” primesp prime, p = 2au+ 1q prime, q = 2bv + 1

Public key parametersN N = p · qy {y ∈ N | ord(y,N) ≥ 4 ∧

∀pi ∈ u, v : y(p−1)(q−1)

pi mod N 6= 1}σ = u · v The maximum message size

Plaintext m ∈ {0, 1, . . . , σ − 1}Ciphertext c(m) ∈ ZN


Encryption u← ZN : uσ · ym mod N

Decryption c(m)(p−1)(q−1)

pi mod N ,table lookup and CRT

Expansion rate σ → N (≈ 1:4)

Table 3.3: Naccache-Stern parameters

3.4. NACCACHE-STERN CRYPTOSYSTEM 27

yi : y(p−1)(q−1)

pii 6= 1. Now, the product

∏ki=1 yi mod N = y has the desired

property with very high probability. In my implementation, the key gen-eration process is fully threaded and makes use of all available processors.During key generation, finding p and q is optimized by using 24 bit tuningprimes, as suggested in Naccache and Stern [NS98].

The Java code for the Naccache-Stern key generation is in listing A.9 onpage 67.

Encryption

Encryption is similar to the encryption process in Benaloh, but here therandom value u is not compulsory since the message space has already ≈ 160bit.

The encryption is in listing A.10 on page 68.

Decryption

Since decryption can be done independently for every single prime, it canbe threaded. This is done in my implementation: For each small prime aDecryptBySmallPrime thread is started which submits the decryption valueto the originating thread. Since I can start multiple threads at once, thetime needed for decryption decreases linearly by the amount of availableprocessors.

The decryption process is in listing A.11 on page 69.


Chapter 4

Constructing a Shared RSAKey

4.1 Preliminary Remarks

The two party RSA key generation is implemented as a classical client-serversystem where the server either has a list containing authorized clients or asksits administrator for the information with every connecting client. The pro-tocol is designed in such a way that both parties are assumed to be honestlyfollowing the protocol but curiously interpreting every message sent. Theycannot learn the secrets of the other party by analyzing the messages. In thissetting, mutual authentication is useful because the generated key cannot beused without the other party. Thus keys are usually generated only withreliable parties. To this end, mutually authenticated SSL connections areused for communication, where all messages are signed and encrypted auto-matically. Furthermore, the certificates used to establish the SSL connectionare used to identify the parties. The encryption of the SSL connection is notnecessary for the security of the protocol.

There are mainly two reasons why the software is not implemented in apeer to peer setting:

1. Peer to peer computing is useful when a large group of people wantsto do something together. Since this implementation is tailored to thetwo party scenario, it is more efficient if one person is the client andthe other is the server.

2. When using true peer to peer technology with automatic peer discovery(without fixed rendezvous servers), one cannot guarantee that bothparties actually find each other. Peer to peer networks tend to form

29

30 CHAPTER 4. CONSTRUCTING A SHARED RSA KEY

clusters of computers that are strongly interconnected and have veryfew if any connections to other clusters. Thus, the two parties wantingto generate a shared RSA key may not be able to find each other inthe peer to peer network.

Moreover, as peer to peer networks usually add some kind of abstractionlayer over the actual network, it may also not be easy to reconstructIP addresses from P2P addresses for direct communication.

By using a classical client-server solution, these two problems are over-come.

Before using the protocols explained below, the parties have to agree onthe bit length k of the generated RSA key, as well as on the protocol used,and have to set up the needed cryptosystems.

4.1.1 Implementation Details

Certificates for Authentication

When the application starts, the user is asked whether he wants to create anew certificate and private key on the fly or import both from his PKCS#12keystore (as defined in RSA Laboratories [RSA93a]). With this certificateand private key the application has authentication credentials that are cryp-tographically strong and are later used to authentify against the other party.Certificates from other parties can also be stored in the keystore after suc-cessful authentication. Thus, if two parties exchange their certificates once,the identity of the other party needs no confirmation in successive runs ofthe application.

Persistent Settings

In my implementation, it is possible to store all settings in a configuration filethat can be supplied to the application on startup. If a valid configuration fileis presented, the application tries to generate a shared RSA key without userinteraction. Thus, scenarios for larger organizations where multiple sharedRSA keys are needed or keys must be generated automatically are possible.

Size of the Generated RSA Key

The size of the generated RSA key is the smaller of the preferences of clientand server, because the homomorphic encryption systems for generating theshared key are set up before the generation. If the larger size was chosen,the homomorphic systems would also need to be stronger. In the process of

4.1. PRELIMINARY REMARKS 31

generating a shared RSA key the cryptosystems used are always as hard orharder than the generated key. Therefore, the encryption added by the SSLprotocol is irrelevant.

Agreement on a Random Element

During the protocol the parties have to agree on a random element of a ring.These agreements are necessary in two crucial steps of the protocol: theelement used for the primality test and the element used as public exponentof the shared RSA key.

Thus the security of the resulting RSA key highly depends on the inabilityof any party to influence the agreement. Neither Boneh and Franklin [BF97]nor Gilboa [Gil99] publish a protocol to reach a secure agreement, so I willgive a short example of such a protocol:

• Each party chooses a random element of the ring. It then computes thehash value of the element with a cryptographically strong hash algo-rithm and publishes the hash value. After both parties have publishedthe hash value, their elements are fixed and every party is sure that itselement is truly random.

• The parties publish their elements and add them. The resulting elementis the element agreed upon. Multiplication should not be used in thering because then one party can choose a divisor of zero to get “special”results.

• If a prime number is needed, one party can search for the first primeafter the element agreed upon and publish it. If both parties are con-vinced that the number is prime and indeed the next possible element,then the process of finding a prime number can be significantly reducedin large rings. For elements that have other special properties, the sameprinciple can be used.

Protocol used

Currently, the choice of the protocol depends on the client; the server adoptsas necessary. A configuration option that lists the allowed protocols for theserver is not yet implemented but would be a nice addition. The currentimplementation contains three steps:

1. Preparation of a mutually authenticated channel. To this end, a SSLconnection with verified certificates is created between both parties.


2. Generation of a shared modulus over the authenticated channel. Thecurrent implementation allows for multiple protocols to be used. Ac-tually, only Gilboa’s Protocol as described in Gilboa [Gil99] is fullyimplemented. Work on the protocol designed by Straub [Str03] hasbegun but is not finished yet.

3. Generation of a private and a public exponent matching the sharedmodulus. The protocol used here is Gilboa’s adoption to the two partyscenario of the protocol developed by Boneh and Franklin in [BF97].

4.2 Gilboa’s Protocol

4.2.1 Description

Gilboa’s protocol is inspired by the original work of Boneh and Franklin[BF97] but tailored to the two party scenario by using either Oblivious Trans-fers, Oblivious Polynomial Evaluation or Benaloh cryptosystems. In this the-sis, only Benaloh cryptosystems are used to generate N , since in section 8 ofGilboa [Gil99] it is stated that this is the fastest way to generate N . Afterthe generation of N finished, Oblivious Transfers are used to construct theprivate RSA exponent d for each party.

As Gilboa [Gil99] explains in section 3 of his paper, the protocol is splitinto four steps (although Gilboa lists five):

1. The server and the client agree on the bit length k of the modulusN . The parties make sure that both p and q are equal to 3 mod 4 bysetting the server’s shares of p and q, ps and qs, equal to 3 mod 4 andthe clients shares pc and qc equal to 0 mod 4. All other informationabout pi and qi is kept secret.

2. For each party, a list of the first l primes p is constructed so that the bitlength of

∏li=0 pi > k. For each of these primes a Benaloh cryptosystem

is set up and the sharing of (ps + pc)(qs + qc) mod pi is computed (seesection 4.2.3 on page 34). By using the Chinese Remainder Theorem(see section 2.5 on page 12), N is reconstructed from the shares. If(ps +pc)(qs +qc) mod pi = 0 is detected, each party chooses new sharesand the process is restarted.

3. After an N has been found that is relatively prime to all generatingprimes and has at least the desired bit length k, two bi-primality testsare executed: One adopted Fermat test (see section 2.6 on page 12 and

4.2. GILBOA’S PROTOCOL 33

section 4.2.4 on page 37) and a Fermat test in the twisted group thatcatches the few elements that may have passed the first test.

4. After the N has been found and shared by both parties, they computetheir private decryption exponent d. To this end, Oblivious Transfersare used. At the end of the computation, the parties have a shared RSAkey. Since this computation can be used in both Gilboa’s protocol andStraub’s protocol, it is implemented in its own package that is executedafter the shared modulus is found.

4.2.2 Program Design

State Command Next State(0) Initial State Preferred Shared Key Size (1)(1) Exchange Key Size Start Benaloh Setup (2)(2) Benaloh Setup Benaloh Setup (2)(2) Benaloh Setup Benaloh Setup Finished (3)(2) Benaloh Setup Benaloh Setup Failed (X)(3) Benaloh Setup Finished Start Candidate Generation (4)(4) Candidate Generation Conversion Mod Prime (4)(4) Candidate Generation N Mod Prime Is 0 (3)(4) Candidate Generation Generation Finished (5)(5) Candidate Found N Failed (3)(5) Candidate Found Start Verification (6)(6) Candidate Verification Conversion Mod Prime (6)(6) Candidate Verification Verification Failed (3)(6) Candidate Verification Verification Finished (7)(7) Candidate Verified New N (8)(8) New N N Failed (3)(8) New N Bi-primality Test (9)(9) Bi-primality Test Witness (9)(9) Bi-primality Test N Verified (X)(X) Finish

Table 4.1: States used in Gilboa’s protocol

The program is designed as a finite state machine in which for every stateonly a few commands are possible. State transitions are executed by definedcommands and for every state there is a very limited set of following states.During state transitions, there are always sanity checks on the environment;


thus corruption can be detected early and execution can be aborted if nec-essary.

For the Gilboa Protocol, all states with the allowed state transitions areshown in table 4.1 on the page before. The corresponding state machine isdiplayed in diagram 4.2 on the facing page.

Furthermore, for every set of commands that can be executed in a state,a strict order is implemented. With these precautions, both parties are verystrictly bound to the protocol.

At first, the client sends the public keys of his Benaloh cryptosystemsto the server. They are generated using the first l primes pi so that the bitlength of

∏li=1 pi > k. The server verifies this condition by checking that at

least l Benaloh public keys were sent and that the product of the upper limitsfor the message size ri is larger than the desired bit length of the shared key.Only if both criteria are met, the reconstruction of N is possible with theChinese Remainder Theorem.

4.2.3 Generation of N

The server generates two integers ps and qs that are both equal to 3 mod 4.The client generates two integer pc and qc that are equal to 0 mod 4.

Together, they want to compute N = (ps + pc)(qs + qc). We know fromthe Chinese Remainder Theorem that we can recompose an integer fromits remainders modulo coprime integers (see section 2.5 on page 12). In aBenaloh cryptosystem (see section 3.3 on page 22), all operations are modulothe message border r. Since the Benaloh encryption scheme is homomorphic,we can perform addition and multiplication on encrypted messages withoutdecrypting them. If we use multiple Benaloh systems with pairwise coprimemessage borders, we can do mathematical operations on very large messagesin small steps and recompose the operation on the large message by theChinese Remainder Theorem.

With a close look at N = (ps + pc)(qs + qc) = psqs + psqc + pcqs + pcqc wesee that if the client encrypts pc to c(pc) and qc to c(qc) and sends both tothe server, then the server can compute

c(N ′) = c(pc)qs · c(qc)ps · c(psqs)

without decrypting c(pc) and c(qc). Upon decryption, c(N ′) equals psqs +psqc + pcqs. Now the client can add pcqc to it and gets N . Since Benalohsystems limit messages below the message border r, the client constructs oneBenaloh system for every pi and reconstructs N using the Chinese RemainderTheorem. So effectively the server computes for every pi


Table 4.2: Finite state machine for Gilboa’s protocol


c(N ′i mod pi) = c(pc)

qs mod pi · c(qc)ps mod pi · c((psqs) mod pi)

and the client computes Ni = (pcqc) mod pi + N ′i . With the Chinese

Remainder Theorem N can be restored from the Ni and pi.

Privacy of the Parties

The privacy of the client is based on the hardness of the Benaloh cryptosys-tems it uses. If on average half of the cryptosystems are broken then itsshares are transparent to the server since they can be recovered by ChineseRemaindering (recall that the bit length of p and q is half the bit length ofN). But since all Benaloh cryptosystems used in the generation of N havethe same bit length as N , each is probably as hard to break as factoring Nis. So this is not a real threat.

The privacy of the server is based on the fact that every message sent ina Benaloh system is randomized by u. Since it is essential for the client thatthe Benaloh systems used have the same magnitude as N , u is also a pseudorandom element in ZN . The decryption cannot recover u from the encryptedmessage and thus the client gains only the information that c(N ′

i mod pi) isa random element in the partition (N − pcqc) mod pi of ZN . It cannot gainany new information from it.

Optimization

Gilboa proposes in section 5.2 of [Gil99] that both parties compute N bypicking random elements in pi and compute Ni separately for every elementas described above. If it turns out that N mod pi = 0, then both partiespick new shares for pi. At the end, N can be reconstructed from the Ni bymeans of the Chinese Remainder Theorem. This optimization is currentlyimplemented.

Another optimization that has not yet been implemented would be touse Naccache-Stern cryptosystems to compute N . If the primes used duringthe transfers are split into groups such that every group forms one σ of aNaccache-Stern cryptosystem, the number of transfers would be significantlyreduced.

Since σ consists of many primes, it is possible to check during decryptionfor every single prime if N mod pi = 0. For the few cases where this willhappen, Benaloh cryptosystems can be used to recompute until N mod pi 6=0. This would decrease the communication needed approximately by a factor


of 10 since the expansion rate of Naccache-Stern encoded messages is muchbetter than the expansion rate of messages encrypted with Benaloh systems.

The Java source code for the generation of N is shown in section A.12 onpage 72 for the client and in section A.13 on page 75 for the server.

4.2.4 Primality Test

The primality test is taken from section 4 of Boneh and Franklin [BF97] asGilboa recommends. For m parties, the test is m− 1 private and thus is alsosuitable for the two party scenario.

Boneh and Franklin look at all possible settings for an RSA N that iscomposed of two primes p and q which are equal to 3 modulo 4.

During the test, the parties detect an N that is not a product of twodistinct primes with probability at least 1

2for every complete run. Experience

shows that the test is even stronger: When a prime passes a single test, itusually passes repeated tests as well.

The test has the following steps:

1. The parties agree on a g with J(g,N) = 1. We already know that thereare two possibilities for the quadratic residues of such a g in N = p · q(see section 3.2 on page 20), namely 1 and −1. This g is used for thetest.

2. The client computes

vc = g−pc−qc

4

and the server computes

vs = gN−ps−qs+1

4 .

They combine to gain v = vc · vs = gN−p−q+1

4 . They check whetherv = ±1. If not, N is not the product of two distinct primes.

3. Additionally, the parties generates a random element from the twistedgroup of N , h ∈ TN (see also section 2.9 on page 15).

For both primes p and q, x2 + 1 is irreducible in ZN [x] since they areequal to 3 modulo 4 (for a proof, see Rogers [Rog05], page 1). Thus,ZN [x]x2+1

is a quadratic extension of ZN with N = p · q. The multiplicative

group Tp = Zp

x2+1/Zp has order p+1; similarly, Tq has order q+1. Thus,

TN has order (p+1)(q+1) and for all h ∈ TN : h(p+1)(q+1) = 1 = (1, 0).


For the chosen element, the client computes uc = hpc+qc

4 and the server

computes us = hN+ps+qs+1

4 . They compute u = uc · us = hN+p+q+1

4 andverify that u = 1 = (1, 0). If not, N is not the product of two distinctprimes, as will be shown below.

4. This test is repeated until the security parameters for primes of bothparties are met (usually 25 to 30 times).

Boneh and Franklin prove that the standard Fermat test already catchesalmost all N that are not the product of two primes, if g is chosen at randomin N . By using a g ∈ G for that J(g,N) = 1, they make sure that J(g, p) =J(g, q). Recalling the definition of the Jacobi Symbol (see section 2.8 onpage 14), and the fact that both q−1

2and p−1

2are uneven (because p = q =

3 mod 4), we can write

gN−p−q+1

4 = g(p−1)(q−1)

4 =(g

p−12

) q−12

= J(g, p)q−12 = J(g, p)

gN−p−q+1

4 = g(q−1)(p−1)

4 =(g

q−12

) p−12

= J(g, q)p−12 = J(g, q).

Now consider an N that is not the product of two distinct primes. Then,N can be written as N = rd1

1 . . . rdss . With the odd exponent e = (N − p −

q + 1)/4 = (p− 1)(q − 1)/4, we can define two subgroups of N :

G = {g ∈ ZN | J(g,N) = 1}H = {g ∈ G | ge = ±1}.

H is a subgroup of G because H is closed under multiplication; moreover,1 ∈ H, and H ⊆ G, since H is made of elements that are also in G.

To prove that we detect an N that is not the product of two distinctprimes with probability of at least 1

2, we have to show that |H| ≤ 1

2|G|.

Since G is closed under multiplication it suffices to find a single element ofG that is not in H. We have to consider four cases:

• N consists of 3 or more factors, thus s ≥ 3. Let r2 and r3 be distinctprime factors of N with the same exponent modulo 2. With threedifferent primes making up N , such a pair must exist. Let r1 be adistinct prime factor different from r2 and r3.

Define g ∈ G (with a being a quadratic non-residue modulo r3):


g ≡ 1 mod r1

g ≡ −1 mod r2

g ≡

{1 mod r3 if J(r2, N) = 1

a mod r3 if J(r2, N) = −1

g ≡ 1 mod ri.

By definition, J(g,N) = J(g, r1)d1 ·J(g, r2)

d2 ·J(g, r3)d3 · . . .. Since a is

a quadratic non-residue modulo r3, J(g, r3) = −1 if J(g, r2) = −1 andsince the exponents modulo 2 are equal, J(g,N) = 1. If J(g, r2) = 1,then J(g, r3) = 1 and J(g,N) = 1, too. A suitable g can be recon-structed from the moduli by the Chinese Remainder Theorem. Thus,g ∈ G.

Since e is odd, we have

ge mod r1 = g mod r1 = 1

ge mod r2 = g mod r2 = −1.

To meet both conditions at once, g cannot be ±1. Thus we have proventhe existence of a g ∈ G that is not in H for this case.

• Consider the condition that gcd(p, q) > 1. Then a prime r ≥ 3 existswhich divides both p and q (it can’t be 2 because N is odd). We haveN = rdp′ ·p′ ·rdq′ ·q′ and thus ϕ(N) = rk(r−1)(p′−1)·(q′−1) with k ≥ 1.Thus we have an element g of order r in ZN and therefore gr = 1. Sincer is odd, we have J(g,N) = J(g,N)r = J(gr, N) = J(1, N) = 1.

Therefore g is an element of G. We know that r divides both p and qand thus does not divide N − p− q + 1 = 4e. Thus, g4e 6= ±1 and alsoge 6= ±1, and therefore g /∈ H.

• An N that is not caught by the upper two cases must be of the formp · q = rd1

1 rd22 with gcd(r1, r2) = 1 and at least one of d1 or d2 greater

than 1.

Let us set d1 > 1. We now have as before ZN = rd1−11 (r1−1)rd2−1

2 (r2−1). Thus, again we have an element g with order r1 and J(g,N) = 1as above. If q mod rd1−1

1 6= 1, then again N − p− q + 1 is not divisibleby rd1−1

1 . As above, g /∈ H since ge 6= ±1.


• The last case is for N = rd11 · rd2

2 where d1 > 1 and q mod rd1−11 = 1.

An N of this form has a probability to pass the first three tests. Sincep ≡ q ≡ 3 mod 4 we know that r1 ≡ r2 ≡ 3 mod 4. For this case, thetest in the twisted group will fail with probability at least 1

2:

Define the group H ′ = {h ∈ TN | h(p+1)(q+1) = 1} which is a subgroupof TN . Again, we have to show that |H ′| ≤ 1

2|TN |. Again, proving

the existence of a single element of TN that is not in H ′ is sufficientbecause TN is closed under multiplication.

Since p = rd11 we know that the group Tp has order rd1−1(r1 +1). Thus

an element g of order r1 exists in Tp and similarly an element g′ existsin TN with order r1. Since we know that q mod r1 ≡ 1, it is clear thatr1 does not divide q + 1. Thus r1 cannot divide N + p + q + 1 andg(p+1)(q+1) 6= 1. Again we have found an element that is in TN but notin H ′ and can therefore be sure that we detect a composite N at leastwith probability 1

2.

The Java source code for the client’s prime test is in appendix A.14 onpage 77. The corresponding code for the server is in appendix A.15 onpage 81.

4.3 Oblivious Transfers

Oblivious Transfers enable party A to query party B for exactly one secretout of many secrets that party B holds. Party B sends that secret, but doesnot know which of the secrets was requested. Additionally, party A cannotlearn the other secrets. In the protocol for computing the private RSA keysfrom the shared modulus N this protocol is always used for two secrets. I

will now describe “one out of two” or

(21

)Oblivious Transfers as described

originally in Even et al. [EGL85] and in short in Wikipedia [Wik06e]:

• Party B generates an RSA key pair and sends the public exponent eand the modulus N to party A. For its secrets m0 and m1 in ZN , itprepares two random messages in ZN , x0 and x1. It then sends x0 andx1 to party A.

• Party A also generates a random message k in ZN . It encrypts k withB’s public key to c(k). Depending on the secret A wants to know, itsends kx, which is either c(k) + x0 or c(k) + x1 to B.

4.3. OBLIVIOUS TRANSFERS 41

• Party B decrypts two messages: k0 = kx − x0 and k1 = kx − x1, fromwhich only one reveals the correct k (but B doesn’t know which). Thedecryption of the other message leads to a random element in ZN thatparty A cannot guess.

B now sends k0 +m0 and k1 +m1 to party A

• Party A chooses the message corresponding to its choice of x0 or x1 andsubtracts k from it. It gains the correct message from B but cannotrecover B’s second secret.

It should be noted that the secrets m0 and m1 can be of arbitrary sizebecause they are transferred additively. If they are larger than N , the high-order bits of the secrets are exposed.

4.3.1 Converting Shared Secrets

Using Oblivious Transfers in a ring R, we can transform a multiplicativelyshared secret a·b into an additively shared secret x+y so that a·b = s = x+y.The same process can also be used to transform an additively shared secretinto a multiplicatively shared secret. The protocol presented here is basedon the protocol described in Gilboa [Gil99, section 4.1 and section 6].

Note that every element in the ring R can be encoded using ρ = log2 |R|bits. Thus, if mathematical operations can be carried out bitwise by usingOblivious Transfers, there are exactly ρ transfers needed for the computation.In the process described below, party A always has the secrets a and x andparty B always has the secrets b and y.

Party B chooses uniformly at random and independently ρ elements ofR. Let s0, s1, . . . sρ−1 denote the randomly chosen elements.

Party B additionally has a private element b,

• either by choosing a random element r in R if an additively sharedsecret shall be converted into a multiplicatively shared secret,

• or by setting it to the correct value b if a multiplicatively shared secretshall be converted into an additively shared secret.

Party B prepares ρ pairs of elements mi with

mi = (m0i ,m

1i ) = (si, 2

ib · si).

To convert the shared secret from one type to the other, party A uses itssecret denoted by a. Let aρ−1, . . . , a1, a0 denote the bits of party A’s secret.


Now, the parties execute ρ

(21

)Oblivious Transfers. In the ith invocation,

party A chooses from the tuple (m0i ,m

1i ) the mx

i that matches the bit in ai.Thus, if ai = 0, it chooses m0

i and if ai = 1 it chooses m1i .

Party A computes x =∑ρ−1

i=0 maii and party B computes y = −

∑ρ−ii=0m

0i

= −∑ρ−1

i=0 si.

The parties share x+ y = a · b. For a multiplicatively shared secret thatshall be converted into an additively shared secret we are done.

But an additively shared secret that shall be converted into a multiplica-tively shared secret needs more attention: Currently party A holds x and aand party B holds y, r and b.

Party B sends y+rb (since r is a random element in R, the secrets y and bare blinded) to party A. Party A computes x+ y︸︷︷︸

=a·r

+rb = r ·a+r ·b = r ·(a+b)

and party B computes r−1 in R; the conversion is finished.

Finally we have to prove that x + y = a · b over the ring R. The binaryrepresentation of a is given by aρ−1, . . . , a1, a0. Thus a =

∑ρ−1i=0 ai · 2i and as

proven in [Gil99, section 4.1] we find that

x+ y =

ρ−1∑i=0

taii −

ρ−1∑i=0

si

=

ρ−1∑i=0

(ai · 2i · b+ si)−ρ−1∑i=0

si

=

ρ−1∑i=0

(ai · 2i · b) +

ρ−1∑i=0

si −ρ−1∑i=0

si

= b

ρ−1∑i=0

(ai · 2i)

= a · b.

The code for Party B can be found in listing A.16 on page 85, the codefor Party A is analogously in listing A.17 on page 88.

4.4. COMPUTING THE PUBLIC AND THE PRIVATE EXPONENT 43

4.4 Computing the Public and the Private

Exponent

The client and the server share N = (pc + ps)︸︷︷︸=p

(qc + qs)︸︷︷︸=q

in an additive manner

and thus also share ϕ(N) = (p− 1)(q − 1) = N − p− q + 1 = N − pc − ps −qc − qs + 1 additively. Since in our setting the server holds the shares thatare equivalent to 3 mod 4, it is somewhat natural to split ϕ(N) = ϕs +ϕc =(N − ps − qs + 1) + (−pc − qc). To compute an RSA key, the parties have toagree on a public exponent e and compute the matching private exponent dso that de mod ϕ(N) = 1.

As also described in section 3.1 on page 19, the recent development inRSA side channel attacks has shown that RSA public exponents e such as3 or 216 + 1 are not very secure and should be avoided. For details pleasesee Fouque et al. [FKJM+06]. Similar problems arise if the private exponentis too small (see Wiener [Wie89] and Hinek [Hin06] for details). To avoidthis, both parties agree on a random public exponent in ZN that is primeand thus yields a very high probability that both the private and the publicexponent will not be susceptible to attacks.

Usually RSA private keys are constructed by inverting e modulo ϕ(N) byuse of the Chinese Remainder Theorem which is described in section 2.5 onpage 12. Unfortunately, ϕ(N) must be known to all parties to do this andthus the secret shares of the client and the server would be exposed.

Boneh and Franklin [BF97] describe how to generate a shared RSA privatekey without the need to make reductions modulo ϕ(N):

• First compute ζ = ϕ(N)−1 mod e.

• Set T = −ζ · ϕ(N) + 1. Modulo e we have

T mod e = −ζ(ϕ(N) mod e) + 1

= −(ϕ(N)

ϕ(N)mod e

)+ 1

= −1 + 1 = 0

and modulo ϕ(N)

T mod ϕ(N) = −ζ (ϕ(N) mod ϕ(N))︸︷︷︸=0

+1 = 1.


• Set d = Te. Thus, de = 1 mod ϕ(N).

Four steps are needed to apply this computation to the two-party scenario.The process is described in section 6 of Gilboa [Gil99]:

1. Transform the additive sharing of ϕ(N) = ϕc + ϕs into a multiplica-tive sharing ϕcm · ϕsm modulo e. We use the protocol described insection 4.3.1 on page 41 with the ring Ze.

The server incorporates party A in the protocol and his secret elementa is ϕs modulo e. The client takes party B and his b is a randomelement r of Ze.

As we want to convert an additively shared secret into a multiplicativelyshared secret, at the end of the conversion the client sends y + r · ϕc

modulo e to the server as described in the protocol. The server holdsϕsm = r · (ϕs +ϕc) and the client holds ϕcm = r−1. Hence, both partieshold multiplicative shares of ϕ(N) = ϕsm · ϕcm (modulo e).

2. The parties invert their shares modulo e. The server holds

ζs =1

ϕsm

=1

r((ϕs + ϕc) mod e)

and the client holds

ζc =1

ϕcm

=1

r−1= r.

Thus, they hold multiplicative shares of ϕ(N)−1 modulo e:

ζs · ζc =1

r((ϕs + ϕc) mod e)· r

=1 mod e

(ϕs + ϕc) mod e

= ϕ(N)−1 mod e.

Additionally the server negates his share so that the parties now share−ζ = −ζs · ζc = −ϕ(N)−1 mod e.


3. The shares of −ϕ(N)−1 modulo e are re-converted into additive shar-ings ψc and ψs using the algorithm given in section 4.3.1 on page 41.The ring used is again Ze.

The server’s initial secret a is −ζs and the client’s initial secret b is ζc.At the end of the protocol the parties share x+y = −ζs ·ζc. This resultcan be used, but to follow Gilboa’s protocol exactly, the sharing is notfinished when the server holds x and the client holds y.

Instead, the client additionally generates a ψc uniformly at randomfrom Ze. It then sends y − ψc to the server so that the server hasψs = x+ y−ψc = −ζsζc−ψc. This additional step can be skipped butdoes not have to, since it does not significantly slow down the protocoleither.

4. The parties now compute T−1 = −ζ ·ϕ(N) from Boneh and Franklin’sprotocol. The additive sharing of ζ is ψs + ψc as computed in theprevious step and the additive sharing of ϕ(N) = ϕs +ϕc = (N − ps−qs + 1) + (−pc − qc) is also known to both parties. Thus

T − 1 = −ζ · ϕ(N)

= (ϕs + ϕc)(ψs + ψc)

= ϕsψs + ϕsψc + ϕcψs + ϕcψc.

The elements needed to compute T−1 are shared by the server and theclient. The current sharing of T −1 is both additive and multiplicative.To convert it into a sharing that is only additive, both sides need toconvert the multiplicative sharings of ϕsψc to x1+y1 and ϕcψs to x2+y2.The server always holds xi and the client always holds yi. The sharingsare converted using Oblivious Transfers in a ring R with R > 4e ·N . Inthe current implementation, the ring used is Zk with k being the firstprime number that is larger than 4eN . The ring has to be larger than4eN because each element of T − 1 is composed of ϕi︸︷︷︸

∈ZN

ψi︸︷︷︸∈Ze

< N · e.

Since we have 4 shared elements, we can safely say that any ring Zk

with k > 4eN is sufficient for the computation of T − 1.

After the conversion, both parties hold elements of Zk. However, theaddition of the elements may lead to an element that is larger thank: The parties cannot reveal their elements, thus reductions modulo kcan only be made on a “per party” basis and not on the sum of theelements.


Following this argumentation, the computed value is either T − 1 orT−1+k. The latter case is not acceptable, because T+k mod ϕ(N) 6=1.

To avoid this problem and complete the computation of T − 1, theclient chooses uniformly at random an element y of Zk/2 and sendsy + y1 + y2 + ϕcψc to the server. The server now holds ϕsψs + x1 +x2 + (y+ y1 + y2 +ϕcψc) = (T − 1) + y. This value modulo k is smallerthan k. The client’s secret is −y which is in Zk/2. Added, the partieshave an element that is surely in Zk and thus the correct T − 1. Bychoosing y from Zk/2 the client’s security is not significantly reducedsince it looses only a single bit of security. Since this bit could also beguessed in an attempt to recover its secret, the loss does not signify.

Finally, the server sets

ds =ϕsψs + x1 + x2 + (y + y1 + y2 + ϕcψc)

e

=(T − 1) + y

e

and the client sets

dc =−y + 1

e.

Finally we get

ds + dc =(T − 1) + y − y + 1

e=T

e⇒ e · (ds + dc) mod ϕ(N) = 1.

Both parties hold additive shares of the secret exponent, thus they can de-crypt a encrypted message y = c(x) = xe by multiplication of the decryptedvalues:


yd = (xe)ds · (xe)dc

= (xe)ds+dc

= (xe)d

= x(ed−1)+1

= xϕ(N)+1

= xϕ(N) · x= x.


Chapter 5

Results

In order to judge the fitness of the software for practical use, a performanceanalysis is required. Mostly, the analysis focuses on aspects such as compu-tational effort versus key size – the key size is directly related to the securityof the key – as well as possible optimizations to the implementation. Finally,the question is addressed, whether it is likely that existing software can beused with the keys generated here.

5.1 Performance

When the implementation was finished, I noticed that one client only used≈ 30% of the the CPU when generating a 1024 bit key. This increased therunning time by a factor three, which was unacceptable. After a lengthyanalysis I found out that the TCP protocol used for communication seems towait until either enough data for sending a packet is available or a timeoutfor constructing packets has passed. Since the information sent is usually lessthan the data needed for a packet, the communication was impaired becausethe TCP stack slowed the data exchange.

I found a workaround by setting the TCP options TCP NODELAY to true

and setting TCP TRAFFIC CLASS to IPTOS LOWDELAY and IPTOS THROUGHPUT.This led to a much better processor usage of ≈ 80%.

5.1.1 Statistics

The search for an N that is a product of two primes is nondeterministic,since both parties choose their parts randomly and N is verified only againstthe first few primes during generation. On average, the computation of a 130bit RSA key takes 20 seconds on a AMD Athlon XP 2500+. In that case,

49

50 CHAPTER 5. RESULTS

the average communication between both parties sums to 500 kB where theclient generates roughly 350 kB and the server generates about 150 kB oftraffic. A large part of the bandwidth is used by the protocol to generate theprivate exponent d; here the client uses 216 kB of his traffic and the serverneeds 54 kB.

In section 8 of [Gil99], Gilboa maintains that a 1024 bit key has a com-munication complexity of 42 MB on average, when two primes are used perBenaloh key as opposed to one in the current implementation.

I received the following data for twenty runs of the protocol to generate1024 bit keys with unpaired Benaloh keys, without SSL overhead, via loop-back network on a 8x Xeon 3.2 GHz, with 10 clients and one server executingsimultaneously:

Traffic generatedRun Time Client [byte] Server [byte] Total [byte] Tries

#20 0:41:59 7045535 1911246 8956781 17#17 0:44:17 10423907 3604966 14028873 111#01 0:47:54 12140554 5210535 17351089 199#03 0:54:54 17580750 7545371 25126121 322#12 0:58:11 17357593 8035923 25393516 350#02 1:11:07 23148323 9934857 33083180 455#11 1:34:20 40390020 18651728 59041748 927#13 2:17:25 68191228 32605370 100796598 1685#07 2:17:27 72772452 34911252 107683704 1817#18 2:26:19 76017226 36545303 112562529 1906#04 2:24:43 79007433 38038436 117045869 1984#08 2:44:12 86896689 42000429 128897118 2200#15 2:41:25 88956596 43032935 131989531 2252#05 3:26:31 96007829 46575500 142583329 2451#16 2:49:27 99812655 48482706 148295361 2553#09 3:55:07 109519716 53355402 162875118 2823#10 5:35:27 203188471 100390472 303578943 5367#14 4:52:26 252834571 125315065 378149636 6740#06 9:54:02 417250385 207853153 625103538 11223#19 7:03:15 428536888 213518269 642055157 11547

Average 2:57:36 110206443 53875945 164082390 2846

On average, it takes 2846 rounds of the protocol to generate a 1024 bit keyand the whole process generates 164MB of network traffic. This is four times

5.2. USABILITY WITH EXISTING RSA SOFTWARE 51

as much as Gilboa claimed in section 8 of [Gil99]. From Gilboa’s results withpaired keys I would expect only twice as much traffic in my implementation.

Since Gilboa’s implementation is not transparent, it is not quite clearwhere the differences between his and my implementation lie. However, themost likely candidate is the size of the transferred data set. Here, I senduncompressed Java objects which, while they might result in some overhead,will certainly not be responsible for the large difference in traffic.

Interestingly, if I consider only the ten fastest runs of the algorithm, theaverage traffic suddenly diminishes to ≈ 50MB on average, which is muchcloser to Gilboa’s result.

5.2 Usability with Existing RSA Software

The Java API supports only RSA keys with 512 or more bits. Thus, smallerkeys cannot be saved to a PKCS#8 structure (as defined by the RSA Labo-ratories in [RSA93b]) for later use. Instead, all relevant data to reconstructthe key is logged and the user has to reconstruct the key on his own.

Keys with 512 bits or more are written to a standard PKCS#8 structure.The public key can be successfully reconstructed from the structure but isalso saved in a X.509 structure for later use.

Standard RSA software such as OpenSSL (http://www.openssl.org/)or the Java BouncyCastle library (http://www.bouncycastle.org/) use avery fast algorithm for RSA decryption. The algorithm basically decryptsmodulo p and modulo q and uses the Chinese Remainder Theorem to recom-pose the correct value.

The private RSA keys generated with this software cannot include p orq because neither party is supposed to know the values. Thus, standardlibraries and standard software will not work with the generated privatekeys. The generated public key does not have this problem and can be usednormally.

http://www.openssl.org/

http://www.bouncycastle.org/

52 CHAPTER 5. RESULTS

Chapter 6

Summary

The focus of the summary is twofold: On one hand, venues for future workare explored; on the other hand, the thesis is placed in realtion to its scientificcontext.

6.1 Outlook

With the current software, distributed RSA keys for two parties can be suc-cessfully generated so that neither party ever possessed the complete key andis also not able to reconstruct the complete key from the communication pro-tocol. But software is never perfect, so there still exist a few improvementsthat should be included in future releases:

• Gilboa’s protocol should be using Naccache-Stern cryptosystems in-stead of Benaloh cryptosystems as described in section 4.2.3 on page 36.I think that this will speed up the computation of N by a factor of morethan 2.

• Other protocols for generating shared RSA keys should be integrated aswell. I would like to mention Straub’s protocol as described in [Str03]which will probably give a dramatic decrease in key generation time.The current algorithm has to find two primes simultaneously. Thisimplies a running time in the order of k2 where k is the bit size ofthe generated keys. By generating keys with only one shared prime,the running time will be in the order of k. A disadvantage is that theresulting RSA key will be composed of three primes, which will furtherreduce its usability with off the shelf software.

• It would be nice to have protocol whitelists for the server so that pro-tocols deemed insecure can be excluded.

53

54 CHAPTER 6. SUMMARY

• An integration of the multi party protocol developed by Boneh andFranklin in [BF97] should be achieved. This would open the softwareto a broader range of users since then it would also allow more thantwo parties to generate a shared RSA key. The primality test could bere-used; other parts of the software would have to be adapted.

• I would like to see an integration of the software into a software for man-aging Certification Authorities, e.g. OpenCA (http://www.openca.org). This would result in an even broader range of potential users.

Although there are improvements that can be made, the software is in astate that is usable and reliable and therefore releasable as an open sourceproject.

6.2 Conclusion

In the course of this thesis, a software for generating shared RSA keys inthe two party scenario has been developed. Apart from the work of Bonehand Franklin [BF97], Gilboa [Gil99] and Straub [Str03] there exists to myknowledge no further literature on the subject of generating shared RSAkeys.

Moreover, the algorithms used in the process are not included in standardcryptographic libraries so that a verification and extension of the work of thethree authors initially requires a lot of preparation.

The cryptographic algorithms implemented in the course of this thesiswere submitted to the BouncyCastle library (http://www.bouncycastle.org). This may facilitate further development on the subject. Additionally,the software accompanying the thesis has a design that allows for easy inte-gration of other protocols tailored to generate two-party RSA keys and willsoon be made publicly available as an open source project.

The performance of the actual software is about half as good as proposedby Gilboa but can be boosted by using the Naccache-Stern cipher instead ofBenaloh’s. The Naccache-Stern cipher is fully implemented, only the inte-gration into Gilboa’s protocol is missing.

This thesis is one of the few, if any, that provide a complete coverage ofthe process of generating shared RSA keys for two parties. By explaining theneeded mathematical background, then introducing homomorphic encryptionand finally putting together and explaining the elements used in the protocoldesigned by Gilboa and Boneh and Franklin, it enables the reader to quicklygrasp the theoretical background. Combined with the complete source code

http://www.openca.org

http://www.openca.org

http://www.bouncycastle.org

http://www.bouncycastle.org

6.2. CONCLUSION 55

for the application as a reference to the reader, it is probably one of the mostcomplete guides on the subject.

56 CHAPTER 6. SUMMARY

Bibliography

[Ben94] Josh Benaloh. Dense Probabilistic Encryption. http:

//research.microsoft.com/crypto/papers/dpe.ps, 1994.Download on July 23rd, 2006. 3, 18, 22

[BF97] Dan Boneh and Matthew Franklin. Efficient Generation ofShared RSA Keys. http://theory.stanford.edu/~dabo/

abstracts/sharing.html, 1997. Download on May 23rd, 2006.3, 7, 31, 32, 37, 43, 54

[BOGW88] Michael Ben-Or, Shafi Goldwasser, and Avi Wigderson. Com-pleteness Theorems for Non-Cryptographic Fault-Tolerant Dis-tributed Computation. http://theory.lcs.mit.edu/~cis/

pubs/shafi/1988-stoc.pdf, 1988. Download on July 23rd,2006. 3, 7

[Bon99] Dan Boneh. The ITTC Project. http://crypto.stanford.

edu/~dabo/ITTC/, 1999. Download on August 11th, 2006. 7

[EGL85] Shimon Even, Oded Goldreich, and Abraham Lem-pel. A Randomized Protocol for Signing Contracts.http://portal.acm.org/citation.cfm?id=3818&dl=

&coll=GUIDE&CFID=15151515&CFTOKEN=6184618, http:

//delivery.acm.org/10.1145/10000/3818/p637-even.

pdf?key1=3818&key2=5964925511&coll=GUIDE&dl=&CFID=

15151515&CFTOKEN=6184618, 1985. Download on August 14th,2006. 3, 40

[FKJM+06] Pierre-Alain Fouque, Sebastien Kunz-Jaques, Gwenaelle Mar-tinet, Frederic Muller, and Frederic Valette. Power Attackon Small RSA Public Exponent. http://www.di.ens.fr/

~fouque/pub/ches06.pdf, 2006. Download on August 14th,2006. 19, 43

57

http://research.microsoft.com/crypto/papers/dpe.ps

http://research.microsoft.com/crypto/papers/dpe.ps

http://theory.stanford.edu/~dabo/abstracts/sharing.html

http://theory.stanford.edu/~dabo/abstracts/sharing.html

http://theory.lcs.mit.edu/~cis/pubs/shafi/1988-stoc.pdf

http://theory.lcs.mit.edu/~cis/pubs/shafi/1988-stoc.pdf

http://crypto.stanford.edu/~dabo/ITTC/

http://crypto.stanford.edu/~dabo/ITTC/

http://portal.acm.org/citation.cfm?id=3818&dl=&coll=GUIDE&CFID=15151515&CFTOKEN=6184618

http://portal.acm.org/citation.cfm?id=3818&dl=&coll=GUIDE&CFID=15151515&CFTOKEN=6184618

http://delivery.acm.org/10.1145/10000/3818/p637-even.pdf?key1=3818&key2=5964925511&coll=GUIDE&dl=&CFID=15151515&CFTOKEN=6184618




http://www.di.ens.fr/~fouque/pub/ches06.pdf

http://www.di.ens.fr/~fouque/pub/ches06.pdf

58 BIBLIOGRAPHY

[Fl05] Jana Froschler. Probabilistische Algorithmen fur PRIMES.http://tal.cs.tu-berlin.de/lv/ws0405/komplexitaet/

ausarb-froeschler.pdf, 2005. Download on August 11th,2006. 15

[Gil99] Niv Gilboa. Two Party RSA Key Generation. http://www.

cs.technion.ac.il/~gilboa/rsa2805.ps, 1999. Download onMay 23rd, 2006. 3, 8, 18, 31, 32, 36, 41, 42, 44, 50, 51, 54

[GM] S. Goldwasser and S. Micali. Probabilistic Encryption. http:

//theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf.Download on July 23rd, 2006. 3, 18, 20

[Hin06] M. Jason Hinek. Another Look at Small RSA Expo-nents. http://www.cs.uwaterloo.ca/~mjhinek/ct-rsa06.

pdf, 2006. Download on August 14th, 2006. 43

[KS98] B. Kaliski and J. Staddon. RFC 2437: PKCS #1: RSA Crypto-graphy Specifications Version 2.0. ftp://ftp.math.utah.edu/pub/rfc/rfc2437.txt, 1998. Obsoletes RFC 2313, downloadon August 11th, 2006. 3, 7

[MvOV96] Alfred J. Menezes, Paul C. van Oorschot, and Scott A.Vanstone. Handbook of Applied Cryptography.http://www.cacr.math.uwaterloo.ca/hac/, 1996. Download onAugust 11th, 2006. 10, 12

[NS98] David Naccache and Jacques Stern. A New Public KeyCryptosystem Based on Higher Residues. http://www.

gemplus.com/smart/rd/publications/pdf/NS98pkcs.pdf,1998. Download on July 23rd, 2006. 18, 23, 25, 27

[Res99] E. Rescorla. RFC #2631: Diffie-Hellman Key Agree-ment Method. http://www.ietf.org/rfc/rfc2631.txt, 1999.Download on August 11th, 2006. 22

[Rog05] John Henrik Rogers. Finite Fields (Galois Fields). http://

www-math.mit.edu/~dav/finitefields.pdf, 2005. Downloadon August 11th, 2006. 37

[RSA93a] RSA Laboratories. PKCS#12: Personal Information ExchangeSyntax Standard. http://www.rsasecurity.com/rsalabs/

node.asp?id=2138, 1993. Download on August 11th, 2006. 30

http://tal.cs.tu-berlin.de/lv/ws0405/komplexitaet/ausarb-froeschler.pdf

http://tal.cs.tu-berlin.de/lv/ws0405/komplexitaet/ausarb-froeschler.pdf

http://www.cs.technion.ac.il/~gilboa/rsa2805.ps

http://www.cs.technion.ac.il/~gilboa/rsa2805.ps

http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf

http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf

http://www.cs.uwaterloo.ca/~mjhinek/ct-rsa06.pdf

http://www.cs.uwaterloo.ca/~mjhinek/ct-rsa06.pdf

ftp://ftp.math.utah.edu/pub/rfc/rfc2437.txt

ftp://ftp.math.utah.edu/pub/rfc/rfc2437.txt

http://www.gemplus.com/smart/rd/publications/pdf/NS98pkcs.pdf

http://www.gemplus.com/smart/rd/publications/pdf/NS98pkcs.pdf

http://www.ietf.org/rfc/rfc2631.txt

http://www-math.mit.edu/~dav/finitefields.pdf

http://www-math.mit.edu/~dav/finitefields.pdf

http://www.rsasecurity.com/rsalabs/node.asp?id=2138


BIBLIOGRAPHY 59

[RSA93b] RSA Laboratories. PKCS#8: Private Key Information SyntaxStandard. http://www.rsasecurity.com/rsalabs/node.asp?id=2130, 1993. Download on August 11th, 2006. 51

[Str03] Tobias Straub. Efficient Two Party Multi-Prime RSA KeyGeneration. http://www.informatik.tu-darmstadt.de/GK/

staff/straub/publications/straub_cnis_2003.pdf, 2003.Download on July 23rd, 2006. 3, 15, 32, 53, 54

[Wei04] Eric W. Weisstein. Fermat’s Little Theorem. http://

mathworld.wolfram.com/FermatsLittleTheorem.html, 2004.Download on August 11th, 2006. 12

[Wei05] Eric W. Weisstein. Carmichael Number. http://mathworld.

wolfram.com/CarmichaelNumber.html, 2005. Download onAugust 11th, 2006. 14

[Wie89] Michael J. Wiener. Cryptanalysis of Short RSA Secret Expo-nents. http://www3.sympatico.ca/wienerfamily/Michael/

MichaelPapers/ShortSecretExponents.pdf, 1989. Downloadon August 14th, 2006. 43

[Wik06a] Wikipedia. Chinese Remainder Theorem. http://

en.wikipedia.org/wiki/Chinese_remainder_theorem, 2002-2006. Download on August 11th, 2006. 12

[Wik06b] Wikipedia. Euclidean Algorithm. http://en.wikipedia.org/

wiki/Euclidean_algorithm, 2002-2006. Download on August11th, 2006. 10

[Wik06c] Wikipedia. Euler’s totient function. http://en.wikipedia.

org/wiki/Euler%27s_totient_function, 2002-2006. Down-load on August 11th, 2006. 19

[Wik06d] Wikipedia. Multiplicative group of integers modulo n.http://en.wikipedia.org/wiki/Multiplicative_group_

of_integers_modulo_n, 2004-2006. Download on August 11th,2006. 19

[Wik06e] Wikipedia. Oblivious transfer. http://en.wikipedia.org/

wiki/Oblivious_transfer#1-2_oblivious_transfer, 2004-2006. Download on August 11th, 2006. 40



http://www.informatik.tu-darmstadt.de/GK/staff/straub/publications/straub_cnis_2003.pdf

http://www.informatik.tu-darmstadt.de/GK/staff/straub/publications/straub_cnis_2003.pdf

http://mathworld.wolfram.com/FermatsLittleTheorem.html

http://mathworld.wolfram.com/FermatsLittleTheorem.html

http://mathworld.wolfram.com/CarmichaelNumber.html

http://mathworld.wolfram.com/CarmichaelNumber.html

http://www3.sympatico.ca/wienerfamily/Michael/MichaelPapers/ShortSecretExponents.pdf

http://www3.sympatico.ca/wienerfamily/Michael/MichaelPapers/ShortSecretExponents.pdf

http://en.wikipedia.org/wiki/Chinese_remainder_theorem

http://en.wikipedia.org/wiki/Chinese_remainder_theorem

http://en.wikipedia.org/wiki/Euclidean_algorithm

http://en.wikipedia.org/wiki/Euclidean_algorithm

http://en.wikipedia.org/wiki/Euler%27s_totient_function

http://en.wikipedia.org/wiki/Euler%27s_totient_function

http://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n

http://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n

http://en.wikipedia.org/wiki/Oblivious_transfer#1-2_oblivious_transfer

http://en.wikipedia.org/wiki/Oblivious_transfer#1-2_oblivious_transfer

60 BIBLIOGRAPHY

Appendix A

Appendix: Source Code

A.1 Mathematical Tools

Listing A.1: Chinese Remainder Theorem in PrimeUtils.java105 /∗∗

∗ Computes t h e i n t e g e r x t h a t i s e x p r e s s e d through th e g i v en primes and the

∗ congruences w i th t h e c h i n e s e remainder theorem (CRT) .

∗∗ @param congruences

110 ∗ t h e congruences c i

∗ @param primes

∗ t h e pr imes p i

∗ @return an i n t e g e r x f o r t h a t x % p i == c i

∗/

115 public stat ic Big Intege r chineseRemainder ( f ina l Vector congruences ,

f ina l Vector primes ) {Big Intege r r e t v a l = ZERO;

Big Intege r a l l = ONE;

for ( int i = 0 ; i < primes . s i z e ( ) ; i++) {120 a l l = a l l . mult ip ly ( ( B ig Intege r ) primes . elementAt ( i ) ) ;

}Big Intege r a ;

B ig Intege r b ;

B ig Intege r b ;

125 Big Intege r tmp ;

for ( int i = 0 ; i < primes . s i z e ( ) ; i++) {a = ( Big Intege r ) primes . elementAt ( i ) ;

b = a l l . d i v ide ( a ) ;

b = b . modInverse ( a ) ;

130 tmp = b . mult ip ly ( b ) ;

tmp = tmp . mult ip ly ( ( B ig Intege r ) congruences . elementAt ( i ) ) ;

r e t v a l = r e t v a l . add (tmp) .mod( a l l ) ;

}return r e t v a l ;

135 }

Listing A.2: Legendre Symbol in PrimeUtils.java30 /∗∗

∗ Computes t h e Legendre symbol o f a and p .

∗

61

62 APPENDIX A. APPENDIX: SOURCE CODE

∗ @param a

∗ t h e number to t e s t

35 ∗ @param p

∗ t h e prime p

∗ @return the Legendre symbol −1 , 0 or 1 . See a l s o Jacob i Symbol .

∗ @see # jacob iSymbo l ( B i g In t e g e r , B i g I n t e g e r )

∗/

40 public stat ic int legendreSymbol ( f ina l Big Intege r a , f ina l Big Intege r p) {Big Intege r tmp = a ;

tmp = tmp .mod(p) ;

f ina l Big Intege r sym = tmp .modPow( ( p . subt rac t (ONE) ) . d iv ide (TWO) , p) ;

i f ( sym . equa l s (ZERO) ) {45 return 0 ;

}i f ( sym . equa l s (ONE) ) {

return 1 ;

}50 // mod in Java a lways r e t u rn s p o s i t i v e i n t e g e r s

i f ( sym . equa l s (p . subt rac t (ONE) ) | | ( sym .mod(p) ) . equa l s (p . subt rac t (ONE) ) ) {return −1;

}// shou ldn ’ t g e t here

55 throw new I l l ega lArgumentExcept ion (

" p r o b a b l y the s e c o n d a r g u m e n t is not p r i m e " ) ;

}

Listing A.3: Jacobi Symbol in PrimeUtils.java/∗∗

60 ∗ Returns t h e Jacob i symbol ( a over p ) :

∗∗ < l i > −1 i f a i s not q u a d r a t i c r e s i d u e mod p </ l i >

∗ < l i > 0 i f a i s mu l t i p l e o f p </ l i >

∗ < l i > 1 i f a i s q u a d r a t i c r e s i d u e mod p </ l i >

65 ∗∗ @param a

∗ t h e number to t e s t

∗ @param p

∗ t h e prime or uneven number t h e t e s t i s run a g a i n s t .

70 ∗ @return the Jacob iSymbo l −1 , 0 or 1 .

∗/

public stat ic int jacobiSymbol ( f ina l Big Intege r a , f ina l Big Intege r p) {

i f ( a . equa l s (ZERO) ) {75 return 0 ;

}i f ( a . equa l s (ONE) ) {

return 1 ;

}80 i f ( a . compareTo (p) > 0) {

return jacobiSymbol ( a .mod(p) , p) ;

}i f ( a .mod(FOUR) . equa l s (ZERO) ) {

return jacobiSymbol ( a . d iv ide (FOUR) , p) ;

85 }i f ( a .mod(TWO) . equa l s (ZERO)

&& (p .mod(EIGHT) . equa l s (ONE) | | p .mod(EIGHT) . equa l s (SEVEN) ) ) {return jacobiSymbol ( a . d iv ide (TWO) , p) ;

}90 i f ( a .mod(TWO) . equa l s (ZERO)

&& (p .mod(EIGHT) . equa l s (THREE) | | p .mod(EIGHT) . equa l s (FIVE) ) ) {return (−1) ∗ jacobiSymbol ( a . d iv ide (TWO) , p) ;

}i f ( a .mod(FOUR) . equa l s (ONE) | | p .mod(FOUR) . equa l s (ONE) ) {

A.1. MATHEMATICAL TOOLS 63

95 return jacobiSymbol (p .mod( a ) , a ) ;

}i f ( a .mod(FOUR) . equa l s (THREE) | | p .mod(FOUR) . equa l s (THREE) ) {

return (−1) ∗ jacobiSymbol (p .mod( a ) , a ) ;

}100 // shou l d never g e t here

throw new I l l ega lArgumentExcept ion (

" p r o b a b l y the s e c o n d a r g u m e n t is e v e n " ) ;

}


A.2 Cryptosystems

Listing A.4: Goldwasser-Micali key generation in BenalohKeyPairGenera-tor.java

/∗∗∗ Generates a new Goldwasser−Mica l i key pa i r u s ing t h e g i v en key g en e r a t i on

175 ∗ parameters .

∗∗ @return An AsymmetricCipherKeyPair c on t a i n i n g a Goldwasser−Mica l i key

∗ pa i r .

∗/

180 private AsymmetricCipherKeyPair generateGMKeyPair ( ) {

// bp are t h e key g en e r a t i on parameters s u p p l i e d by t h e user

p = new Big Intege r (bp . getStrength ( ) / 2 , bp

. getPr imeCerta inty ( ) , bp . getRandom () ) ;

185

q = new Big Intege r (bp . getStrength ( ) / 2 , bp


n = p . mult ip ly (q ) ;

190

do {y = PrimeUti l s . getRandom(n , bp . getRandom () ) ;

} while ( ( Pr imeUti l s . jacobiSymbol (y , p) != −1)

&& (PrimeUti l s . jacobiSymbol (y , q ) != −1) ) ;

195

return new AsymmetricCipherKeyPair (new BenalohKeyParameters (y ,

r , n ) , new BenalohPrivateKeyParameters (y ,

r , n , p , q ) ) ;

200 }

Listing A.5: Benaloh & Goldwasser-Micali encryption in BenalohEngine.java/∗∗∗ Encrypts a B i g I n t e g e r r e p r e s e n t i n g t h e p l a i n t e x t message w i th t h e p u b l i c

140 ∗ key .

∗∗ @param p l a i n

∗ The p l a i n t e x t message

∗ @return The enc ryp t ed p l a i n t e x t message as B i g I n t e g e r . toByteArray ( )

145 ∗/

private byte [ ] encrypt ( f ina l Big Intege r p l a in ) {c e r t = PrimeUti l s . getRandom(bkp . getModulus ( ) , rand ) ;

f ina l byte [ ] output = bkp . getModulus ( ) . toByteArray ( ) ;

Arrays . f i l l ( output , Byte . parseByte ( " 0 " ) ) ;

150

Big Intege r encrypted = bkp . getY ( ) .modPow( pla in , bkp . getModulus ( ) ) ;

encrypted = encrypted . mult ip ly (

c e r t .modPow(bkp . getMessageBorder ( ) , bkp . getModulus ( ) ) ) .mod(

bkp . getModulus ( ) ) ;

155

f ina l byte [ ] tmp = encrypted . toByteArray ( ) ;

System

. arraycopy (tmp , 0 , output , output . l ength − tmp . length ,

tmp . l ength ) ;

160 i f ( debug ) {System . out . p r i n t l n ( " E n c r y p t e d v a l u e is : "

+ new Big Intege r ( 1 , output ) ) ;

}

A.2. CRYPTOSYSTEMS 65

return output ;

165

}

Listing A.6: Goldwasser-Micali decryption in BenalohEngine.java/∗∗∗ Decryp t s a B i g I n t e g e r r e p r e s e n t i n g an enc ryp t ed b i t w i th t h e

190 ∗ Goldwasser−Mica l i a l g o r i t hm

∗∗ @param encryp t ed

∗ The enc ryp t ed message

∗ @return The de c r yp t e d message in a B i g I n t e g e r . toByteArray ( )

195 ∗/

private byte [ ] decryptGM( f ina l Big Intege r encrypted ) {f ina l BenalohPrivateKeyParameters privKey = ( BenalohPrivateKeyParameters ) bkp ;

f ina l int pRes = PrimeUti l s . jacobiSymbol ( encrypted , privKey . getPQ ( ) [ 0 ] ) ;

f ina l int qRes = PrimeUti l s . jacobiSymbol ( encrypted , privKey . getPQ () [ 1 ] ) ;

200

i f ( debug ) {System . out . p r i n t l n ( " p R e s is " + pRes ) ;

System . out . p r i n t l n ( " q R e s is " + qRes ) ;

}205

i f ( ( pRes == 1) && (qRes == 1) ) {return Big Intege r .ZERO. toByteArray ( ) ;

} else {return Big Intege r .ONE. toByteArray ( ) ;

210 }

Listing A.7: Benaloh key generation in BenalohKeyPairGenerator.java/∗∗∗ Generates a Benaloh key pa i r u s ing t h e g i v en key g en e r a t i on parameters .

∗80 ∗ @return An AsymmetricCipherKeyPair c on t a i n i n g a Benaloh key pa i r .

∗/

private AsymmetricCipherKeyPair generateBenalohKeyPair ( ) {// Generate p

f ina l Big Intege r s tartP = new Big Intege r (bp . getStrength ( ) / 2

85 − r . b itLength ( ) − 24 , bp . getPr imeCerta inty ( ) , bp

. getRandom () ) ;

while ( true ) {p = startP . mult ip ly ( B ig Intege r . valueOf (2) ) ;

p = p . mult ip ly (new Big Intege r ( 24 , bp

90 . getPrimeCerta inty ( ) , bp . getRandom () ) ) ;

p = p . mult ip ly ( r ) ;

p = p . add ( Big Intege r .ONE) ;

f ina l Big Intege r pMinus1 = p . subt rac t ( B ig Intege r .ONE) ;

95 // r s h a l l d i v i d e p−1

i f ( ! pMinus1 .mod( r ) . equa l s ( B ig Intege r .ZERO) ) {i f ( debug ) {

System . out . p r i n t l n ( " r d o e s not d i v i d e p -1 " ) ;

}100 continue ;

}

// ( p−1) / r and r s h a l l be r e l a t i v e l y prime

i f ( ! ( r . gcd ( pMinus1 . d iv ide ( r ) ) . equa l s ( B ig Intege r .ONE) ) ) {105 i f ( debug ) {

System . out . p r i n t l n ( " p - 1 / r and r are not r e l a t i v e l y p r i m e " ) ;

}


continue ;

}110

i f ( ! p . i sProbablePrime (bp . getPr imeCerta inty ( ) ) ) {i f ( debug ) {

System . out . p r i n t l n ( " not p r i m e : " + p) ;

}115 continue ;

}i f ( debug ) {

System . out . p r i n t l n ( " New B e n a l o h p " + p + " w i t h "

+ p . bitLength ( ) + " bit . " ) ;

120 }break ;

}

125 // Generate q

while ( true ) {q = new Big Intege r (bp . getStrength ( ) / 2 , bp


i f ( debug ) {130 System . out . p r i n t l n ( " New B e n a l o h q " + q) ;

}// r and ( q−1) s h a l l be r e l a t i v e l y prime .

i f ( ! r . gcd (q . subt rac t ( B ig Intege r .ONE) ) . equa l s (

B ig Intege r .ONE) ) {135 continue ;

}break ;

}i f ( debug ) {

140 System . out . p r i n t l n ( " New B e n a l o h q " + q + " w i t h "

+ q . bitLength ( ) + " bit . " ) ;

}

n = p . mult ip ly (q ) ;

145 i f ( debug ) {System . out . p r i n t l n ( " New B e n a l o h n " + n + " w i t h "

+ n . bitLength ( ) + " bit . " ) ;

}

150 while ( true ) {y = PrimeUti l s . getRandom(n , bp . getRandom () ) ;

i f ( debug ) {System . out . p r i n t l n ( " New B e n a l o h y " + y) ;

}155

i f ( ! y . gcd (n) . equa l s ( B ig Intege r .ONE) ) {continue ;

}i f ( y .modPow(

160 ( ( p . subt rac t ( B ig Intege r .ONE) ) . mult ip ly (q

. subt rac t ( B ig Intege r .ONE) ) ) . d i v ide ( r ) , n)

. equa l s ( B ig Intege r .ONE) ) {continue ;

}165 break ;

}return new AsymmetricCipherKeyPair (new BenalohKeyParameters (y ,

r , n ) , new BenalohPrivateKeyParameters (y ,

r , n , p , q ) ) ;

170

}


Listing A.8: Benaloh decryption in BenalohEngine.java/∗∗

215 ∗ Decryp t s a B i g I n t e g e r t h a t i s a Benaloh enc ryp t ed message .

∗∗ @param encryp t ed

∗ The enc ryp t ed message

∗ @return A B i g I n t e g e r . toByteArray ( ) r e p r e s e n t i n g t h e d e c r yp t e d message .

220 ∗/

private byte [ ] decryptBenaloh ( f ina l Big Intege r encrypted ) {f ina l BenalohPrivateKeyParameters privKey = ( BenalohPrivateKeyParameters ) bkp ;

// s e t up lookup t a b l e i f n e c e s sa r y

225 i f ( privKey . getLookupList ( ) . s i z e ( ) == 0) {privKey . setupLookupList ( ) ;

}

Big Intege r [ ] pq = privKey . getPQ () ;

230 Big Intege r pSub1 = pq [ 0 ] . subt rac t ( B ig Intege r .ONE) ;

B ig Intege r qSub1 = pq [ 1 ] . subt rac t ( B ig Intege r .ONE) ;

B ig Intege r exp = pSub1 . mult ip ly ( qSub1 ) . d iv ide (bkp . getMessageBorder ( ) ) ;

B ig Intege r r e s = PrimeUti l s . chineseModPow ( encrypted , exp , pq ) ;

235 f ina l byte [ ] output = privKey . getMessageBorder ( ) . toByteArray ( ) ;


f ina l Big Intege r decrypted = ( Big Intege r ) privKey . getLookupList ( ) . get (

r e s ) ;

f ina l byte [ ] tmp = decrypted . toByteArray ( ) ;

240 System


tmp . l ength ) ;

i f ( debug ) {System . out . p r i n t l n ( " D e c r y p t e d v a l u e is " + decrypted ) ;

245 }return output ;

}

Listing A.9: Naccache Stern key generation in NaccacheSternKeyPairGener-ator.java

/∗∗∗ Generates a new NaccacheSternKeyPair u s ing t h e number o f p r o c e s s o r s g i v en

190 ∗ in t h e c on s t r u c t o r and the parameters s u p p l i e d in t h e i n i t ( ) method .

∗∗∗ @see org . b o un c y c a s t l e . c r yp t o . AsymmetricCipherKeyPairGenerator#genera teKeyPair ( )

∗/

195 public AsymmetricCipherKeyPair generateKeyPair ( ) {

// Permute t h e prime l i s t i n d i v i d u a l l y

smal lPrimes = permuteList ( smallPrimes , rand ) ;

200 // compute u and v

u = Big Intege r .ONE;

v = Big Intege r .ONE;

for ( int i = 0 ; i < smal lPrimes . s i z e ( ) / 2 ; i++) {205 u = u . mult ip ly ( ( B ig Intege r ) smal lPrimes . get ( i ) ) ;

}for ( int i = smal lPrimes . s i z e ( ) / 2 ; i < smal lPrimes . s i z e ( ) ; i++) {

v = v . mult ip ly ( ( B ig Intege r ) smal lPrimes . get ( i ) ) ;

}210

// the upper bound f o r messages , sigma


sigma = u . mult ip ly (v ) ;

// g ene ra t e a and b ( t h r eaded )

215 generateAB ( ) ;

i f ( debug ) {System . out . p r i n t l n ( " g e n e r a t i n g p and q " ) ;

}220

// g ene ra t e p and q ( t h r eaded )

generatePQ () ;

// n and \ ph i (n )

225 n = p . mult ip ly (q ) ;

phi n = p . subt rac t ( B ig Intege r .ONE) . mult ip ly (q . subt rac t ( B ig Intege r .ONE) ) ;

i f ( debug ) {System . out . p r i n t l n ( " g e n e r a t i n g y " ) ;

230 }

// compute y , NCS ’98 c a l l s i t g ( t h r eaded )

computeY ( ) ;

235 i f ( debug ) {System . out . p r i n t l n ( ) ;

System . out . p r i n t l n ( " f o u n d new N a c c a c h e S t e r n c i p h e r v a r i a b l e s : " ) ;

System . out . p r i n t l n ( " s m a l l P r i m e s : " + smallPrimes ) ;

System . out . p r i n t l n ( " s i g m a : . . . . . . " + sigma + " ( "

240 + sigma . bitLength ( ) + " b i t s ) " ) ;

System . out . p r i n t l n ( " a : . . . . . . . . . . " + a) ;

System . out . p r i n t l n ( " b : . . . . . . . . . . " + b) ;

System . out . p r i n t l n ( " p ’ : . . . . . . . . . " + p ) ;

System . out . p r i n t l n ( " q ’ : . . . . . . . . . " + q ) ;

245 System . out . p r i n t l n ( " p : . . . . . . . . . . " + p) ;

System . out . p r i n t l n ( " q : . . . . . . . . . . " + q) ;

System . out . p r i n t l n ( " n : . . . . . . . . . . " + n) ;

System . out . p r i n t l n ( " phi ( n ) : . . . . . " + phi n ) ;

System . out . p r i n t l n ( " y : . . . . . . . . . . " + y) ;

250 System . out . p r i n t l n ( ) ;

}

return new AsymmetricCipherKeyPair (new NaccacheSternKeyParameters (

false , y , n , sigma ) , new NaccacheSternPrivateKeyParameters (y ,

255 n , sigma , smallPrimes , p , q , debug , processorCount ) ) ;

}

Listing A.10: Naccache Stern encryption in NaccacheSternEngine.java/∗∗∗ Encrypts a B i g I n t e g e r aka P l a i n t e x t w i th t h e p u b l i c key . Uses

175 ∗ p r o b a b i l i s t i c en c r yp t i on i f a c e r t i f i c a t e i s s e t .

∗∗ @param p l a i n

∗ The B i g I n t e g e r to enc ryp t

∗ @return The b y t e [ ] r e p r e s e n t a t i o n o f t h e enc ryp t ed B i g I n t e g e r ( i . e .

180 ∗ c r yp t e d . toByteArray ( ) )

∗/

public byte [ ] encrypt ( f ina l Big Intege r p l a in ) {// Always r e t u rn modulus s i z e v a l u e s 0−padded a t t h e b e g i nn in g

// 0− padding a t t h e b e g i nn in g i s c o r r e c t l y parsed by B i g I n t e g e r : )

185 f ina l byte [ ] output = key . getModulus ( ) . toByteArray ( ) ;


B ig Intege r encrypted = key . getY ( ) .modPow( pla in , key . getModulus ( ) ) ;


// C e r t i f i c a t e i s t h e un i f o rm ly a t random gene ra t ed o b f u s c a t i n g e l ement

190 // from Z n

i f ( c e r t i f i c a t e != null ) {encrypted = c e r t i f i c a t e .modPow( key . getSigma ( ) , key . getModulus ( ) )

. mult ip ly ( encrypted ) .mod( key . getModulus ( ) ) ;

}195

f ina l byte [ ] tmp = encrypted . toByteArray ( ) ;

System


tmp . l ength ) ;

200 i f ( debug ) {System . out . p r i n t l n ( " E n c r y p t e d v a l u e is : "

+ new Big Intege r ( 1 , output ) ) ;

}return output ;

205 }

Listing A.11: Naccache Stern decryption in NaccacheSternEngine.java/∗∗∗ Decryp t s a B i g I n t e g e r t h a t r e p r e s e n t s t h e enc ryp t ed message .

390 ∗∗ @param inpu t

∗ The message

∗ @return A by t e array t h a t c on t a i n s t h e d e c r yp t e d message as

∗ Bi g I n t e g e r . toByteArray ( ) .

395 ∗/

private synchronized byte [ ] decrypt ( f ina l Big Intege r input ) {f ina l NaccacheSternPrivateKeyParameters pr iv = ( NaccacheSternPrivateKeyParameters )

key ;

f ina l Vector primes = pr iv . getSmallPrimes ( ) ;

p l a in = new Vector ( primes . s i z e ( ) ) ;

400 threads = new Vector ( ) ;

// Get Chinese Remainders o f CipherText

f ina l Object tmp = new Object ( ) ;

B ig Intege r smallPrime ;

405 Thread t ;

for ( int i = 0 ; i < primes . s i z e ( ) ; i++) {// i n s e r t o b j e c t s i n t o p l a in , so I can use Vector . se tE lementAt ( )

p la in . add (tmp) ;

smallPrime = ( Big Intege r ) primes . get ( i ) ;

410 t = new DecryptBySmallPrime ( smallPrime , input ) ;

threads . add ( t ) ;

}

f ina l Vector runningThreads = new Vector ( ) ;

415

synchronized ( waitFor ) {

for ( int i = 0 ; ( i < threads . s i z e ( ) ) && ( i < processorCount ) ; i++) {t = ( Thread ) threads . get ( i ) ;

420 runningThreads . add ( t ) ;

t . s t a r t ( ) ;

}

while ( threads . s i z e ( ) > 0) {425 try {

waitFor . wait ( ) ;

} catch ( f ina l Inter ruptedExcept ion e ) {}for ( int i = 0 ; i < threads . s i z e ( ) ; i++) {

430 t = ( Thread ) threads . get ( i ) ;


i f ( ! runningThreads . conta in s ( t ) ) {runningThreads . add ( t ) ;

t . s t a r t ( ) ;

break ;

435 }}

}}for ( int i = 0 ; i < runningThreads . s i z e ( ) ; i++) {

440 t = ( Thread ) runningThreads . get ( i ) ;

try {t . j o i n ( ) ;

} catch ( f ina l Inter ruptedExcept ion e ) {}

445 }

// compute message from remainders

f ina l Big Intege r r e t v a l = PrimeUti l s . chineseRemainder ( p la in , primes ) ;

450 return r e t v a l . toByteArray ( ) ;

}

/∗∗455 ∗ Ca l l b a c k f u n c t i o n f o r d e c r y p t i on t h r e ad s . They submi t t h e d e c r yp t e d va l u e

∗ modulo t h e i r prime .

∗∗ @param t

∗ The d e c r y p t i on th r ead s u bm i t t i n g .

460 ∗/

private void submitDecryptionValue ( f ina l DecryptBySmallPrime t ) {f ina l NaccacheSternPrivateKeyParameters pr iv = ( NaccacheSternPrivateKeyParameters )

key ;

f ina l Vector smal lPrimes = pr iv . getSmallPrimes ( ) ;

p l a in . setElementAt ( B ig Intege r . valueOf ( t . lookedup ) , smal lPrimes

465 . indexOf ( t . smallPrime ) ) ;

synchronized ( threads ) {threads . remove ( t ) ;

}

470 synchronized ( waitFor ) {waitFor . n o t i f yA l l ( ) ;

}}

475 /∗∗∗ DecryptBySmal lPrime computes t h e p l a i n t e x t modulo a sma l l prime t from

∗ t h e c i p h e r t e x t . With t h e Chinese Remainder Theorem , t h e comp le t e

∗ p l a i n t e x t can be r e s t o r e d .

∗480 ∗ @author l i p p o l d

∗/

class DecryptBySmallPrime extends Thread {private f ina l Big Intege r smallPrime ;

485 private f ina l Big Intege r input ;

private f ina l NaccacheSternPrivateKeyParameters privKey ;

private int lookedup ;

490

private boolean debug ;

DecryptBySmallPrime ( f ina l Big Intege r smallPrime , f ina l Big Intege r input ) {super ( ) ;


495 this . smallPrime = smallPrime ;

this . input = input ;

privKey = ( NaccacheSternPrivateKeyParameters ) key ;

}

500 public void run ( ) {Big Intege r [ ] pq = privKey . getPQ () ;

B ig Intege r exponent = pq [ 0 ] . subt rac t ( B ig Intege r .ONE) ;

exponent = exponent . mult ip ly (pq [ 1 ] . subt rac t ( B ig Intege r .ONE) ) ;

exponent = exponent . d iv ide ( smallPrime ) ;

505 Vector a l = ( Vector ) privKey . getLookupTable ( ) . get ( smallPrime ) ;

lookedup = a l

. indexOf ( Pr imeUti l s . chineseModPow ( input , exponent , pq ) ) ;

i f ( debug ) {System . out . p r i n t l n ( " d e c r y p t i o n for p r i m e " + smallPrime

510 + " f i n i s h e d . " ) ;

}submitDecryptionValue ( this ) ;

}}


A.3 Protocols

Listing A.12: Client generation of N in GilboaClient.java/∗∗

640 ∗ Computes a s ha r i n g f o r a g i v en prime

∗∗ @param prime

∗ t h e prime to use f o r t h e s ha r i n g

∗ @return t r u e i f t h e s ha r i n g i s s u c c e s s f u l , f a l s e i f t h e p r o t o c o l needs to

645 ∗ be r e s t a r t e d .

∗∗ @throws Excep t ion

∗ i f t h e o t h e r pa r t y t a l k s about a d i f f e r e n t prime

∗/

650 private boolean sendSharingModPrime ( f ina l Big Intege r prime )

throws Exception {int po s i t i o n ;

// f i r s t r e t r i e v e t h e c o r r e c t p o s i t i o n o f our prime l i s t s

655 i f ( super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {po s i t i o n = genPrimes . indexOf ( prime ) ;

} else {po s i t i o n = verPrimes . indexOf ( prime ) + genPrimes . s i z e ( ) ;

}660

// g e t t h e c o r r e c t pre−computed Benaloh sys tems

f ina l BenalohEngine pubEngine = (( BenalohSystem ) benalohSystems

. get ( prime ) ) . getPubEngine ( ) ;

f ina l BenalohEngine pr ivEngine = (( BenalohSystem ) benalohSystems

665 . get ( prime ) ) . getPrivEngine ( ) ;

// s e t N mod p i to 0 , t hu s N i s d i v i d e d by p i

int nModPi = 0 ;

B ig Intege r pModPrime ;

670 Big Intege r qModPrime ;

B ig Intege r n ;

// and do the g en e r a t i on o f N u n t i l i t i s no l on g e r d i v i d e d by p i or

// f a i l f i n a l l y and must be newly g ene ra t ed .

675 while ( nModPi == 0) {i f ( super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {

// p and q are not se t , we can adopt as nec e s sa r y

l og . debug (REMOTE IP + " g e n e r a t i n g N mod " + prime ) ;

// g e t new random p and q

680 Big Intege r [ ] pq = generateNewPrimes ( prime ) ;

pModPrime = pq [ 0 ] ;

qModPrime = pq [ 1 ] ;

// s e t them in the l i s t s t h a t are l a t e r used to r e c o n s t r u c t N

// v i a CRT

685 pComposites . s e t ( pos i t i on , pModPrime) ;

qComposites . s e t ( pos i t i on , qModPrime) ;

} else {// p and q are se t , c a l c u l a t e v a l u e s

pModPrime = p .mod( prime ) ;

690 qModPrime = q .mod( prime ) ;

}

// enc ryp t p mod p i and q mod p i

f ina l byte [ ] z1 = pubEngine . processBlock (pModPrime . toByteArray ( ) ,

695 0 , pModPrime . toByteArray ( ) . l ength ) ;

f ina l byte [ ] z2 = pubEngine . processBlock (qModPrime . toByteArray ( ) ,

0 , qModPrime . toByteArray ( ) . l ength ) ;

A.3. PROTOCOLS 73

// w r i t e them to th e s e r v e r

700 out . wr i t e ( Gi lboaProtoco l .CONVERSION MOD PRIME) ;

out . wr i teObject ( prime ) ;

out . wr i t e ( Gi lboaProtoco l .REMOTE Z1) ;

out . wr i t e In t ( z1 . l ength ) ;

705 out . wr i t e ( z1 ) ;

out . wr i t e ( Gi lboaProtoco l .REMOTE Z2) ;

out . wr i t e In t ( z2 . l ength ) ;

out . wr i t e ( z2 ) ;

710

out . f l u s h ( ) ;

n = Big Intege r .ZERO;

// make sure t h a t bo th p a r t i e s are a t t h e same s t e p o f t h e p r o t o c o l

715 i f ( in . read ( ) == Gi lboaProtoco l .COMPUTED N ) {f ina l Big Intege r remPrime = ( Big Intege r ) in . readObject ( ) ;

// check t h a t bo th p a r t i e s ope ra t e on the same prime

i f ( prime . equa l s ( remPrime ) ) {720 // read in th e s e r v e r s computed r e s u l t

f ina l byte [ ] z data = new byte [ in . r eadInt ( ) ] ;

in . readFul ly ( z data ) ;

// and de c r yp t i t

725 n = new Big Intege r ( 1 , pr ivEngine . processBlock ( z data , 0 ,

z data . l ength ) ) ;

// compute t h e f i n a l N mod p i

n = n . add ( ( pModPrime . mult ip ly (qModPrime) ) .mod( prime ) ) ;

730 n = n .mod( prime ) ;

// t e s t whether N != 0

i f ( n . equa l s ( B ig Intege r .ZERO) ) {// N i s z e ro mod prime

735 log . debug (REMOTE IP + " F o u n d t h a t N mod " + prime

+ " is 0 . \ n " ) ;

i f ( super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {// g ene ra t e new sha r e s mod prime , we s t i l l can

// a d j u s t

740 out . wr i t e ( Gi lboaProtoco l . N MOD PRIME IS 0) ;

out . f l u s h ( ) ;

} else {// Tes t ing rsaN f a i l e d .

// Re s t a r t g en e r a t i on .

745 log . i n f o (REMOTE IP + " R e s t a r t i n g g e n e r a t i o n . "

+ " N is d i v i s i b l e by " + prime ) ;

out . wr i t e ( Gi lboaProtoco l .N FAILED) ;

// r e s e t s t a t e machine to c o r r e c t s t a t e

750 super . a c tua lS ta t e = s t a t e s [ 3 ] ;

// and r e s t a r t g en e r a t i on o f N

out

. wr i t e ( Gi lboaProtoco l .START CANDIDATE GENERATION) ;

755 out . f l u s h ( ) ;

// inform c a l l e r about f a i l u r e

return fa l se ;

}760 } else {

// s u c c e s s f u l l y g ene ra t ed N mod prime

nModPi = n . intValue ( ) ;

// s e t i t in t h e l i s t from which N i s recomposed


nModPrimes . s e t ( pos i t i on , n) ;

765 // inform o th e r pa r t y about s u c c e s s

out . wr i t e ( Gi lboaProtoco l .COMPUTED N ) ;

out . f l u s h ( ) ;

}} else {

770 throw new Exception (PROTO VIOL

+ " Not t a l k i n g a b o u t the s a m e p r i m e . " ) ;

}}// f i n a l l y s e t n to t h e a c t u a l v a l u e so t h a t t h e p r o c e s s r e s t a r t s i f

775 // i t i s 0

nModPi = n . intValue ( ) ;

}// i f N != 0 mod prime , r e t u rn t r u e

return true ;

780 }

A.3. PROTOCOLS 75

Listing A.13: Server generation of N in GilboaServer.java/∗∗∗ Computes N ’ = p c ∗ q s + q c ∗ p s + p s ∗ q s mod < t t >prime</t t > . In t h e

650 ∗ Gi lboa paper t h e s e are named z1 , z2 and z3 , N ’ i s named z .

∗∗ @param prime

∗ The prime f o r t h a t N ’ s h a l l be computed

∗ @throws Excep t i on

655 ∗ I f t h e p r o t o c o l i s v i o l a t e d .

∗/

private void computeN ( f ina l Big Intege r prime ) throws Exception {// g e t t h e o t h e r p a r t i e s p u b l i c b ena loh system

f ina l BenalohSystem bs = ( BenalohSystem ) benalohSystems . get ( prime ) ;

660 f ina l BenalohEngine pubEngine = bs . getPubEngine ( ) ;

// read in c l i e n t s p

byte [ ] p c ;

i f ( in . read ( ) == Gi lboaProtoco l .REMOTE Z1) {665 f ina l int s i z e = in . readInt ( ) ;

p c = new byte [ s i z e ] ;

in . readFul ly ( p c ) ;

} else {throw new Exception (PROTO VIOL + " R E M O T E _ Z 1 " ) ;

670 }

// read in c l i e n t s q

byte [ ] q c ;

i f ( in . read ( ) == Gi lboaProtoco l .REMOTE Z2) {675 f ina l int s i z e = in . readInt ( ) ;

q c = new byte [ s i z e ] ;

in . readFul ly ( q c ) ;

} else {throw new Exception (PROTO VIOL + " R E M O T E _ Z 2 " ) ;

680 }

// s e t own s h a r i n g s o f p and q mod prime

Big Intege r pModPrime ;

B ig Intege r qModPrime ;

685 i f ( super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {// wh i l e g e n e r a t i n g p and q

f ina l int pos = genPrimes . indexOf ( prime ) ;

B ig Intege r [ ] pq = generateNewPrimes ( prime ) ;

// s e t p and q in t h e l i s t s used to r e c o n s t r u c t them v i a CRT

690 pComposites . s e t ( pos , pq [ 0 ] ) ;

qComposites . s e t ( pos , pq [ 1 ] ) ;

pModPrime = pq [ 0 ] ;

qModPrime = pq [ 1 ] ;

} else {695 // p and q are f i x e d , s e t c o r r e c t v a l u e

pModPrime = p .mod( prime ) ;

qModPrime = q .mod( prime ) ;

}

700 // e x p on en t i a t e p c w i th pModPrime , t h i s i s e q u i v a l e n t to a p l a i n t e x t

// mu l t i p l i c a t i o n

p c = pubEngine . mult iplyCryptedBlock ( p c , qModPrime) ;

// e x p on en t i a t e q c w i th pModPrime , t h i s i s e q u i v a l e n t to a p l a i n t e x t

// mu l t i p l i c a t i o n

705 q c = pubEngine . mult iplyCryptedBlock ( q c , pModPrime) ;

// Compute p∗q mod prime

f ina l byte [ ] pqModPrime = pModPrime . mult ip ly (qModPrime) .mod( prime )

. toByteArray ( ) ;

710

// enc ryp t i t


byte [ ] n = pubEngine . processBlock (pqModPrime , 0 , pqModPrime . l ength ) ;

// mu l t i p l y a l l c r y p t e d b l o c k s s u c c e s s i v e l y , t h i s i s e q u i v a l e n t to

715 // a d d i t i o n in p l a i n t e x t

n = pubEngine . addCryptedBlocks ( n , q c ) ;

n = pubEngine . addCryptedBlocks ( n , p c ) ;

// inform the c l i e n t about t h e newly computed N ’

720 out . wr i t e ( Gi lboaProtoco l .COMPUTED N ) ;

out . wr i teObject ( prime ) ;

out . w r i t e In t ( n . l ength ) ;

out . wr i t e ( n ) ;

out . f l u s h ( ) ;

725

// check r e s u l t o f comp le t e computat ion

f ina l int command = in . read ( ) ;

i f ( command == Gi lboaProtoco l .COMPUTED N ) {// e v e r y t h i n g went we l l , p∗q mod prime != 0

730 i f ( super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {computedZs . s e t ( genPrimes . indexOf ( prime ) , prime ) ;

}return ;

} else i f ( ( command == Gi lboaProtoco l . N MOD PRIME IS 0)

735 && super . a c tua lS ta t e . equa l s ( s t a t e s [ 4 ] ) ) {// N mod prime i s 0 , needs to be redone

l og . i n f o (REMOTE IP + " Got N _ M O D _ P R I M E _ I S _ 0 for p r i m e " + prime ) ;

} else i f ( command == GilboaProtoco l .N FAILED) {// N f a i l e d f i n a l l y and cannot be a d j u s t e d . Re s t a r t needed

740 log . i n f o (REMOTE IP + " R e s t a r t i n g g e n e r a t i o n , r s a N f a i l e d for "

+ prime ) ;

// r e s e t s t a t e machine to c o r r e c t s t a t e

super . a c tua lS ta t e = s t a t e s [ 3 ] ;

} else {745 // go t p r o t o c o l v i o l a t i o n , e x i t

f ina l St r ing msg = PROTO VIOL + " W r o n g c o m m a n d : " + command ;

log . debug (REMOTE IP + " a c t u a l s t a t e is " + super . a c tua lS ta t e ) ;

l og . f a t a l (REMOTE IP + msg) ;

throw new Exception (msg) ;

750 }}

A.3. PROTOCOLS 77

Listing A.14: Client BiPrime test of N in GilboaClient.java/∗∗∗ Tes t s i f t h e rsaN i s composed o f e x a c t l y two primes . F i r s t , t h e

∗ c and i d a t e s o f bo th p a r t i e s are f i x e d and then the t e s t i s per formed by

380 ∗ us ing t h e cand i da t e t h a t i s t h e sum o f bo th c and i d a t e s .

∗∗ @return True i f t h e t e s t i s s u c c e s s f u l .


∗ I f t h e p r o t o c o l i s v i o l a t e d or t h e p a r t i e s d i s a g r e e about t h e

385 ∗ compos i t ene s s .

∗/

private boolean sendWitness ( ) throws Exception {// Inform the s e r v e r t h a t a BiPrime t e s t s t a r t s

out . wr i t e ( Gi lboaProtoco l .BIPRIME TEST) ;

390 Big Intege r wi tnes s ;

// f i x our h a l f o f t h e cand i da t e

witnes s = PrimeUti l s . getRandom( rsaN , rand ) ;

SHA1Digest sha1 = new SHA1Digest ( ) ;

byte [ ] wData = witnes s . toByteArray ( ) ;

395 sha1 . update (wData , 0 , wData . l ength ) ;

byte [ ] d i g e s t = new byte [ sha1 . g e tD ig e s tS i z e ( ) ] ;

sha1 . doFinal ( d ige s t , 0 ) ;

// and inform s e r v e r about t h e cand i da t e bu t do not r e v e a l i t

out . wr i t e ( Gi lboaProtoco l . SHA1 DIGEST) ;

400 out . wr i t e ( d i g e s t . l ength ) ;

out . wr i t e ( d i g e s t ) ;

out . f l u s h ( ) ;

// read th e s e r v e r s cand i da t e

i f ( in . read ( ) == Gi lboaProtoco l . SHA1 DIGEST) {405 byte [ ] remoteDigest = new byte [ in . read ( ) ] ;

in . readFul ly ( remoteDigest ) ;

// r e v e a l our cand i da t e

out . wr i teObject ( wi tnes s ) ;

out . f l u s h ( ) ;

410 // read th e remote cand i da t e and v e r i f y i t

Big Intege r remCand = ( Big Intege r ) in . readObject ( ) ;

wData = remCand . toByteArray ( ) ;

sha1 . r e s e t ( ) ;

sha1 . update (wData , 0 , wData . l ength ) ;

415 sha1 . doFinal ( d ige s t , 0 ) ;

i f ( (new Big Intege r ( 1 , remoteDigest ) ) . equa l s (new Big Intege r (1 ,

d i g e s t ) ) ) {// compose t h e f i n a l c and i da t e o f bo th s h a r i n g s

witnes s = witnes s . add ( remCand) ;

420 while ( Pr imeUti l s . jacobiSymbol ( witness , rsaN ) != 1) {witnes s = witnes s . add ( Big Intege r .ONE) ;

}} else {

St r ing msg = REMOTE IP + PROTO VIOL + " SHA -1 d i g e s t "

425 + " of t r a n s f e r r e d o b j e c t is not c o r r e c t " ;

l og . f a t a l (msg) ;


}} else {

430 St r ing msg = REMOTE IP + PROTO VIOL + " e x p e c t e d S H A 1 _ D I G E S T " ;



}

435 // Do the s imp l e t e s t t h a t c a t c h e s a lmos t a l l

f ina l Big Intege r myExp = ((p . add (q ) ) . negate ( ) ) . d i v ide ( four ) ;

B ig Intege r jWitness = witnes s .modPow(myExp , rsaN ) ;

jWitness = jWitness .mod( rsaN ) ;

// l o g . debug (REMOTE IP + ” Sending Witness ” + w i t n e s s ) ;

440 out . wr i t e ( Gi lboaProtoco l .WITNESS) ;



out . wr i teObject ( jWitness ) ;

out . f l u s h ( ) ;

B ig Intege r remWitness ;

445 i f ( in . read ( ) == Gi lboaProtoco l .WITNESS) {remWitness = ( Big Intege r ) in . readObject ( ) ;

} else {f ina l St r ing msg = PROTO VIOL + " e x p e c t i n g W I T N E S S " ;


450 throw new Exception (msg) ;

}jWitness = remWitness . mult ip ly ( jWitness ) ;


int r e t v a l = in . read ( ) ;

455 i f ( ( jWitness . equa l s ( B ig Intege r .ONE) | | jWitness . equa l s ( rsaN

. subt rac t ( B ig Intege r .ONE) ) )

&& ( r e t v a l == Gi lboaProtoco l .N VERIFIED) ) {

// I f i t succeeded , do a f i n a l t e s t in t h e t w i s t e d group

460

// F i r s t f i x our share o f t h e t w i s t e d cand i da t e

Big Intege r [ ] twWitness = PrimeUti l s . getRandomTwistedElement ( rsaN ,

rand ) ;

sha1 . r e s e t ( ) ;

465 wData = twWitness [ 0 ] . toByteArray ( ) ;


wData = twWitness [ 1 ] . toByteArray ( ) ;



470

// and inform the s e r v e r about i t


out . wr i t e ( d i g e s t . l ength ) ;

475 out . wr i t e ( d i g e s t ) ;

out . f l u s h ( ) ;

// read th e s e r v e r s hash va l u e

i f ( in . read ( ) == Gi lboaProtoco l . SHA1 DIGEST) {480 byte [ ] remoteDigest = new byte [ in . read ( ) ] ;


// and r e v e a l our e l ement

out . wr i teObject ( twWitness [ 0 ] ) ;

485 out . wr i teObject ( twWitness [ 1 ] ) ;

out . f l u s h ( ) ;

// read th e s e r v e r s e l ement

Big Intege r [ ] remCand = new Big Intege r [ 2 ] ;

490 remCand [ 0 ] = ( Big Intege r ) in . readObject ( ) ;

remCand [ 1 ] = ( Big Intege r ) in . readObject ( ) ;

// and v e r i f y i t

wData = remCand [ 0 ] . toByteArray ( ) ;

495 sha1 . r e s e t ( ) ;


wData = remCand [ 1 ] . toByteArray ( ) ;



500 i f ( (new Big Intege r ( 1 , remoteDigest ) ) . equa l s (new Big Intege r (1 ,

d i g e s t ) ) ) {

// I f a l l i s c o r r e c t , f i x t h e f i n a l e l ement

twWitness = PrimeUti l s . twistedAdd ( twWitness , remCand) ;

505

A.3. PROTOCOLS 79

} else {St r ing msg = REMOTE IP + PROTO VIOL + " SHA -1 d i g e s t "

+ " of t r a n s f e r r e d o b j e c t is not c o r r e c t " ;



}} else {

St r ing msg = REMOTE IP + PROTO VIOL + " e x p e c t e d S H A 1 _ D I G E S T " ;



}

// Do the c l i e n t s pa r t o f t h e t e s t in t h e t w i s t e d group

Big Intege r [ ] jTwWitness = PrimeUti l s . twistedModPow ( twWitness , p

520 . add (q ) , rsaN ) ;

// and inform the s e r v e r about i t

out . wr i t e ( Gi lboaProtoco l .TW WITNESS) ;



525 out . wr i teObject ( jTwWitness [ 0 ] ) ;

out . wr i teObject ( jTwWitness [ 1 ] ) ;

out . f l u s h ( ) ;

// Read the s e r v e r s r e s u l t s

530 f ina l Big Intege r [ ] remTwWitness = new Big Intege r [ 2 ] ;

i f ( in . read ( ) == Gi lboaProtoco l .TW WITNESS) {remTwWitness [ 0 ] = ( Big Intege r ) in . readObject ( ) ;

remTwWitness [ 1 ] = ( Big Intege r ) in . readObject ( ) ;

}535

// and combine t h e r e s u l t s t o g e t t h e f i n a l r e s u l t

jTwWitness = PrimeUti l s . twistedModMult ( remTwWitness , jTwWitness ,

rsaN ) ;

540 r e t v a l = in . read ( ) ;

i f ( jTwWitness [ 1 ] . equa l s ( B ig Intege r .ZERO) ) {i f ( r e t v a l == Gi lboaProtoco l .N VERIFIED) {

// i f bo th p a r t i e s are sure t h a t rsaN i s prime f o r t h i s

// cand ida te , r e t u rn t r u e to t h e c a l l i n g f un c t i o n

545 log . i n f o (REMOTE IP + " For w i t n e s s " + witnes s

+ " , the r s a N p a s s e s the t e s t " ) ;

out . wr i t e ( Gi lboaProtoco l .N VERIFIED) ;

out . f l u s h ( ) ;

return true ;

550 } else {// Throw e x c e p t i o n on d i sag reement and e x i t

f ina l St r ing msg = " O t h e r s i d e t h i n k s t h a t " + rsaN

+ " is not prime , but I do " ;



}} else {

i f ( r e t v a l == Gi lboaProtoco l .N FAILED) {

560 // E l s e r e t u rn f a l s e i f bo th p a r t i e s agree t h a t rsaN i s not

// composed o f e x a c t l y two primes .

l og . i n f o (REMOTE IP + " N f a i l e d B i P r i m a l i t y t e s t " ) ;

return fa l se ;

} else {565 // Throw e x c e p t i o n on d i sag reement and e x i t


+ " is prime , but I don ’ t " ;



570 }


}} else {

// Return f a l s e i f t h e f i r s t t e s t f a i l e d a l r e a d y

l og . i n f o ( " RSA N f a i l e d f i r s t B i P r i m a l i t y t e s t . R e s t a r t i n g . " ) ;

575 return fa l se ;

}}

A.3. PROTOCOLS 81

Listing A.15: Server BiPrime test of N in GilboaServer.java/∗∗∗ Does a biPrime t e s t f o r t h e RSA N. N o t i f i e s t h e c l i e n t o f t h e r e s u l t and

∗ r e s e t s t h e s e r v e r i f an i n v a l i d rsaN i s d e t e c t e d .

∗340 ∗ @throws Excep t i on

∗ I f t h e p r o t o c o l i s not f o l l o w e d c o r r e c t l y .

∗∗/

private void doBiPrimeTest ( ) throws Exception {345 Big Intege r wi tnes s ;

// F i r s t , f i x t h e s ha r e s o f bo th p a r t i e s w i t hou t r e v e a l i n g them

i f ( in . read ( ) == Gi lboaProtoco l . SHA1 DIGEST) {// Read in th e o t h e r s i d e ’ s sha−1 d i g e s t

350 byte [ ] remoteDigest = new byte [ in . read ( ) ] ;


// Compute our own w i t n e s s pa r t

witnes s = PrimeUti l s . getRandom( rsaN , rand ) ;

355

// and inform the o t h e r pa r t y about i t w i t h ou t r e v e a l i n g i t

byte [ ] wData = witnes s . toByteArray ( ) ;



360 byte [ ] d i g e s t = new byte [ sha1 . g e tD ig e s tS i z e ( ) ] ;



out . wr i t e ( d i g e s t . l ength ) ;


365 out . f l u s h ( ) ;

// Read the o t h e r p a r t i e s cand i da t e and v e r i f y i t

Big Intege r remCand = ( Big Intege r ) in . readObject ( ) ;

wData = remCand . toByteArray ( ) ;

370 sha1 . r e s e t ( ) ;



i f ( (new Big Intege r ( 1 , remoteDigest ) ) . equa l s (new Big Intege r (1 ,

d i g e s t ) ) ) {375

// i f i t i s c o r r e c t , send our own cand i da t e


out . f l u s h ( ) ;

380 // and add bo th c and i d a t e s to g e t t h e f i n a l c and i da t e

witnes s = witnes s . add ( remCand) ;

// f i n d th e nex t needed va l u e

while ( Pr imeUti l s . jacobiSymbol ( witness , rsaN ) != 1) {385 witnes s = witnes s . add ( Big Intege r .ONE) ;

}} else {

St r ing msg = REMOTE IP + PROTO VIOL + " SHA -1 d i g e s t "


390 log . f a t a l (msg) ;


}} else {




}

// Then do a s imp l e t e s t . I f t h i s t e s t f a i l s a l r eady , we do not have to


400 // t e s t in t h e t w i s t e d group

i f ( in . read ( ) == Gi lboaProtoco l .WITNESS) {

// v e r i f y t h a t t h e o t h e r pa r t y found the same w i t n e s s

Big Intege r compWitness = ( Big Intege r ) in . readObject ( ) ;

405 i f ( compWitness . equa l s ( w i tnes s ) ) {

// read th e o t h e r p a r t i e s r e s u l t

f ina l Big Intege r remResult = ( Big Intege r ) in . readObject ( ) ;

// compute our own r e s u l t

410 Big Intege r jWitness = witnes s .modPow( ( rsaN . subt rac t (p)

. subt rac t (q ) . add ( Big Intege r .ONE) ) . d iv ide ( B ig Intege r

. valueOf (4) ) , rsaN ) ;


// and inform the c l i e n t about our pa r t

415 out . wr i t e ( Gi lboaProtoco l .WITNESS) ;

out . wr i teObject ( jWitness ) ;

out . f l u s h ( ) ;

// compute t h e f i n a l r e s u l t

420 jWitness = jWitness . mult ip ly ( remResult ) ;


i f ( jWitness . equa l s ( B ig Intege r .ONE)

| | jWitness . equa l s ( rsaN . subt rac t ( B ig Intege r .ONE) ) ) {// i f s u c c e s s f u l in form the c l i e n t

425 out . wr i t e ( Gi lboaProtoco l .N VERIFIED) ;

out . f l u s h ( ) ;

} else {// i f u n s u c c e s s f u l in form c l i e n t

l og . i n f o (REMOTE IP + " F o u n d w i t n e s s t h a t r s a N "

430 + " is not a p r o d u c t of two p r i m e s . " ) ;


out . f l u s h ( ) ;

// and r e s e t s t a t e machine so t h a t a new N must be g ene ra t ed

435 super . a c tua lS ta t e = s t a t e s [ 3 ] ;

pr imeTries . c l e a r ( ) ;

return ;

}} else {

440 St r ing msg = REMOTE IP + PROTO VIOL

+ " Not u s i n g the s a m e w i t n e s s " ;



}445 }

// The p r e v i o u s t e s t was s u c c e s s f u l . Now do a t e s t in t h e t w i s t e d group .

Big Intege r twWitness [ ] = PrimeUti l s . getRandomTwistedElement ( rsaN , rand ) ;

450 i f ( in . read ( ) == Gi lboaProtoco l . SHA1 DIGEST) {// read th e sha−1 d i g e s t o f t h e c l i e n t ’ s c and i da t e

byte [ ] remoteDigest = new byte [ in . read ( ) ] ;


// compute our own d i g e s t

455 byte [ ] wData = twWitness [ 0 ] . toByteArray ( ) ;



wData = twWitness [ 1 ] . toByteArray ( ) ;


460 byte [ ] d i g e s t = new byte [ sha1 . g e tD ig e s tS i z e ( ) ] ;


// and inform the c l i e n t about i t


A.3. PROTOCOLS 83

465 out . wr i t e ( d i g e s t . l ength ) ;


out . f l u s h ( ) ;

// read in th e c l i e n t ’ s c and i da t e

470 Big Intege r remWitness [ ] = new Big Intege r [ 2 ] ;

remWitness [ 0 ] = ( Big Intege r ) in . readObject ( ) ;


// and v e r i f y i t s d i g e s t

sha1 . r e s e t ( ) ;

475 wData = remWitness [ 0 ] . toByteArray ( ) ;


wData = remWitness [ 1 ] . toByteArray ( ) ;



480 i f ( (new Big Intege r ( 1 , remoteDigest ) ) . equa l s (new Big Intege r (1 ,

d i g e s t ) ) ) {// i f d i g e s t i s c o r r e c t , r e v e a l our cand i da t e



485 out . f l u s h ( ) ;

// and compute f i n a l composed cand i da t e

twWitness = PrimeUti l s . twistedAdd ( remWitness , twWitness ) ;

} else {// e l s e a bo r t computat ion

490 St r ing msg = REMOTE IP + PROTO VIOL + " SHA -1 d i g e s t "




}495 } else {




}500

// read th e c l i e n t ’ s composed cand i da t e

f ina l Big Intege r remTwWitnessResult [ ] = new Big Intege r [ 2 ] ;

i f ( in . read ( ) == Gi lboaProtoco l .TW WITNESS) {f ina l Big Intege r remWitness [ ] = new Big Intege r [ 2 ] ;

505 remWitness [ 0 ] = ( Big Intege r ) in . readObject ( ) ;


i f ( ! remWitness [ 0 ] . equa l s ( twWitness [ 0 ] )

| | ! remWitness [ 1 ] . equa l s ( twWitness [ 1 ] ) ) {// i f t h ey are not equa l , t h e o t h e r s i d e i s chea t ing , e x i t

510 throw new Exception ( " w i t n e s s e s not e q u a l " ) ;

}// read th e c l i e n t ’ s pa r t o f t h e t e s t

remTwWitnessResult [ 0 ] = ( Big Intege r ) in . readObject ( ) ;

remTwWitnessResult [ 1 ] = ( Big Intege r ) in . readObject ( ) ;

515 } else {f ina l St r ing msg = PROTO VIOL + " e x p e c t i n g T W _ W I T N E S S " ;



}520

// compute our pa r t o f t h e t e s t

Big Intege r [ ] jTwWitness = PrimeUti l s . twistedModPow ( twWitness , rsaN . add (

p) . add (q ) . add ( Big Intege r .ONE) , rsaN ) ;

// and inform the c l i e n t about i t

525 out . wr i t e ( Gi lboaProtoco l .TW WITNESS) ;



out . f l u s h ( ) ;


530 // compute t h e f i n a l outcome

jTwWitness = PrimeUti l s . twistedModMult ( jTwWitness , remTwWitnessResult ,

rsaN ) ;

i f ( jTwWitness [ 1 ] . equa l s ( B ig Intege r .ZERO) ) {535 // i f s u c c e s s f u l , in form the c l i e n t

l og . i n f o (REMOTE IP + " For w i t n e s s " + witnes s

+ " , the r s a N p a s s e s the t e s t " ) ;

out . wr i t e ( Gi lboaProtoco l .N VERIFIED) ;

out . f l u s h ( ) ;

540 // h o p e f u l l y i t t h i n k s t h e same ; )

i f ( in . read ( ) == Gi lboaProtoco l .N VERIFIED) {l og . i n f o (REMOTE IP + " RSA n v e r i f i e d for " + witnes s ) ;

// Record th e s u c c e s s f u l t e s t in our s t a t i s t i c s , so we can

// v e r i f y l a t e r t h a t we d id enough t e s t s

545 pr imeTries . add ( wi tnes s ) ;

} else {// i f p a r t i e s d i s a g r e e , e x i t


+ " is not prime , but I do " ;

550 log . f a t a l (REMOTE IP + msg) ;


}} else {

// i f un su c c e s s f u l , a l s o inform the c l i e n t

555 log . i n f o (REMOTE IP + " F o u n d w i t n e s s "

+ " t h a t r s a N is not a p r o d u c t of two p r i m e s . " ) ;


out . f l u s h ( ) ;

560 // and r e s e t s t a t e machine

super . a c tua lS ta t e = s t a t e s [ 3 ] ;

pr imeTries . c l e a r ( ) ;

}}

565

A.3. PROTOCOLS 85

Listing A.16: Oblivious Transfer for Party B in ComputeKeyClient.java/∗∗

255 ∗ Prepares t h e RSA key pa i r needed to perform a o b l i v i o u s t r a n s f e r and

∗ sends i t t o t h e o t h e r pa r t y

∗∗ @throws Excep t i on

∗ I f o b l i v i o u s t r a n s f e r s cou l d not be prepared c o r r e c t l y .

260 ∗∗/

private void setupOblTrans fers ( f ina l Big Intege r r ing ) throws Exception {out . wr i t e ( KeyProtocol .OBLIVIOUS SETUP) ;

l og . debug ( " S e t t i n g up o b l i v i o u s t r a n s f e r s " + " for d e s i r e d e x p o n e n t " ) ;

265 log . i n f o ( " G e n e r a t i n g RSA key p a i r in r i n g " + r ing

+ " for o b l i v i o u s t r a n s f e r s " ) ;

// Do not g i v e pubExp too few 1− b i t s t o avo id SideChanne l A t t a ck s

Big Intege r pubExp ;

270 do {pubExp = new Big Intege r ( r ing . bitLength ( ) , rand ) ;

i f ( pubExp . isProbablePrime ( c e r t a i n t y ) ) {break ;

}275 } while ( true ) ;

// Cons t ruc t t h e RSA key t h a t has s i z e o f t h e r i n g

f ina l RSAKeyGenerationParameters param = new RSAKeyGenerationParameters (

pubExp , rand , r ing . bitLength ( ) , c e r t a i n t y ) ;

280 f ina l RSAKeyPairGenerator generator = new RSAKeyPairGenerator ( ) ;

generator . i n i t ( param) ;

f ina l AsymmetricCipherKeyPair pa i r = generator . generateKeyPair ( ) ;

f ina l RSAKeyParameters oblPubKey = (RSAKeyParameters ) pa i r . ge tPub l i c ( ) ;

key = ( RSAPrivateCrtKeyParameters ) pa i r . g e tPr iva te ( ) ;

285

// Write t h e data needed f o r t h e o b l i v i o u s t r a n s f e r to t h e s e r v e r

out . wr i t e ( KeyProtocol .OBL RING) ;

out . wr i teObject ( r ing ) ;

out . wr i t e ( KeyProtocol .OBL MODULUS) ;

290 out . wr i teObject ( oblPubKey . getModulus ( ) ) ;

out . wr i t e ( KeyProtocol .OBL EXP) ;

out . wr i teObject ( oblPubKey . getExponent ( ) ) ;

out . f l u s h ( ) ;

295 // v e r i f y t h a t a l l went w e l l

i f ( in . read ( ) == KeyProtocol .OBLIVIOUS SETUP) {return ;

} else {St r ing msg = REMOTE IP + PROTO VIOL + " e x p e c t i n g O B L I V I O U S _ S E T U P " ;



}}

305 /∗∗∗ Does i 2−1 o b l i v i o u s t r a n s f e r s to enab l e t h e o t h e r s i d e to l e a rn th e

∗ needed b i t s o f my va l u e and r e t u rn s my share o f t h e computat ion .

∗∗ @param myValue

310 ∗ t h e e l ement to t r a n s f e r


∗ i f someth ing goes wrong

∗/

private Big Intege r s t a r tOb l i v i ou sTran s f e r ( f ina l Big Intege r r ing ,

315 f ina l Big Intege r value ) throws Exception {l og . debug ( " s t a r t i n g O b l i v i o u s T r a n s f e r " ) ;


// make sure t h a t v a l u e i s an e lement o f t h e r i n g

f ina l Big Intege r myValue = value .mod( r ing ) ;

320

// i n i t i a l i z e y , which w i l l h o l d t h e sum o f our m0

Big Intege r y = Big Intege r .ZERO;

// s t a r t t h e t r a n s f e r

325 out . wr i t e ( KeyProtocol .OBL START) ;

out . f l u s h ( ) ;

// v e r i f y o t h e r s i d e i s ready

i f ( in . read ( ) != KeyProtocol .OBL START) {330 f ina l St r ing msg = REMOTE IP + PROTO VIOL + " E x p e c t i n g O B L _ S T A R T " ;



}

335 // do r i n g . b i t L en g t h ( ) o b l i v i o u s t r a n s f e r s to conve r t an e lement

for ( int i = 0 ; i < r ing . bitLength ( ) ; i++) {

// inform s e r v e r t h a t an o b l . t r a n s f e r i s coming

out . wr i t e ( KeyProtocol .OBL TRANSFER) ;

340

// prepare two random messages x0 and x1

f ina l Big Intege r x0 = PrimeUti l s . getRandom( ring , rand ) ;

f ina l Big Intege r x1 = PrimeUti l s . getRandom( ring , rand ) ;

345 // and wr i t e them to th e s e r v e r

out . wr i t e ( KeyProtocol .OBL X0) ;

out . wr i teObject ( x0 ) ;

out . wr i t e ( KeyProtocol .OBL X1) ;

out . wr i teObject ( x1 ) ;

350 out . f l u s h ( ) ;

// s e r v e r choose s one and adds h i s enc ryp t ed k . We read i t

i f ( in . read ( ) == KeyProtocol .OBL KX) {f ina l Big Intege r kx = ( Big Intege r ) in . readObject ( ) ;

355

// and compute t h e two p o s s i b l e r e s u l t s

f ina l Big Intege r k0 = rsaDecrypt ( kx . subt rac t ( x0 ) ) ;

f ina l Big Intege r k1 = rsaDecrypt ( kx . subt rac t ( x1 ) ) ;

360 // prepare our messages m 0 ( random ) and m 1 = 2ˆ i ∗ m 0

f ina l Big Intege r m0 = PrimeUti l s . getRandom( ring , rand ) ;

B ig Intege r m1 = Big Intege r . valueOf (2) . pow( i ) . mult ip ly (myValue ) ;

m1 = m1. add (m0) .mod( r ing ) ;

y = y . add (m0) .mod( r ing ) ;

365

// add them to th e two p o s s i b l e d e c r y p t i o n s and send each to t h e

// s e r v e r

out . wr i t e ( KeyProtocol .OBL M0K0) ;

out . wr i teObject ( k0 . add (m0) ) ;

370 out . wr i t e ( KeyProtocol .OBL M1K1) ;

out . wr i teObject ( k1 . add (m1) ) ;

out . f l u s h ( ) ;

// s e r v e r choose s c o r r e c t one , one t r a n s f e r i s f i n i s h e d

375 } else {f ina l St r ing msg = REMOTE IP + PROTO VIOL + " E x p e c t i n g O B L _ K X " ;



}380 }

// f i n a l l y , nega t e our sum

y = y . negate ( ) ;

A.3. PROTOCOLS 87

// and make sure t h a t i t i s a r i n g e l ement ( t h e sum may be l a r g e r than the r i n g )

y = y .mod( r ing ) ;

385 log . debug ( " O b l i v i o u s T r a n s f e r f i n i s h e d " ) ;

return y ;

}


Listing A.17: Oblivious Transfer for Party A in ComputeKeyServer.java/∗∗∗ Does a Ob l i v i o u s Trans fe r f o r one b i t o f < t t >va lue </t t >. In each

∗ t r a n s f e r t h e b i t i s i n c r e a s e d by one , so t h a t in t h e end a l l b i t s have

440 ∗ been t r a n s f e r r e d .

∗∗ @throws Excep t ion

∗ I f e i t h e r t h e p r o t o c o l i s v i o l a t e d or t h e connec t i on i s

∗ c l o s e d .

445 ∗∗/

private void ob l i v i ou sTran s f e r ( f ina l Big Intege r r ing , f ina l Big Intege r value )

throws Exception {// make sure t h a t v a l u e i s in Z N

450 f ina l Big Intege r myValue = value .mod( r ing ) ;

a c tua lB i t++;

log . debug ( " Now e x e c u t i n g bit " + actua lB i t + " / " + r ing . bitLength ( ) ) ;

// c on s t r u c t p r i v a t e e l ement

Big Intege r k = PrimeUti l s . getRandom( ring , rand ) ;

455

// and make sure t h a t i t can be enc ryp t ed

k = k .mod( oblModulus ) ;

// and enc ryp t i t

Big Intege r kx = k .modPow( oblExp , oblModulus ) ;

460

// read th e o t h e r p a r t i e s preapared messages

Big Intege r m0;

B ig Intege r m1;

i f ( in . read ( ) == KeyProtocol .OBL X0) {465 m0 = ( Big Intege r ) in . readObject ( ) ;

} else {f ina l St r ing msg = PROTO VIOL + REMOTE IP + " E x p e c t i n g O B L _ X 0 " ;



470 }i f ( in . read ( ) == KeyProtocol .OBL X1) {

m1 = ( Big Intege r ) in . readObject ( ) ;

} else {f ina l St r ing msg = PROTO VIOL + REMOTE IP + " E x p e c t i n g O B L _ X 1 " ;



}

// and add the c o r r e c t message to my encryp t ed va l u e

480 i f ( myValue . t e s tB i t ( ac tua lB i t ) ) {kx = kx . add (m1) ;

} else {kx = kx . add (m0) ;

}485

// w r i t e t h e sum to th e o t h e r pa r t y

out . wr i t e ( KeyProtocol .OBL KX) ;

out . wr i teObject ( kx ) ;

out . f l u s h ( ) ;

490

// and read th e answers

Big Intege r m0k0 ;

B ig Intege r m1k1 ;

i f ( in . read ( ) == KeyProtocol .OBL M0K0) {495 m0k0 = ( Big Intege r ) in . readObject ( ) ;

} else {f ina l St r ing msg = PROTO VIOL + REMOTE IP + " E x p e c t i n g O B L _ M 0 K 0 " ;



500 }

A.3. PROTOCOLS 89

i f ( in . read ( ) == KeyProtocol .OBL M1K1) {m1k1 = ( Big Intege r ) in . readObject ( ) ;

} else {f ina l St r ing msg = PROTO VIOL + REMOTE IP + " E x p e c t i n g O B L _ M 1 K 1 " ;



}

// choose t h e c o r r e c t answer

510 Big Intege r m;

i f ( myValue . t e s tB i t ( ac tua lB i t ) ) {m = m1k1 . subt rac t (k ) ;

} else {m = m0k0 . subt rac t (k ) ;

515 }

// and record i t f o r l a t e r a d d i t i o n w i th o t h e r e l emen t s

oblMessages . s e t ( actua lBi t , m) ;

}

Date post:	22-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Distributed RSA Key Generation - SourceForgedistrib-rsa.sourceforge.net/dipl_lippold.pdf · Boneh...

Documents