Shared Generation of Shared RSA Keys 1. Simon Blake-Wilson 3. Certicom Corp. Steven Galbraith.

Transcription

1 Shared Generation of Shared RSA Keys 1 Simon Blackburn 2 Royal Holloway simonb@dcs.rhbnc.ac.uk Simon Blake-Wilson 3 Certicom Corp. sblakewi@certicom.com Steven Galbraith Royal Holloway stevenga@dcs.rhbnc.ac.uk Mike Burmester Royal Holloway m.burmester@rhbnc.ac.uk February 16, Technical report CORR 98-19, Dept. of C&O, University of Waterloo, Canada. 2 The author is supported by an EPSRC Advanced Fellowship. 3 Research performed as an EPSRC CASE student at Royal Holloway sponsored by Racal Airtech.

2 Abstract The paper considers the problem of distributed key generation for shared-control RSA schemes. In particular: how can two parties generate a shared RSA key in such a way that neither party can cheat? The answer to this question would have signicant applications to, for example, key escrow systems. Cocks has recently proposed protocols to solve this problem in the case when both parties act honestly. However, we show that the Cocks protocols [6] are insecure if a dishonest party actively deviates from the protocol. A new protocol which resists these active attacks is proposed. Keywords: active attack, distributed key generation, RSA.

3 Shared Generation of Shared RSA Keys 1 1 Introduction This paper considers the following problem: how can two parties generate a shared RSA key pair? The generation method should preclude either party individually from compromising the key pair. Our aim is to provide an ecient two-party shared RSA key generation protocol to solve this problem. Shared key generation protocols are relevant to the theory of secret sharing (see Shamir [20]) and threshold cryptography (see Desmedt [9]). For the protocols we consider, the primary application we envisage is key escrow, although a number of other applications, for example parameter generation for Fiat-Shamir signatures [10], also spring to mind. As an illustration of the potential application, suppose users of a system are required to escrow session keys for possible retrieval later by a duly authorised entity (see Micali [17]). Each time a session using key begins, the users deposit encrypted under the public RSA escrow key (N; e) as: e mod N : The key generation protocols we discuss can be used by two escrow agents to generate shares of this highly sensitive escrow key. Now users do not have to trust the integrity of any one third party to ensure protection. The agents can use their shares to carry out threshold decryption and retrieve session keys, and no dealer is required to supply the shares. In theory, generic protocol constructions, such as those described by Yao [22] and Goldreich et al. [15], prove the existence of secure shared key generation protocols; however they do not provide protocols which are ecient enough for most applications. In practice, ecient shared key generation protocols for cryptosystems based on the discrete logarithm problem are relatively plentiful: proposals can be found in Cerecedo et al. [3], Gennaro et al. [12], and Park and Kurosawa [18]. However, ecient shared generation of RSA keys appears a considerably harder problem, and the need for proposals has been noted by Bellare and Goldwasser [1] and Gennaro et al. [13]. Recently Boneh and Franklin [2] and Cocks [6] have independently suggested protocols to address this deciency. Both these papers concentrate on the case in which parties only cheat `passively', and do not actively deviate from the protocol. Cocks' protocols enable two parties to generate a shared key as we require. (Cocks [7] has recently extended his protocols to three or more parties.) Boneh and Franklin's protocols enable k 3 parties to generate a shared key in such a way that no t < k parties can cheat `passively'. 2 However we believe that a more realistic threat model must take into account the possibility that dishonest parties `actively' cheat during the protocol. In this paper, we investigate the possibility of providing secure two-party shared RSA key generation protocols in this enriched threat model which takes into account the ability of dishonest parties to deviate from the protocol. First we present attacks on the Cocks protocols which

4 Shared Generation of Shared RSA Keys 2 show that they are susceptible to these active attacks. Secondly we present a new protocol based on the Cocks protocols which is designed to resist active attacks. Based on Cocks' estimates, our protocol will take a few days to generate a shared 1024-bit modulus on a fast machine. This is ecient enough for some applications. The paper proceeds as follows. In Section 2 a formal denition of protocol security in the presence of a malicious adversary who actively attacks the protocol is provided. Sections 3 and 4 investigate the Cocks protocols: rst we summarise the protocols themselves and then we present some attacks. In Sections 5 and 6 our new protocol is described. Section 7 contains an heuristic justication of the security of our proposal, and Section 8 discusses how it may be implemented in practice. Finally Section 9 draws some conclusions and presents some open problems. 2 Security Model In this section we introduce our communication model and supply denitions of a secure twoparty shared key generation protocol for RSA. Formal denitions are made and accompanied by an informal discussion. The formal statements enable precise analysis, while (hopefully) the discussion gives the reader a avour of the problem. The technical denitions may be skipped by a reader uninterested in formalities; note that we will be providing only heuristic arguments that our proposal is secure, not a formal proof. Communication Model. The environment envisaged is composed of two players, Alice and Bob, who communicate over a reliable but non-secret channel on which messages are relayed in an orderly and authentic fashion. The assumption that Alice and Bob communicate in such a reliable fashion allows us to focus on a high-level description of the key generation protocols. Note, however, that in practice such a channel can be provided either by physical means or by cryptographic means. Alice and Bob only engage in one execution of the protocol at a time. We will formally model this scenario by regarding Alice and Bob as linked interactive Turing machines. See, for example, Goldreich [14] for a denition and discussion of interactive Turing machines. The Adversary. We assume that an adversary, F, can corrupt one of the players. Two kinds of adversary are distinguished: an eavesdropping adversary learns all the information stored and communicated by the corrupted player. a malicious adversary is an eavesdropping adversary who may also cause the corrupted player to divert from the specied protocol in any way. This paper is specically concerned with the kind of active attacks that a malicious adversary is able to launch.

5 Shared Generation of Shared RSA Keys 3 F is modeled as a probabilistic polynomial time Turing machine. The restriction throughout this section to asymptotic concepts like polynomial time and negligible probability is, as always, a device which aids formalization: in reality we are interested in a specic security level and the corresponding concrete notions of work factor and success probability. In any particular execution of the protocol, we will denote Alice by A if she certainly adheres to the description of the protocol, and by A otherwise. Similarly, Bob will be denoted by B or B. Thus an eavesdropping adversary who corrupts Alice can be thought of as one who runs the linked Turing machines (A; B) and witnesses A during this interaction, while a malicious adversary chooses A and runs (A ; B), witnessing A 's actions. Key Generation. Intuitively we require a two-party shared RSA key generation protocol to provide two honest users with shares of an RSA key pair. In this paper, a key pair consisting of ((N; e); d) will always be shared as ((N; e); d a ) and ((N; e); d b ) with d a + d b = d. Sharing the key in this way enables, for example, threshold decryption (see Cocks [6]). In order to formally dene a shared key generation procedure, we need rst to dene what we mean by saying that the RSA problem [19] is hard. Denition 1 The RSA problem is dened by a probabilistic polynomial time key generation algorithm G RSA. On input 1 k, G RSA generates RSA key pairs ((N; e); d) consisting of an integer N, an integer e 2 (Z=(N)Z), and an integer d 2 (Z=(N)Z) satisfying ed = 1 mod (N). The RSA problem is hard for G RSA if, for all probabilistic polynomial time Turing machines E (polynomial time in the rst input): Pr[((N; e); d) G RSA (1 k ); y (Z=NZ) ; E(1 k ; (N; e); y) = x : x e = y mod N] is negligible. Here k is the security parameter. The probability in the above denition is assessed over the coin tosses of G RSA and E, and over the random choice of y. All the above denition says is that the RSA problem is hard for a particular key generator if no-one has a very good chance of inverting the function dened by: f(x) = x e mod N for an N and e chosen by the key generator and a random choice of x. The formal denition of a two-party shared RSA key generator is now straightforward: it consists simply of the description of a pair of linked interactive Turing machines which output a valid RSA key pair and which together can be used in place of an ordinary RSA key generator. For simplicity we will call a pair of linked interactive Turing machines polynomial time if the total number of steps taken by both machines is polynomial. Denition 2 A two-party shared RSA key generation protocol is a polynomial time pair of linked interactive Turing machines (A; B) satisfying:

6 Shared Generation of Shared RSA Keys 4 1. On common input 1 k, (A; B) outputs some ((N; e); d a ; d b ) such that ((N; e); (d a + d b )) is a valid RSA key pair. Here (N; e) is the public output of A and B, d a is the private output of A, d b is the private output of B. 2. The RSA problem is hard for the key generator G RSA dened as follows. On input 1 k, G RSA calls (A; B) on input 1 k and outputs the key pair ((N; e); (d a + d b )) generated by (A; B). Dening the security of a shared RSA key generation protocol is a more delicate problem. It would be nice to say that even in the presence of a malicious adversary, the generator G RSA dened in Denition 2 is a secure key generator for RSA. However this is not possible: note that a malicious adversary can certainly always halt the shared key generation protocol so that a shared key is never produced. Instead, it is necessary to consider a more general adversary who rst takes part in the key generation protocol and then tries to solve the RSA problem for any resulting key pair. Formally a (malicious) adversary F a = (A ; E) which corrupts Alice consists of two Turing machines; an interactive machine A and an RSA adversary E. On input 1 k, F a runs the pair (A ; B) on input 1 k. If (A ; B) have joint public output (N; e) then y 2 (Z=NZ) is chosen at random, and the RSA adversary E is run on input 1 k, (N; e), y, and an auxiliary input consisting of a description of A 's execution. E of course now tries to `invert' y. The denition of a malicious adversary F b = (B ; E) which corrupts Bob is now analogous. An adversary is polynomial time if the total running time of the pair of interactive Turing machines and the RSA adversary is polynomial in k. Denition 3 A two-party shared RSA key generation protocol (A; B) is secure (against malicious adversaries) if, for all polynomial time adversaries F a = (A ; E): Pr[((N; e); d a ; d b ) (A ; B)(1 k ); y (Z=NZ) ; E(1 k ; (N; e); y; ) = x : x e = y mod N] is negligible (where denotes a description of A 's execution, and similarly for all polynomial time adversaries F b = (B ; E). Security can also be dened in the face of eavesdropping adversaries by restricting F a and F b in the above denition to be of the form F a = (A; E) and F b = (B; E). Observe that the above denition of security does not exclude the possibility that an adversary F only allows a shared key to be generated in the unlikely event (occurring with negligible probability) that E can factor N. Note that in some scenarios it would be desirable to generalise the above denition to allow adversaries who run the linked Turing machines a number of times. Since Alice and Bob do not have any private input in this particular model, such an extension does not increase F 's power in this case.

7 Shared Generation of Shared RSA Keys 5 3 The Cocks Protocols In this section the two-party shared RSA key generation protocols introduced by Cocks in [6] are described. In Section 4 we will explain why neither of these protocols can be used in the presence of a malicious adversary. The rst, asymmetric, protocol is designed to provide security against eavesdropping adversaries. The second, symmetric, protocol prevents certain attacks by malicious adversaries. 3.1 The Asymmetric Cocks Protocol To generate a shared key pair, Alice and Bob repeat the following process. Alice chooses two integers p a and q a (not necessarily prime) and Bob chooses two integers p b and q b (again not necessarily prime). Alice and Bob jointly compute the modulus N = (p a + p b )(q a + q b ) as follows. 1. Alice chooses her own RSA modulus M a and public exponent e a, which she makes known to Bob. The exponent e a should be large to prevent an attack due to Coppersmith; see Cocks [7]. Alice's private decryption key is d a. The modulus M a should be larger than the maximum size that N could possibly be. She sends the quantities p ea a mod M a to Bob. q ea a 2. Bob calculates the three elements a 1;a = p ea a qea b = (p a q b ) ea mod M a a 2;a = p ea b qea a = (p b q a ) ea mod M a a 3;a = (p b q b ) ea mod M a : mod M a and 3. Bob generates a set of 3K numbers fb i;j;a : 1 i 3; 1 j Kg, chosen to be random modulo M a subject to the condition that KX j=1 b i;j;a = 1 mod M a for all i 2 f1; 2; 3g : Here K is a `suciently large' integer. The choice of an appropriate K is discussed below. 4. Bob calculates the 3K numbers x i;j;a = a i;a b ea i;j;a mod M a, and sends them to Alice in a new order (for example a random order, or in a sorted order). This is done so that it is impossible for Alice to recover the correspondence between the elements x i;j;a and the pairs (i; j). 5. Alice calculates the elements y i;j;a = x da i;j;a mod M a, so y i;j;a = b i;j;a a da i;a mod M a :

8 Shared Generation of Shared RSA Keys 6 Hence Alice can determine p a q a + 3X KX i=1 j=1 y i;j;a = p a q a + p a q b + p b q a + p b q b = N mod M a : Since 0 < N < M a, Alice has determined N uniquely. 6. Alice sends N to Bob. Once N has been calculated, Alice and Bob determine whether N is the product of two primes by using, for example, the test due to Boneh and Franklin [2]. The above process is repeated until they generate a candidate N which is the product of two primes. Finally, Alice and Bob agree on a small value for e and respectively compute shares d a and d b of the corresponding d by exchanging the values of p a + q a and p b + q b modulo e as described by Boneh and Franklin [2]. Consider the security of this protocol in the case that Alice and Bob do not deviate from the protocol's description. The security of the protocol certainly relies on choosing the integer K to be suciently large. The integer K should be chosen so that Alice receives virtually no information about the decomposition of the the sum i=1p P3 K y j=1 i;j;a into the three summands p a q b, p b q a and p b q b. Cocks recommends that K should be chosen so that (3K)! (K!) > M 3 a 2 ; in which case for most guesses by Alice as to the values of p a q b, p b q a, and p b q b there will be a partition of the 3K fragments into 3 sets which produce these values. If K is chosen to be of this size, it seems that Alice receives no useful information from the protocol, beyond the value of N and her secret information p a and q a. At the end of the protocol, Bob knows p b, q b, the modulus N and the encryptions p ea a, q ea a of Alice's secret information. It seems plausible that the extra information that Bob possesses does not help to break the resulting RSA system (i.e. modulo N) under the assumption that Alice is implementing RSA securely (i.e. modulo M a ). 3.2 The Symmetric Protocol Cocks [6] remarks that a dishonest Alice could, of course, cheat in the asymmetric protocol, simply by transmitting a dierent value of N at stage 6. He observes that, to avoid these kinds of active attacks, the process of computing N could be made symmetrical. More explicitly, let 1 0, 2 0, 3 0, 4 0, 5 0 and 6 0 be the steps of the asymmetric protocol with the roles of Alice and Bob reversed. (We attach a subscript of b rather than a to all the new variables that arise, to indicate that they are associated with Bob's RSA modulus M b.) Then a symmetric version of the protocol replaces the steps 1{6 with the steps 1{5, the steps 1 0 {5 0, an exchange of hashes of N, and nally the publication and verication of N.

9 Shared Generation of Shared RSA Keys 7 4 Attacks on the Cocks Protocols We now consider various attacks on the symmetric and asymmetric versions of the Cocks protocol. These attacks show that neither protocol prevents attacks by a malicious adversary. Three of the attacks are relatively easy to prevent. Our desire to avoid the fourth attack motivated our construction of the protocol in Section Dishonest Alice in the Symmetric Protocol Our rst attack works on the symmetric version of the protocol. Suppose that Alice is dishonest. Before the protocol begins, she generates an RSA modulus N 0. She would like to manipulate Bob into believing that N 0 is the modulus the pair are trying to generate. Alice follows the protocol correctly during stages 1 to 5, and during stage 1 0. At this point, she has calculated the modulus N and has received the values p e b b mod M b and q e b b mod M b from Bob. Suppose that Alice can factor N. (This situation is likely to occur.) Alice is now able to compute Bob's secret information p b and q b as follows. She rst chooses a factorisation N = pq. Provided that N is not too smooth (which is unlikely to happen), there are not very many choices for p and q. For each such choice, she computes p 0 b = p? p a and q 0 b = q? q a. She then checks whether the following equalities hold: (p 0 b )e b = p e b b mod M b (qb) 0 e b = q e b b mod M b : If these equalities do hold, p 0 b = p b and q 0 b = q b so she has found Bob's secret information. If these equalities do not hold, she tries another choice of the factorisation N = pq. One choice of the factorisation N = pq will always recover p b and q b, since N = (p a + p b )(q a + q b ). Alice now chooses a set of 3K elements at random subject to the condition that fy 0 i;j;b 2 Z=M bz: 1 i 3; 1 j Kg 3X KX i=1 j=1 y 0 i;j;b = N 0? p b q b mod M b : She sends elements x 0 i;j;b in a sorted or random order to Bob, where x 0 i;j;b = (y 0 i;j;b) e b mod M b : Bob decrypts these elements to recover the elements y 0 i;j;b, and then calculates the sum mod M b of these elements and p b q b ; this is equal to N 0 rather than N as Bob hopes. Finally, Alice and Bob exchange a hash of N 0 rather than N.

10 Shared Generation of Shared RSA Keys 8 Because Alice knows p b and q b, she can arrange that N 0 passes the Boneh-Franklin test. At the end of the protocol, Alice and Bob have agreed on a common modulus N 0 that is the product of two primes. However, Alice can factor N 0. One way to prevent this attack is to have Alice and Bob exchange messages simultaneously, so that Alice sends ow 1 to Bob at the same time that Bob sends ow 1 0 to Alice, and so on. This can be achieved by the parties exchanging commitments to these ows using a hash function. 4.2 Cheating by a choice of pa, qa In either the symmetric or asymmetric protocol, Alice could cheat by choosing either p a or q a to have a factor in common with her public RSA modulus M a. If she does this, she is able to derive information about the partition of the elements x i;j;a into the three classes fx 1;j;a g, fx 2;j;a g and fx 3;j;a g by computing the greatest common divisor of each x i;j;a and M a. This allows her to obtain Bob's secret information, and so Alice is able to factor N. A dishonest Bob can carry out a similar attack in the symmetric protocol. In either case, however, the attack is easily foiled by checking that the encrypted material received is coprime to the relevant modulus M a or M b. 4.3 Dishonest Bob in the Asymmetric Protocol In the asymmetric protocol Bob can send elements x 0 i;j;a to Alice such that Bob knows the sum of the elements (x 0 i;j;a modulo M )da a. (For example, Bob chooses random elements yi;j;a 0 2 Z=M az and sends the elements x 0 i;j;a = (y0 i;j;a mod M )ea a to Alice.) Then Alice reveals the integer N 0 = p a q a + 3X KX i=1 j=1 (x 0 i;j;a) da mod M a that she regards as the correct modulus, while Bob is able to compute p a q a, and hence (assuming that Bob is able to factor this number) he is able to derive p a and q a. Since Bob now knows Alice's secret information, he can calculate the answers Alice expects in the Boneh-Franklin test and hence he is able to convince Alice that N 0 is the product of two primes. There is a second attack that Bob is able to mount. After receiving p ea a mod M a and qa ea mod M a from Alice at stage 1 of the protocol, Bob is able to pick p b = (p a ) c 1(q a ) c 2c 3, where c 1, c 2 and c 3 are constants of his choice, similarly for q b. Although he does not know p a and q a, he is able to calculate p ea b and q ea b modulo M a from the information that Alice has given him, and so Bob can calculate the elements x i;j;a. This allows Bob to force N to have a certain form. For example, by taking p b = q a and q b = p a, the resulting N is a square. It is possible that Bob could benet from the special form of the resulting N and gain an advantage in factorising N. Both these attacks are prevented by using the symmetric protocol. They are included here to motivate the design of the protocol we propose in Section 5.

11 Shared Generation of Shared RSA Keys Cheating during the Boneh-Franklin Test Suppose that Alice and Bob have calculated a candidate N by following the Cocks protocol honestly. Suppose that Alice is dishonest. She could try to factor N. If she succeeds, she is able to recover Bob's secret information p b and q b using the method outlined in Subsection 4.1. Now when Alice and Bob execute the Boneh-Franklin test to determine whether N is the product of two primes, Alice can convince Bob that N is the product of two primes, even when this is not the case (since she knows what replies Bob expects to any query, as she has his secret information). Hence, at the end of the process of generating and testing N, Bob is convinced that N is a valid RSA modulus, but Alice is able to factor N. This attack is particularly pertinent in the case when Alice has far more computational power than Bob. For then Bob, even after trying (unsuccessfully) to factor N himself, cannot be sure that Alice has not factored N. Note that the attack could equally well have been launched by Bob. This attack motivated the design of the protocol we propose in Section 5. Our approach will require Alice and Bob to prove that they use their secret information p a, p b, q a, and q b properly at this stage. 5 A New Protocol We now describe a new protocol which resists active attacks. The protocol is derived from the Cocks scheme discussed in Subsection 3.1. The principal dierence between our protocol and the Cocks protocol is that we use a discretelogarithm based system, which has the advantage of allowing us to commit to the value of N before it is actually computed. However the security of our protocol therefore relies on the diculty of both the discrete logarithm problem and the RSA problem. A natural question is therefore: why not just agree a discrete logarithm key and forget about RSA altogether? However we point out that in applications like key escrow as described in Section 1, the cost of the encryption operation of the resulting system is a crucial overhead. The use of RSA (especially with small public exponent) may therefore be highly desirable because encryption is cheap. The protocol is fairly complicated. We therefore provide an overview of the protocol before describing the details. Overview. There are four distinct phases of the protocol: A. Commitment to N. As in the Cocks protocol, in this protocol Alice and Bob will generate candidate moduli N of the form N = (p a + p b )(q a + q b ). In the rst phase of the protocol Alice and Bob commit to the value of N that they will compute. B. Computation of N. Having committed to the value of the candidate N, Alice and Bob now proceed to compute N.

12 Shared Generation of Shared RSA Keys 10 C. Testing N. Next Alice and Bob test whether the candidate N they have calculated is the product of two primes. The rst three phases are repeated until a candidate N which passes this test is generated. D. Exponent generation. Once a suitable N has been found, in the nal phase Alice and Bob agree on a value for the public key e and generate shares d a and d b of the corresponding private key. Various steps in the protocol require Alice and Bob to prove that certain statements are true. For clarity of exposition, we delay a description of the proofs we recommend until Section 6. If any of the checks or proofs performed by Alice or Bob during the protocol fail, then the entire protocol is halted; either Alice or Bob has been caught cheating. We now describe the details of the protocol. Suppose that Alice and Bob want to generate a modulus of length 2n + 3 or 2n + 4 bits. Commitment to N. Alice and Bob commit to the value of a candidate N as follows. The commitment is made using a discrete logarithm based system. To initiate this phase Alice and Bob agree on two prime numbers M and L so that L divides M? 1 (ideally M? 1 = 2L), so that L has at least 2n + 7 bits, and so that L? 1 has a large prime factor. They also agree on an element in (Z=MZ) of order L and a generator for (Z=LZ). Techniques like those described in [11] can be used to agree these values. Alice and Bob then proceed as follows: 1. Alice chooses integers p a and q a uniformly at random such that 2 n p a ; q a < 2 n+1 and such that p a = q a = 3 mod 4. Likewise, Bob chooses integers p b and q b such that 2 n p b ; q b < 2 n+1 and such that p b = q b = 0 mod 4. The conditions on p a, p b, q a, and q b modulo 4 allow us to use the Boneh-Franklin test when checking whether or not the candidate N is the product of two primes. 2. Alice computes pa mod M and qa mod M. Bob computes p b mod M and q b mod M. Alice and Bob then exchange hashes of these values before publishing them. Both parties check that the published values agree with the previously exchanged hashes. At this stage the values p a, q a, p b and q b modulo L have been committed. Alice proves to Bob that she knows p a and q a, that p a = q a = 3 mod 4 and that 1 p a ; q a < 2 n+2. Similarly, Bob proves to Alice that he knows the integers p b and q b, that p b = q b = 0 mod 4 and that 1 p b ; q b < 2 n+2. These proofs are made using the proof system described in Subsection 6.3. (Note that we prove that the values lie in a larger interval here than the interval specied in step 1; see Section 7.) Both parties independently compute the value I = pa+p b mod M.

13 Shared Generation of Shared RSA Keys Alice computes and publishes I qa mod M and proves to Bob that this has been performed correctly. Similarly, Bob computes and publishes I q b mod M and proves that this has been performed correctly. Appropriate proof systems are described in Subsection 6.1. Both parties may now independently compute I qa I q b = (pa+p b)(q a+q b) = N mod M which gives a commitment to the choice of N modulo L. In other words, there is a unique integer 0 < N L for which N is the value computed in this step. Having committed to the value of the candidate N, Alice and Bob now proceed to compute N. Computation of N. Alice and Bob calculate N using an ElGamal-based variant of the procedure used in the asymmetric Cocks protocol described in Subsection 3.1. The use of ElGamal is necessary so that the zero-knowledge proofs in Section 6 can be used. 4. Alice chooses an ElGamal secret key s for sending messages modulo L and publishes her public key = s mod L. 5. Alice sends p a and q a to Bob via ElGamal encryption modulo L, using her public key. More precisely, Alice chooses random integers k 1 ; k 2 and sends (R 1 ; S 1 ) = ( k 1 ; p a k 1 ) mod L (R 2 ; S 2 ) = ( k 2 ; q a k 2 ) mod L to Bob. Alice proves to Bob that these encryptions have been correctly computed using the proof system in Subsection Bob chooses 3K random elements b i;j 2 Z=LZ, for 1 i 3 and 1 j K exactly as in the Cocks protocol (so that P j b i;j = 1 mod L for each i). Bob chooses random elements r i;j 2 Z=(L? 1)Zand computes the pairs x 1;j = (R 1 r 1;j ; b 1;jq b S 1 r 1;j ) mod L x 2;j = (R 2 r 2;j ; b 2;jp b S 2 r 2;j ) mod L x 3;j = ( r 3;j ; b 3;jp b q b r 3;j ) mod L : These pairs are then sorted (or thoroughly shued in some other way) and sent to Alice. 7. For each x i;j = (u; v), Alice performs the usual ElGamal decryption y i;j = vu?s mod L :

14 Shared Generation of Shared RSA Keys 12 Hence she obtains the values y 1;j = b 1;j p a q b mod L, y 2;j = b 2;j p b q a mod L and y 3;j = b 3;j p b q b mod L. Alice computes p a q a + 3X KX i=1 j=1 y i;j = (p a + p b )(q a + q b ) = N mod L : She checks that 2 2n+2 N < 2 2n+4 and that N mod M agrees with the value committed earlier. (This check shows that Bob has been honest in the generation of the elements x i;j.) She then sends the integer N to Bob. 8. Bob checks that 2 2n+2 N < 2 2n+4, computes N mod M and checks to see if it agrees with the value committed earlier. Note that, in this protocol, there is no advantage in using a symmetric version, since Alice and Bob are forced to produce the value of N to which they have already committed. Testing N. Once N has been calculated, Alice and Bob determine whether N is the product of two primes using the test due to Boneh and Franklin [2]. However, we will insist on proofs that the test is performed correctly. 9. Alice and Bob independently check that N is not divisible by any small primes (say less than 2 15 ). 10. For all?? x x in a predetermined list Alice and Bob calculate the Jacobi symbol x If N = 1, Alice computes and publishes va = x (pa+qa+2)=4 mod N and Bob computes and publishes v b = x (p b+q b )=4 mod N. Alice and Bob prove to each other that these values have been computed correctly using the proof system in Subsection The candidate modulus N is declared to be a probable product of two primes if it is always the case that x (N?1)=4 (v a )?1 = v b mod N. The three phases above are repeated until a modulus N is generated that is the product of two primes. Exponent generation. Having generated a candidate N which is the product of two primes, Alice and Bob now generate the public exponent e and shares d a and d b of the private exponent in the same way as the Cocks protocol in Subsection 3.1. We outline the method here for completeness. 12. Alice and Bob agree on a small public exponent e (say e = ). N.

15 Shared Generation of Shared RSA Keys Alice and Bob exchange the values p a + q a mod e and p b + q b mod e. Both parties can therefore calculate f = (p a + p b ) + (q a + q b )? N? 1 mod e and hence g = f?1 mod e (provided f is invertible modulo e). Alice then calculates d a as: d a = (N +1) 2? p a? q a g e 75 ; and Bob calculates d b as: d b = 2 (N +1) 6 3? p 2 b? q b g e 7 : Finally Alice and Bob have succeeded in generating a shared RSA key: the public key is (N; e), Alice's share of the private key is d a, and Bob's share of the private key is d b. In some applications, it may be desirable to ensure that neither party can be duped into holding an incorrect share of the private key. If this is the case, then Alice and Bob should additionally check that the values of p a + q a mod e and p b + q b mod e exchanged in step 13 are correct. This can be done using standard (but impractical) zero-knowledge techniques, or by carrying out trial decryptions with proofs of correctness similar to those in Subsection 6.4. The security of this protocol will be discussed in Section 7. Issues involved in the implementation of the protocol in practice are discussed in Section 8. 6 Proofs used in the Protocol There are four points in the protocol given above where one participant must convince the other of their knowledge of a certain piece of information, or of the correctness of some calculation. This section suggests proofs that can be used in these situations. Two of the proofs we suggest are zero-knowledge, but the remainder leak some knowledge to the verier. Where a signicant amount of knowledge is revealed by the protocol, we attempt to quantify the amount of revealed knowledge. 6.1 The Proofs in Step 3 Let I 2 Z=MZand qa ; q b 2 Z=MZ be public. In step 3 of the protocol, Alice publishes G 2 Z=MZ. She wishes to prove to Bob that G = I qa without revealing any information about q a. Similarly, Bob publishes G 0 2 Z=MZ, and wishes to prove to Alice that G 0 = I q b. We suggest that Alice and Bob achieve this using the perfect zero-knowledge conrmation protocol for undeniable signatures due to Chaum [4]. For completeness we now describe the protocol that Alice uses. The protocol used by Bob is analogous. The probability that Alice can successfully cheat in this proof is 1=L.

16 Shared Generation of Shared RSA Keys 14 The proof system works as follows. Bob checks that G L = 1 mod M. He then chooses elements r 1 ; r 2 2 Z=LZuniformly at random. He sends v = I r 1 r 2 mod M to Alice. Alice then chooses a random element r 3 2 Z=LZ. She sends w 1 = r 3 and w 2 = (v r 3) qa to Bob. Bob then sends r 1 and r 2 to Alice. She checks that v was computed correctly. Finally, Alice sends r 3 to Bob. He checks that w 1 and w 2 were computed correctly, and recovers I qa by calculating (w 2 =( qa ) r 2+r 3 ) 1=r The Proofs in Step 5 Let pa ; qa mod M, and = s mod L be public. Let (R 1 ; S 1 ) and (R 2 ; S 2 ) be the ElGamal encryptions sent from Alice to Bob. In step 4 of the protocol, Alice is required to prove to Bob that (R 1 ; S 1 ) and (R 2 ; S 2 ) are respectively valid encryptions of p a mod L and q a mod L under the public key. We suggest that Alice achieves this using the perfect zero-knowledge proof described below. Since the technique is of a standard type (see Chaum et al. [5]), we omit the proof of soundness. The probability that Alice can cheat in any one iteration of the system described is 1=2. Alice and Bob will therefore repeat the proof until Bob is convinced that Alice has sent him the correct encryptions. To prove to Bob that (R 1 ; S 1 ) is a valid encryption of p a, Alice proceeds as follows. Let k 1 be such that (R 1 ; S 1 ) = ( k 1; p a k 1). Alice chooses two elements r 1 2 (Z=LZ) n f0g and r 2 2 Z=(L? 1)Zuniformly at random. She sends the values T 0 = par 1 mod M, R 0 = k 1+r 2 mod L and S 0 = (p a r 1 ) k 1+r 2 mod L to Bob. Either Bob requests (and Alice sends) r 1 and r 2, in which case Bob checks that r 1 6= 0 mod L ( pa ) r 1 = T 0 mod M R 1 r 2 = R 0 mod L r 1 S 1 r 2 = S 0 mod L ; or Bob requests (and Alice sends) r 1 p a 2 Z=LZand k 1 + r 2 2 Z=(L? 1)Z, in which case Bob checks that r 1 p a 6= 0 mod L r 1p a = T 0 mod M k 1+r 2 = R 0 mod L (r 1 p a ) k 1+r 2 = S 0 mod L : The analogous proof is then used to convince Bob that (R 2 ; S 2 ) is a valid encryption of q a.

17 Shared Generation of Shared RSA Keys The Proof in Step 2 In step 1 of the protocol above, Alice has published an element S where S = pa mod M. In step 2, Alice is required to prove to Bob that she knows an integer p a such that pa = S mod M, such that 1 p a < 2 n+2 and such that p a = 3 mod 4. Alice is also required to prove similar statements about q a, and Bob to prove similar statements about p b and q b. Since these requirements are all of the same form, we will describe here only a proof system that can be used by Alice in the rst case. This proof system can be adapted in the obvious way to prove the other statements. The proof required presents a problem. The statement being proved is in NP, so one possibility is to use the generic zero-knowledge techniques described by Goldreich, Micali, and Wigderson [16]. However, the resulting proofs are not practical. Indeed the authors know of no practical zero-knowledge protocol for this problem. Therefore we propose instead an ecient proof system which is not zero-knowledge. This system is inspired by zero-knowledge proofs such as those described in Subsection 6.2. Unfortunately the proof we suggest does leak a substantial amount of knowledge about p a ; after the description of the proof system, we will discuss how much knowledge of p a is leaked by our method. The probability that Alice can cheat in any one iteration of the system described is 1=2. Alice and Bob will therefore repeat the proof enough times so that Bob is convinced by Alice's proof, but few enough times so that (with high probability) Bob cannot obtain too much knowledge about p a. To prove that Alice knows an integer p a such that pa = S mod M and 1 p a < 2 n+2, she proceeds as follows. She chooses an integer r 2 f0; 1; : : : ; 2 n? 1g uniformly at random. She publishes R = r mod M. Bob then requests (and Alice sends) either r or the integer m = p a +r. In the rst case, Bob checks that r = R and that 0 r 2 n?1. This proves that R is properly constructed. In the second case, Bob checks that m = RS and that 2 n m 2 n n. This proves that, provided r is properly constructed, m = p a + r and 1 p a 2 n n < 2 n+2. Alice also wishes to prove to Bob that p a = 3 mod 4. This can be simply achieved by requiring Alice to choose an integer r such that r = 0 mod 4 in the above proof system. Bob checks that r = 0 mod 4 or that m = p a + r = 3 mod 4 at the appropriate place in the proof. No extra knowledge about p a is leaked by this modication when Alice is acting honestly, since the value of p a mod 4 is already specied in the protocol. In the Appendix, we analyse how much knowledge is leaked by this proof system. In summary, it is shown that with probability at least 1? 2t at most d bits of information about p 2 a are d leaked to Bob by revealing the t sums p a + r 1 ; p a + r 2 ; : : :; p a + r t. See the Appendix for details. Bob gains no signicant additional knowledge from the commitments r 1; : : :; rt. In practice we would like to reduce the amount of knowledge leaked in this stage of the protocol. One possibility, discussed in Section 8, is that the system is not iterated many times. We suggest that in many applications, Alice and Bob nonetheless receive sucient assurance from the protocol. Another possibility is to omit the proof altogether, and replace it by a simple

18 Shared Generation of Shared RSA Keys 16 zero-knowledge proof of knowledge of the discrete logarithm. In this case one party may actively cheat by choosing their secret integers to be outside the correct range. Whilst this might cause the value of N to exceed L, it is then almost certain that N would fail the Boneh-Franklin test. The attack could be made even less attractive by specifying that all secret information is revealed whenever a modulus N that fails the Boneh-Franklin test is generated, so that a party cheating like this is almost certainly detected. Omitting the proof altogether may therefore also be considered a possibility in some applications. 6.4 The Proof in the Boneh-Franklin Test During the Boneh-Franklin test, Alice needs to prove to Bob that she has computed the value R = x z mod N correctly, where z = (p a + q a + 2)=4. Note that, by this stage of the protocol, Bob knows that 1 z 2 n+1. In this subsection we will describe an ecient proof system that can be used by Alice to prove this statement. Essentially the same proof can be used by Bob to prove that he has calculated correctly x (p b+q b )=4 mod N. Again only impractical zero-knowledge techniques to prove this statement like those described by Goldreich, Micali, and Wigderson [16] are known. We therefore propose instead a method which is similar to those used in Subsection 6.3. However, since we are able to use random values which are taken from a much larger range in this test, the proof is unlikely to leak a signicant amount of knowledge. The test is carried out as follows. Alice chooses an integer r 2 f0; 1; : : : ; u? 1g uniformly at random, where u is chosen so that u is large and u + 2 n+1 < L. Alice publishes S = x r mod N and T = r mod M. Then Bob requests (and Alice sends) either r or m = z + r. In the rst case, Bob checks that Otherwise, Bob checks that 0 r u? 1 (1) x r = S mod N (2) r = T mod M : (3) 1 m < L (4) x m = SR mod N (5) 4m = T 4 pa qa 2 mod M : (6) The checks (1) to (3) in the rst case ensure that S and T have been correctly constructed, i.e. there exists a (uniquely determined) integer r such that 0 r < u and such that S = x r mod N and T = r mod M. Assuming that S and T have been correctly constructed, the checks in

19 Shared Generation of Shared RSA Keys 17 the second case ensure that R = x z mod N, as the following argument shows. By (6), we have that 4m = 4(r + z) mod L (and so, since 4 is coprime to L, that m = z + r mod L). Now 0 m < L (by equation (4)). Moreover, 1 z 2 n+1 and 0 r < u L? z. Hence the fact that m = z + r mod L implies that m = z + r. The equality (5) now shows that R = x m?r = x z mod N. Just as in the subsection above, knowledge about z may be leaked to Bob via the sums m and the commitments r i and x r i. Again the results proved in the Appendix can be used to analyse how much. In this case it is very unlikely that any signicant knowledge is, in fact, leaked. For example, taking u = 2 2n+5 it is shown that with probability at least 1? t2?(n+3) no information is leaked about z from observing the t sums m i = z + r i. See the Appendix for details. As before, the commitments r i and x r i do not appear to add to Bob's eective knowledge. Note that in this case the possibility of relaxing or leaving out the proofs altogether is not a good idea: on the one hand as we have seen very little knowledge is likely to be leaked about p a, and on the other hand eective attacks like those described in Subsection 4.4 become possible if the proof is omitted. 7 Security Issues This section aims to give plausible arguments as to why the protocol in Section 5 is a secure two-party shared RSA key generation protocol. Is the Protocol Well-Dened? This boils down to the question: is the protocol a good key generator for RSA from the point of view of a third party? Just like the Cocks protocols [6] and the protocol of Boneh and Franklin [2], our protocol generates a random modulus N of the form (p a + p b )(q a + q b ) which is a product of two primes. This modulus is therefore the product of two primes chosen almost uniformly at random within a certain range. Given that it is secure to generate RSA keys simply by picking primes of the appropriate length at random (which is widely believed), then it can be seen that keys generated in this way are also secure (see [2]). Is the Protocol Secure against Eavesdropping Adversaries? Suppose Alice and Bob follow the protocol honestly. Does the extra knowledge they learn during the protocol give either party an advantage they can use to invert the resulting RSA system? Consider rst the knowledge leaked to either party by the proof systems employed during the protocol. As we have seen, the proof systems used in steps 3 and 4 are zero-knowledge and the proof system used during the Boneh-Franklin test is extremely unlikely to leak a signicant amount of knowledge. Hence the only threat comes from the system used in step 2. The most signicant bits of the secrets p a and q a or p b and q b may well be leaked by the proof at this stage. It is possible that this knowledge may be used to factor N if suciently many bits leak: for example an algorithm based on lattice techniques due to Coppersmith [8] factors N in

20 Shared Generation of Shared RSA Keys 18 polynomial time provided that the 1 4 log 2 N most signicant bits of one of the factors are known. In our situation suppose N is a 512-bit integer, then this means that Bob is able to factor N if 128 bits of p a are revealed. However, according to the analysis in the appendix, this number of bits will leak with probability only approximately 2?128. Based on the analysis, it seems that, provided the proof system is only iterated a sensible number of times, Alice and Bob are extremely unlikely to gain sucient knowledge at this stage to make such an attack viable. (If this leakage is undesirable, one possibility is to omit the proof. This possibility is discussed in Subsection 6.3.) Next consider the knowledge that may be leaked to either party during the other stages of the protocol. At the end of the protocol Alice also possesses Bob's commitments to p b and q b, the elements y i;j;a, and the value p b + q b mod e. Alice certainly gains nothing from the value p b + q b mod e since e is necessarily small. Furthermore, as in the Cocks protocol, the integer K is chosen so that it is unlikely that Alice gains any useful information from the elements y i;j;a. Finally, provided the discrete logarithm problem is hard, it seems plausible that Bob's commitments to p b and q b also do not leak any knowledge that Alice can use to her advantage. Thus it seems reasonable to assert that a passive Alice does not gain signicant advantage from the protocol to help her invert the resulting RSA system. At the end of the protocol, Bob also possesses Alice's commitments to p a and q a, the ElGamal encryptions of p a and q a, and the value of p a + q a mod e. As above, provided Bob does not gain any signicant knowledge from the ElGamal encryptions of p a and q a, he appears to gain no worthwhile advantage that might enable him to invert the resulting RSA system. It therefore seems that the protocol proposed in secure against eavesdropping adversaries provided the discrete logarithm problem is hard and the RSA problem is hard. Note that it is required that the discrete logarithm problem is hard for logarithms within certain ranges: see van Oorschot and Wiener [21] for a discussion of this problem. Is the Protocol Secure against Malicious Adversaries? The crucial point here is that the proofs and checks performed during the protocol essentially force Alice and Bob to behave honestly. There are two exceptions: there is no check that either party has selected their secret contributions at random, and the proof used during step 2 only checks that the contributions lie in the larger range 1 to 2 n+2 rather than the specied range 2 n to 2 n+1. Malicious adversaries who cheat in any other way will be detected with high probability, and hence it is sucient to restrict our attention to malicious adversaries of the special type that possibly cheat in either of the above ways but otherwise follow the protocol honestly. Firstly it seems impossible for such an adversary to gain a signicant advantage by choosing the contributions p a and q a or p b and q b non-uniformly. In this case the other pair of contributions will still have been selected uniformly at random, and so the distribution of the resulting moduli will not have been signicantly eected.

21 Shared Generation of Shared RSA Keys 19 Modulus Size K ElGamal (bits) Operations ,000, ,000, ,000,000 Figure 1: ElGamal operations to be carried out by Alice or Bob Secondly, what damage can be caused by choosing the values, say p a and q a, outside the range 2 n to 2 n+1? Since p a and q a are certainly less than 2 n+2, the resulting modulus N is certainly no greater than L. Furthermore, since the other party is behaving honestly and has selected p b and q b in the range 2 n to 2 n+1, both factors of N are certainly greater than 2 n. The power of such an adversary is therefore extremely limited. Both parties check that the modulus N generated is in the range 2 2n+2 to 2 2n+4, so the best the adversary can hope to achieve is to force the modulus to be the product of an (n + 1)-bit prime and an (n + 3)-bit prime. In the light of current factoring algorithms, this does not represent a signicant advantage. We conclude that the protocol appears to be secure in the face of malicious adversaries. 8 Eciency Issues This section contains estimates of the running time of the protocol proposed in Section 5. We also discuss ways in which the protocol might be modied in practical situations in order to increase its eciency. Workload Estimate. The protocol generates candidate moduli N of the form N = pq and then tests whether N is the product of two primes. The probability of p and q both being prime is approximately (log p)?1 (log q)?1. Hence we expect that (log 2 n ) 2 candidate moduli are produced before a 2n-bit modulus that passes the Boneh-Franklin test is generated. The bulk of the work in the protocol is involved in the ElGamal encryptions and decryptions carried out during the calculation of N. Bob performs 3K ElGamal encryptions and Alice performs essentially 3K decryptions. If K is chosen to be as small as possible subject to the condition that (3K)!=(K!) 3 > M 2 a, the expected total number of ElGamal operations to be calculated by Alice or Bob may be enumerated. Some sample values are given in Figure 1. The cost of the other components in the protocol is negligible compared to the cost of these operations. Note that the number of operations required is essentially the same as the number of operations required by the asymmetric Cocks protocol described in Subsection 3.1. However, the asymmetric Cocks protocol employs RSA operations as opposed to ElGamal operations. Since RSA is computationally less expensive than ElGamal, we would expect the asymmetric Cocks