Automatically Verified Mechanized Proof of One-Encryption Key Exchange

Automatically Veriﬁed Mechanized Proof of One-Encryption Key Exchange

Bruno Blanchet INRIA, Ecole´ Normale Superieure,´ CNRS Paris, France [email protected]

Abstract—We present a mechanized proof of the password- Unfortunately, a security result should be considered with based protocol One-Encryption Key Exchange (OEKE) using care. As explained above, it consists of a theorem which the computationally-sound protocol prover CryptoVerif. OEKE states that under a precise intractability assumption a spe- is a non-trivial protocol, and thus mechanizing its proof provides additional confidence that it is correct. This case cific security model (goals and means of the adversary) is study was also an opportunity to implement several important satisfied. The reduction constitutes the proof of the theorem. extensions of CryptoVerif, useful for proving many other Weaknesses can appear at several steps: the intractability protocols. We have indeed extended CryptoVerif to support the assumption can be too strong, or even wrong; the security computational Diffie-Hellman assumption. We have also added model might not correspond to the expected security level; support for proofs that rely on Shoup’s lemma and additional game transformations. In particular, it is now possible to insert the reduction may not be tight; and the proof can be erro- case distinctions manually and to merge cases that no longer neous. Because of more and more complex security models need to be distinguished. Eventually, some improvements have and proofs, most of them are never (double)-checked. been added on the computation of the probability bounds for A famous example is the OAEP construction [6] that attacks, providing better reductions. In particular, we improve has been proven to achieve chosen-ciphertext security. But over the standard computation of probabilities when Shoup’s lemma is used, which allows us to improve the bound given because of ambiguous security models in the early 90s, there in a previous manual proof of OEKE, and to show that the was no real difference between the so-called IND-CCA1 and adversary can test at most one password per session of the IND-CCA2 security levels. As a consequence, the proof was protocol. In this paper, we present these extensions, with their believed to achieve the IND-CCA2 level, until Shoup [7] application to the proof of OEKE. All steps of the proof, both exhibited a counter-example. Fortunately, a complete proof automatic and manually guided, are verified by CryptoVerif. for IND-CCA2 has quickly been provided [8]. A machine- Keywords-Automatic proofs, Formal methods, Provable se- checked proof has later been provided [9]. curity, Protocols, Password-based authentication As suggested by Halevi [10], computers could help in verifying proofs. This paper follows this path, with I.INTRODUCTION computationally-sound computer-aided proof and verification of cryptographic protocols. Since the beginning of public-key cryptography, more Related Work: Various methods have been proposed for and more complex security notions have been defined, reaching Halevi’s goal. Following the seminal paper by with protocols getting also more intricate. Initially, a long Abadi and Rogaway [11], many results show the soundness time without attack was a good argument in favor of the of the Dolev-Yao model with respect to the computational security of a scheme. But some schemes took a long time model, which makes it possible to use Dolev-Yao provers before being broken. A famous example is the Chor-Rivest in order to prove protocols in the computational model cryptosystem [1], [2], which took more than 10 years to be (see, e.g., [12], [13], [14], [15], [16] and the survey [17]). totally broken [3]. Nowadays, the lack of attacks is no longer However, these results have limitations, in particular in considered as a security validation, and provable security is terms of allowed cryptographic primitives (they must satisfy a requirement for any new proposal. strong security properties so that they correspond to Dolev- The basic idea of provable security consists in reducing a Yao style primitives), and they require some restrictions on well-known hard problem to an attack, in the complexity protocols (such as the absence of key cycles). A tool [18] theory framework. Such a reduction guarantees that an was developed based on [12] to obtain computational proofs efficient adversary against the cryptosystem could be con- using the formal verifier AVISPA, for protocols that rely on verted into an efficient algorithm against the hard problem. public-key encryption and signatures. First security proofs were essentially theoretical, providing Several frameworks exist for formalizing proofs of pro- polynomial reductions only. But “exact security” [4] or tocols in the computational model. Backes, Pfitzmann ,and “concrete security” [5] asked for more efficient reductions. Waidner [19], [20] designed an abstract cryptographic library

1 and showed its soundness with respect to computational already been used to prove several cryptographic protocols, primitives, under arbitrary active attacks. This framework and also primitives [50]. This tool extends considerably has been used for a computationally-sound machine-checked early work by Laud [51], [52] which was limited either to proof of the Needham-Schroeder-Lowe protocol [21], [22]. passive adversaries or to a single session of the protocol. Canetti [23] introduced the notion of universal composabil- More recently, Tsahhirovˇ and Laud [53], [54] developed a ity. With Herzog [24], they show how a Dolev-Yao-style tool similar to CryptoVerif but that represents games by symbolic analysis can be used to prove security properties dependency graphs. It handles public-key and shared-key of protocols within the framework of universal compos- encryption and proves secrecy properties; it does not provide ability, for a restricted class of protocols using public- bounds on the probability of success of an attack. key encryption as only cryptographic primitive. Then, they Contributions: In this paper, we use the tool CryptoVerif use the automatic Dolev-Yao verification tool ProVerif [25] in order to prove the password-based key exchange protocol for verifying protocols in this framework. Process calculi One-Encryption Key-Exchange (OEKE) [55], a variant of have been designed for representing cryptographic games, Encrypted Key Exchange (EKE) [56]. This is a non-trivial such as the probabilistic polynomial-time calculus of [26] case study, since EKE was not proved correct before 2003, and the cryptographic lambda-calculus of [27]. Logics have 10 years after its publication. This mechanized proof pro- also been designed for proving security protocols in the vides additional confidence that the protocol OEKE is se- computational model, such as the computational variant cure. More precisely, we have shown that OEKE guarantees of PCL (Protocol Composition Logic) [28], [29] and CIL the secrecy of the session key and the authentication of the (Computational Indistinguishability Logic) [30]. Canetti et client to the server. The proof combines manually-guided al. [31] use the framework of time-bounded task-PIOAs and automatic steps, as detailed in Section IV. With the (Probabilistic Input/Output Automata) to prove security pro- manual proof indications included in the CryptoVerif input tocols in the computational model. This framework makes file, the runtime of CryptoVerif version 1.14 for this proof it possible to combine probabilistic and non-deterministic was 3 s on an Intel Core i5 2.67 GHz (4 cores). behaviors. These frameworks can be used to prove security This case study was also an opportunity for implementing properties of protocols in the computational sense, but except several extensions of CryptoVerif, useful for proving many for [24] which relies on a Dolev-Yao prover, they have not other protocols. Here are these extensions: been automated up to now, as far as we know. • CryptoVerif’s specification mechanism for assumptions Several techniques have been used for directly mechaniz- on primitives did not support the computational Diffie- ing proofs in the computational model. Type systems [32], Hellman (CDH) assumption, needed for proving OEKE [33], [34], [35] provide computational security guarantees. and many important protocols. We have extended it For instance, [32] handles shared-key and public-key en- to support CDH (Section III-D). This extension also cryption, with an unbounded number of sessions, by relying allowed us to prove a signed Diffie-Hellman protocol, on the Backes-Pfitzmann-Waidner library. A type inference in a fully automatic way. algorithm is given in [36]. In another line of research, a spe- • We have extended CryptoVerif to be able to apply cialized Hoare logic was designed for proving asymmetric Shoup’s lemma [43], by introducing events and later encryption schemes in the random oracle model [37], [38]. bounding their probability. We improve over the stan- The tool CertiCrypt [39], [40], [41], [42], [9] enables dard computation of probabilities, for applications of the machine-checked construction and verification of cryp- Shoup’s lemma, by avoiding to count several times tographic proofs by sequences of games [43], [44]. It relies probabilities that in fact correspond to the same runs. on the general-purpose proof assistant Coq, which is widely This allows us to obtain better probability bounds believed to be correct. EasyCrypt [45] generates CertiCrypt than [55] and to show that the adversary can test at most proofs from proof sketches that formally represent the se- one password per session of the client or the server, quence of games and hints, which makes the tool easier to which is the optimal result. This improvement applies use. Nowak et al. [46], [47], [48] follow a similar idea by both to CryptoVerif proofs and to manual proofs, and providing Coq proofs for several cryptographic primitives. it is not specific to the OEKE protocol (Section IV-A). Independently, we have built the tool CryptoVerif [49] • Additional game transformations were also needed for to help cryptographers, not only for the verification, but manually introducing case distinctions or for merg- also by generating the proofs by sequences of games [43], ing cases. We have implemented these transformations [44], automatically or with little user interaction. The games (Sections IV-A and IV-C). are formalized in a probabilistic polynomial-time process • Password-based protocols require a careful computation calculus. CryptoVerif provides a generic method for speci- of the probability of an attack, since one aims to fying security properties of many cryptographic primitives. It compute how many passwords the adversary can test proves secrecy and authentication properties. It also provides by interacting with the protocol. We have improved a bound on the probability of success of an attack. It has CryptoVerif in this respect (Section IV-D).

2 Outline: We recall the protocol OEKE in the next section. Client U Server S Section III presents the CryptoVerif model of the protocol, and Section IV presents its proof. We conclude in Section V. pw pw The appendices give background on CryptoVerif and addi- accept ← false accept ← false tional details. The tool CryptoVerif and the input and output terminate ← false terminate ← false files can be found at http://www.cryptoverif.ens.fr/OEKE/. R R x ← [1, q − 1] y ← [1, q − 1] Notations: |S| denotes the cardinal of the set S. #O U, X denotes the number of calls to oracle O. X ← gx −−−−−→ Y ← gy ? ? S, Y ? II.THE OEKEPROTOCOL Y ← Dpw (Y ) ←−−−−− Y ← Epw (Y ) x y Password-authenticated key exchange protocols allow two KU ← Y KS ← X parties that share a low-entropy common secret (a password) MU ← UkSkXkY kKU to agree on a common high-entropy secret key thereafter Auth ← H1(MU ) used with symmetric primitives, such as symmetric encryp- sk U ← H0(MU ) tion for privacy and message authentication codes for au- Auth accept ← true −−−−−→ MS ← UkSkXkY kKS thentication. The goal of such a protocol is to guarantee the ? Auth = H (M ) secrecy of the resulting common key between the two partic- 1 S if true, accept ← true ipating players. Furthermore, the protocol should succeed if sk ← H (M ) and only if the two players actually share the same password, S 0 S which guarantees the identity of the partner to both of terminate ← true terminate ← true them. Because of the low-entropy, an active adversary will Figure 1. An execution of OEKE, run by client U and server S. The x y succeed in impersonating a party to the other one with non- session key is sk = H0(UkSkXkY kY ) = H0(UkSkXkY kX ). negligible probability by successive password guesses. Such an on-line dictionary attack is unavoidable. However, one should guarantee that this is the best attack: one active attack within time t, and with less than N sessions with a allows the adversary to test and thus eliminate at most one U client, N sessions with a server (active attacks) and N password, and not more. Namely, passive attacks should not S P passive eavesdroppings (passive attacks), and, asking q (computationally) leak any information about the password. h hash-queries and q encryption/decryption queries, to make One definitely wants to prevent off-line dictionary attacks, e a server instance accept with no terminating client partner where after a few active attacks and possibly many passive is bounded by ones the collected information is enough to eliminate many passwords, and thus accelerate impersonation from the on- NU + 2NS cdh 0 + 3qh × Succ (t ) + pcoll line dictionary attack. N G 2 2 The first password-authenticated key exchange protocol (2qe + 2NU + 3NS + 3NP ) qh + 4Ns with pcoll = + has been proposed by Bellovin and Merritt [56], the En- 2(q − 1) 2`1+1 crypted Key Exchange (EKE). This is basically a Diffie- 0 where `1 is the length of the output of H1 and t ≤ t+(NU + Hellman key exchange where the two flows are encrypted Ns +NP +qe +1)·τexp, with τexp denoting the computation with a symmetric encryption scheme, using the password as cdh time for an exponentiation in .1 Furthermore, Succ (t) secret key. Several variants have thereafter been proposed, G G denotes the maximal success probability an adversary can such as AuthA [57]. The One-Encryption Key Exchange gain within time t against the computational Diffie-Hellman protocol (OEKE) studied in [55] is the particular variant problem in . Similarly, no adversary can distinguish the where the second flow only is encrypted under the password, G session key from a random key with advantage greater than and the first player proves his knowledge of the password with an additional key confirmation flow. Figure 1 provides 2NU + 4NS cdh 0 + 8qh × Succ (t ) + 2pcoll . a description of this OEKE protocol, which guarantees client N G authentication and key secrecy, under the assumptions that The proofs basically show that the unique way for the ad- H0 and H1 are random oracles, that E and D are respectively versary to gain something (against both client authentication the encryption and decryption of an ideal cipher, and that and secrecy of the session key) is to correctly guess the G is a finite group of prime order q, with generator g, in password, by either sending a Y ? that is really an encryption which the computational Diffie-Hellman problem is hard under the correct password, or using the correct password to (see the definition in Section III-D), as proven in [55]. 1 If the password pw is chosen among a finite dictionary In [55], they use as parameter the number qs of interactions with the parties, instead of the numbers of sessions N and N . It is straightforward passwd of size N equipped with the uniform distribution, U S to recompute the probabilities to use NS and NU instead, and this yields their proof shows that the probability for any adversary, a more precise evaluation.

3 decrypt Y ? and compute the authenticator Auth. One could variables V and all distinguishers D that run in time at most 0 hope to prove that the former event, denoted Encrypt, is tD, | Pr[C[G]: D] − Pr[C[G ]: D]| ≤ p(C, tD). bounded by NU /N and the latter event, denoted Auth, is bounded by NS/N. But, because of the way probabilities This definition formalizes that the probability that algorithms 0 are computed when one uses Shoup’s lemma [43], some C and D distinguish the games G and G is at most factor appears to the (NU + NS)/N main term. p(C, tD). The probability p typically depends on the runtime of C and D, but may also depend on other parameters, such III.MODELING OEKE IN CRYPTOVERIF as the number of queries to each oracle made by C. That is why p takes as arguments the whole algorithm C and In this section, we present the model of the protocol given 0 the runtime of D. When V is empty, we write G ≈p G . as input to CryptoVerif. We first recall some basic ideas Therefore, we obtain a sequence of indistinguishable games behind CryptoVerif, and then present the model itself: the G ≈V G ≈V G ...G ≈V G 0 p1 1 p2 2 n−1 pn n, which implies security assumptions on the primitives, the model of the G ≈V G G 0 p1+...+pn n. In the last game n, the desired security protocol, and the security properties that we want to prove. property is proved by direct inspection of the game, without The complete CryptoVerif model, and the reusable library using any computational assumption. For example, to bound that provides the definitions of cryptographic primitives, can the probability that an event e is executed, event e does be found at http://www.cryptoverif.ens.fr/OEKE/. not occur at all in the last game, so Pr[C[Gn]: e] = 0, hence the probability of executing e in the initial game is A. Review of CryptoVerif Pr[C[G0]: e] ≤ (p1 + ··· + pn)(C, e). CryptoVerif builds proofs by sequences of games [43], The game transformations used by CryptoVerif can be [44]. It starts from the initial game given as input, which split into two categories: represents the protocol to prove in interaction with an • syntactic transformations, which are used by Cryp- adversary. Then, it transforms this game step by step using a toVerif to simplify games and to prepare cryptographic set of predefined game transformations, such that each game transformations. These transformations do not rely on is indistinguishable from the previous one. any security assumption on primitives. More formally, a game G interacts with an adversary • cryptographic transformations, which rely on a security represented by a context C, and we denote by C[G] the assumption on a primitive. These security assumptions combination of C and G. During execution, C[G] may are themselves formalized as indistinguishability prop- execute events, collected in a sequence E, and finally returns erties L ≈p R, which are given as input to CryptoVerif a result a, either a bitstring or the special value abort when and need to be proved manually. They are proved the game has been aborted. These events and result can be once for each primitive and can then be reused in used to distinguish games, so we introduce an additional many protocols. We present such equivalences for the algorithm, a distinguisher D that takes as input the sequence primitives used in OEKE below. of events E and the result a, and returns true or false. An CryptoVerif uses these equivalences to perform proofs example of distinguisher is De defined by De(E, a) = true by reduction automatically. It detects that a game G can if and only if e ∈ E: this distinguisher detects the execution be written as a context C that calls the oracles of L, of event e. We will denote the distinguisher De simply by e. V that is, G ≈0 C[L] by purely syntactic transformations, More generally, distinguishers can detect various properties 0 V 0 and builds a game G such that C[R] ≈0 G by purely of the sequence of events E executed by the game and of syntactic transformations. C is the simulator usually its result a. We denote by D ∨ D0, D ∧ D0, and ¬D the defined for reductions. From L ≈p R, we can infer that distinguishers such that (D∨D0)(E, a) = D(E, a)∨D0(E, a), V C[L] ≈p0 C[R] where V is a subset of the variables of (D ∧ D0)(E, a) = D(E, a) ∧ D0(E, a), and (¬D)(E, a) = 0 0 0 0 C and p (C , tD) = p(C [C[ ]], tD). Indeed, if C is ¬D(E, a), where ∨ is the logical disjunction, ∧ the logical V the adversary against C[L] ≈p0 C[R], the adversary conjunction, and ¬ the logical negation. We denote by 0 V 0 against L ≈p R is C [C[ ]]. Therefore, G ≈p0 G and Pr[C[G]: D] the probability that C[G] executes a sequence CryptoVerif can transform G into G0. of events E and returns a result a, such that D(E, a) = true. A context C is acceptable for G with public variables B. The Random Oracle Model V when it can read directly the variables of G that are The random oracle model was introduced in [58] to in V , and it makes no other access to variables of G. model hash functions. It was encoded in CryptoVerif (This is more formally defined in Appendix A.) We define in [50]. We improve this model by using the equivalence indistinguishability as an equivalence G ≈V G0: p L1 ≈#Oeq/|hashoutput| R1 where L1 and R1 are defined in Figure 2. This model is not specific to OEKE. The hash V 0 Definition 1 (Indistinguishability) We write G ≈p G function hash takes as input a key of type key and the when, for all contexts C acceptable for G and G0 with public bitstring to hash of type hashinput and returns a result of

4 R 0 L1 = foreach ih ≤ nh do k ← key; r[u]. Otherwise, x was never given as argument to (foreach i ≤ n do hash(k, ·), so hash(k, x0) is a fresh random number, OH(x : hashinput) := return(hash(k, x)) | and it is equal to r0 with probability 1/|hashoutput|. foreach ieq ≤ neq do We eliminate this case in R1, so the result of the Oeq(x0 : hashinput, r0 : hashoutput) := comparison r0 = hash(k, x0) is replaced with false 0 0 return(r = hash(k, x ))) and the probability of distinguishing L1 from R1 is at most #Oeq/|hashoutput|, where #Oeq denotes the R1 = foreach ih ≤ nh do total number of calls to Oeq. (foreach i ≤ n do OH(x : hashinput) := We can notice that there exists at most one u that can satisfy find[unique] u ≤ n suchthat the condition of find in OH in R . Indeed, suppose that defined(x[u], r[u]) ∧ x = x[u] 1 u 6= u are such that x[u ], r[u ], x[u ], r[u ] are defined then return(r[u]) 1 2 1 1 2 2 and x = x[u ] = x[u ]. Suppose that the query OH with R 1 2 else r ← hashoutput; return(r) | i = u1 is called before OH with i = u2. (The other case foreach ieq ≤ neq do is symmetric.) Thus, when executing the query OH with 0 0 Oeq(x : hashinput, r : hashoutput) := i = u2, x[u1] and r[u1] are defined and x[u2] = x[u1], find[unique] u ≤ n suchthat so the find succeeds with u = u1, so r[u2] will not be defined(x[u], r[u]) ∧ x0 = x[u] defined (since r is defined only in the else branch of the then return(r0 = r[u]) find). Contradiction. Therefore, u is unique. Following a else return(false)) similar reasoning, u is also unique in Oeq in R1. That is why the finds in R1 are marked [unique]. Formally, the Figure 2. Random oracle model modifier [unique] means that, in case several choices satisfy the condition of find, an event NonUnique occurs and the NonUnique type hashoutput. The key models the choice of the hash game is aborted. As we have shown, the event R [unique] function. The key must be chosen once and for all at the never occurs in 1, so the modifier does not alter L ≈ R beginning of the game for each hash function, and the game the equivalence 1 #Oeq/|hashoutput| 1. The modifier [unique] find must include a hash oracle, which allows the adversary to allows additional transformations of , which are compute hashes. For each hash function indexed by ih ≤ nh, correct only when there never exist several choices that make find the games L and R define two oracles, OH and Oeq: the condition of the succeed. These transformations are 1 1 detailed in Appendix E-B. • In L , OH(x) returns the image of x by hash(k, ·). 1 The novelties with respect to [50] are the use of keyed This oracle can be called at most n times for each hash functions, the oracle Oeq, and the modifier [unique]. hash function, and its calls are indexed by i ∈ [1, n], as We believe that using keyed hash functions leads to a better defined by foreach i ≤ n do. We can replace this oracle modeling of random oracles, for several reasons: with a random oracle, that is, an oracle that returns a fresh random number when it is called with a new • In the random oracle model, the adversary cannot argument, and the previously returned result when it evaluate the hash function by himself, without calling is called with the same argument as in a previous call. the random oracle. With the key, this is natural, since Such a random oracle is implemented in R1 as follows. the adversary does not have the key, whereas in the Like all variables defined under foreach i ≤ n, x is in absence of key, this is counterintuitive: the adversary fact an array indexed by i, so that x[u] represents the should be able to reproduce the algorithm of h. value of x in the u-th call to OH. The find construct • In the absence of key, the transformation of L1 into R1 looks for an index u such that x[u] and r[u] are defined, above replaces a deterministic function h with a prob- and x = x[u], that is, the current argument of OH is the abilistic one, since the results are chosen randomly in same as the argument in the u-th call, and if we find the right-hand side. The key removes this discrepancy: one, then we return the result of the u-th call, r[u]. with the key, the hash oracle is also probabilistic in the Otherwise, we return a fresh random number r. left-hand side thanks to the choice of the key. • The oracle Oeq aims to optimize the treatment of • The transformation of L1 into R1 above is correct only comparisons with the result of the hash function, an when it is applied to all occurrences of h simultane- operation that appears frequently. In L1, the oracle ously. In the absence of key, this has to be enforced by 0 0 0 0 Oeq(x , r ) compares r with hash(k, x ). In R1, this an additional constraint on the transformation. With the comparison is replaced with a lookup in previous key, this is naturally enforced, since all occurrences of calls to the hash function. If x0 was already given the key need to be encoded as calls to the oracles of 0 as argument to hash(k, ·), in the u-th call (x = L1 for the transformation to be performed. 0 0 x[u]), then hash(k, x ) is r[u], so we compare r with • Finally, keyed hash functions are used in the mod-

5 R L2 = foreach ick ≤ nck do ck ← cipherkey; (foreach ie ≤ ne do Oenc(me : blocksize, ke : key) := return(enc(ck, me, ke)) | foreach id ≤ nd do Odec(md : blocksize, kd : key) := return(dec(ck, md, kd)))

R2 = foreach ick ≤ nck do (foreach ie ≤ ne do Oenc(me : blocksize, ke : key) := find[unique] j ≤ ne suchthat defined(me[j], ke[j], re[j]) ∧ me = me[j] ∧ ke = ke[j] then return(re[j]) ⊕ k ≤ ne suchthat defined(rd[k], md[k], kd[k]) ∧ me = rd[k] ∧ ke = kd[k] then return(md[k]) else re ←R blocksize; return(re) | foreach id ≤ nd do Odec(md : blocksize, kd : key) := find[unique] j ≤ ne suchthat defined(me[j], ke[j], re[j]) ∧ md = re[j] ∧ kd = ke[j] then return(me[j]) ⊕ k ≤ nd suchthat defined(rd[k], md[k], kd[k]) ∧ md = md[k] ∧ kd = kd[k] then return(rd[k]) else rd ←R blocksize; return(rd))

Figure 3. Ideal cipher model

eling of other assumptions on hash functions, such (me = rd[k]) using the same key (ke = kd[k]) and, if as collision resistance. By always using keyed hash we find one, we return the corresponding ciphertext md[k]. functions, we can easily change the assumption on the Otherwise, we return a fresh random ciphertext re. This hash function without changing its interface. definition does not yield random permutations, because the Designing CryptoVerif specifications of primitives requires random choices of re and rd may collide with each other some expertise. That is why the specifications for most and with previous values of me and md. Let us consider 0 common cryptographic primitives are grouped in a reusable a game R2 obtained from R2 by excluding such collisions. library. Therefore, CryptoVerif users generally do not have By adapting the reasoning used for the random oracle model 0 to design such specifications. in Section III-B, we can show that, in R2, there never exist several choices of j/k that satisfy the conditions of the finds C. The Ideal Cipher Model in Oenc and Odec, so these finds can be marked [unique] without modifying their behavior. The game L2 is perfectly The ideal cipher model [59] models block ciphers by indistinguishable from R0 , and R0 can be distinguished saying that encryption and decryption are two random 2 2 from R2 with probability at most p2 (the probability of the permutations, inverse of each other. This can be encoded collisions excluded in R0 ), so the adversary can distinguish in CryptoVerif similarly to the random oracle model: we 2 L2 from R2 with probability at most p2. replace encryption and decryption with lookups in previous encryption/decryption queries; if a previous query matches, D. The Computational Diffie-Hellman Assumption we return the previous result; otherwise, we return a fresh A classical intractability assumption in asymmetric cryp- random number. This is modeled by the equivalence L2 ≈p2 R2 where L2 and R2 are defined in Figure 3 and p2 = tography is the hardness of the Diffie-Hellman problem: let (#Oenc + #Odec)(#Oenc + #Odec − 1)/|blocksize|. The us be given a group G of prime order q, with a generator a b encryption and decryption functions map bitstrings of type g, and two random elements A = g and B = g ab blocksize to bitstrings of type blocksize; they take two keys with a, b ∈ [1, q − 1], compute CDHg(A, B) = g . The as additional arguments: the standard encryption/decryption Computational Diffie-Hellman (CDH) assumption claims that for any polynomial-time adversary A, Succcdh(A) = key of type key, but also a key of type cipherkey that models G the choice of the scheme itself (like the key of the hash Pr[A(G, g, A, B) = CDHg(A, B)] is negligible. More generally, we note Succcdh(t) the maximal success probability function in Section III-B). The games L2 and R2 define G two oracles Oenc and Odec, respectively the encryption for any adversary A within time t. and decryption oracles. In L2, they call the encryption and This assumption can be written in CryptoVerif as follows: decryption functions. In R2, they are replaced with lookups R R in previous encryption/decryption queries. For instance, for foreach i ≤ n do a ← Z; b ← Z; Oenc (OA() := exp(g, a) | OB() := exp(g, b) | oracle , we look for a previous encryption query of 0 0 the same cleartext (me = me[j]) under the same key foreach i ≤ n do ODDH(z : G) := (ke = ke[j]) and, if we find one, we return the same z = exp(g, mult(a, b))) ≈ cdh #ODDH×Succ (t+(n+#ODDH)τexp) ciphertext re[j]. We also look for a previous decryption G query that has returned as cleartext the cleartext to encrypt foreach i ≤ n do a ←R Z; b ←R Z;

6 R L3 = foreach ia ≤ na do a ← Z ;( by the indistinguishability between the two games presented OA() := return(exp(g, a)) | in Figure 4. In these two games, one generates na exponents Oa() := return(a) | a, nb exponents b and the adversary (any context) has access foreach iaDDH ≤ naDDH do to various oracles: OA and OB that return the group elements ODDHa(m : G, j ≤ nb) := associated to a, resp. b; Oa and Ob that return the exponents return(m = exp(g, mult(b[j], a)))) | a and b themselves; and Diffie-Hellman decisions oracles R ODDHa and ODDHb that check whether the adversary foreach ib ≤ nb do b ← Z ;( correctly solved a Diffie-Hellman problem with the above OB() := return(exp(g, b)) | generated elements. Basically, the difference between the Ob() := return(b) | two games is in the answers of the decision oracles: in foreach ibDDH ≤ nbDDH do the first game they answer correctly, while in the second ODDHb(m : G, j ≤ na) := game, they answer false if the adversary did not ask for return(m = exp(g, mult(a[j], b)))) any of the two exponents. Unless the adversary can break

R the Diffie-Hellman problem, and then ask correct Diffie- R3 = foreach ia ≤ na do a ← Z ;( Hellman decision queries, the two executions are perfectly OA() := return(exp(g, a)) | indistinguishable. In more detail, in R3, the variable ka Oa() := let ka : bitstring = mark in return(a) | is defined if and only if the oracle Oa has been called foreach iaDDH ≤ naDDH do and thus the exponent a has been asked by the adversary. ODDHa(m : G, j ≤ nb) := All variables and oracles defined under foreach ia ≤ na find u ≤ nb suchthat defined(kb[u], b[u]) are implicitly indexed by ia, so that ka[ia] is defined if ∧ b[j] = b[u] then and only if a[ia] has been asked by the adversary. The return(m = exp(g, mult(b[j], a))) variable kb plays the same role for b. The oracle ODDHa else if defined(ka) then computes the equality test m = ga[ia]b[j] when b[j] has return(m = exp(g, mult(b[j], a))) been asked by the adversary, i.e., kb[j] is defined, or a[ia] else return(false)) | has been asked by the adversary, i.e. ka[ia] (abbreviated foreach ib ≤ nb do b ←R Z ;( ka) is defined. Otherwise, it returns false. The condition OB() := return(exp(g, b)) | “kb[j] is defined” is encoded as “kb[u] is defined for some Ob() := let kb : bitstring = mark in return(b) | u such that b[u] = b[j]”(defined(kb[u], b[u]) ∧ b[j] = b[u]), foreach ibDDH ≤ nbDDH do because CryptoVerif allows to reference a variable x[˜u] in ODDHb(m : G, j ≤ na) := defined conditions in the right-hand side of an equivalence (symmetric of ODDHa) only when its indices u˜ are a prefix of the indices looked up by find, so a reference to kb[j] would not be allowed. Figure 4. Computational Diffie-Hellman assumption We can refer to b[j] without including it in a defined condition because it also occurs in the left-hand side of the equivalence, so CryptoVerif knows that it must be defined. (OA() := exp(g, a) | OB() := exp(g, b) | That is why the condition defined(kb[u], b[u]) ∧ b[j] = b[u] foreach i0 ≤ n0 do ODDH(z : G) := false) is accepted by CryptoVerif. In Appendix B-A, we formally prove that L3 ≈p R3, ∗ 3 The type Z represents [1, q − 1], that is, the group Zq ; mult that is, no adversary can distinguish the two games L3 and is the product in that group; G represents the group G R3, within time t, with advantage greater than without its neutral element; and exp is the exponentiation G × Z → G. These two games define three oracles: OA p3 = (#ODDHa + #ODDHb) and OB return the exponentials ga and gb respectively, and × max(1, 7.4#Oa) × max(1, 7.4#Ob) the oracle ODDH checks whether its argument z is equal cdh × Succ (t + (na + nb + #ODDHa + #ODDHb)τexp). to gab in the left-hand side while it always returns false in G the right-hand side. The adversary can distinguish these two The proof technique consists in guessing the two elements a games if and only if it can provide a z such that z = gab, that and b that will be involved in the critical decisional Diffie- is, it breaks the CDH assumption. However, in CryptoVerif, Hellman query (but with Coron’s improvement [60]), and this model requires that a and b be chosen one after the then to guess the critical query, hence the factor #ODDHa+ other under the same foreach: while this is true in some #ODDHb. cryptographic schemes such as ElGamal, this is not true for For this equivalence to be supported by CryptoVerif, we most protocols: as in OEKE, a and b are chosen by different had to implement two extensions: protocol participants that can each execute several sessions. • Oracles ODDHa and ODDHb take as argument an array Therefore, we need a more general model, which is given index j, which was not supported.

7 • In typical usages of the CDH assumption in proto- UkSkXkY ukK u. These oracles are implicitly indexed by cols, gab is often an argument of a hash function iU , so that they can be written OC1[iU ], OC2[iU ]. (This in the random oracle model. The transformation that index is omitted in CryptoVerif code for readability.) The comes from the random oracle model, presented in adversary can call the oracles with any index it likes in the Section III-B, transforms hash(. . . gab ...) into lookups order it likes, except that, obviously, OC2[iU ] can be called that compare gab with previous arguments of hash. only if OC1[iU ] has been called before with the same iU . These comparisons m = gab, which occur in conditions This gives the adversary full control over the network. of find, are themselves transformed into find using the We represent NS sessions of the server in a similar way. CDH assumption. We therefore end up with a find The NU sessions of the client and the NS sessions of inside the condition of a find, which was not supported. the server model active attacks. Additionally, we represent In addition to the modeling of the CDH assumption itself, NP sessions of the protocol in which the adversary just our model of Diffie-Hellman key agreements includes further eavesdrops messages without altering them. In order to properties, such as commutativity and injectivity of several represent such sessions, we simply compute and output their functions. They are formally defined in Appendix B-B. We transcript. They model passive attacks. Since we are con- stress that our above modeling is not specific to the OEKE sidering dictionary attacks against a password-authenticated protocol. We have also used it to prove a signed Diffie- key exchange protocol, it is important to distinguish passive Hellman key exchange, and we believe that it can be used sessions/attacks from active ones against the honest players. for proving many other protocols. E. The Protocol Itself F. Security Properties If we consider a general configuration with several clients Our goal is to prove that OEKE is a secure key exchange and servers, each client-server pair shares a different pass- that provides unilateral (explicit) authentication. (OEKE word, and there is no other secret shared initially. Therefore, guarantees client authentication but not server authentica- different client-server pairs have no common secret, so we tion.) To do that, we follow the ideas of [61, Section 7.2]: can encode a single client U and a single server S that wish instead of proving semantic security of the key and au- to talk to each other; the other clients and servers, which thentication, we prove secrecy of the key on the client may be corrupted, and the interactions of U and S with side and a slightly stronger authentication property. This other clients and servers are included in the adversary. This technique avoids the burden of considering partnering when model supports static corruptions; dynamic corruptions and proving secrecy of the key and still implies authenticated forward secrecy properties are left for future work. key exchange [61, Proposition 4]: intuitively, authentication The protocol model first chooses random keys hk0 and guarantees that a key of the server is also a key of a client. hk1 to model the choice of the hash functions h0 (i.e. H0) Authentication is modeled by correspondence properties [62] and h1 (i.e. H1) respectively and a key ck to model the of the form “if some event occurs, then some other event oc- choice of the ideal cipher scheme. It also randomly chooses curred”. There are still two differences with respect to [61]: a password pw in the type passwd. Then, it makes available • [61] considers mutual authentication, while we consider hash oracles for h0 and h1, encryption and decryption unilateral authentication, so we remove the correspon- oracles, as well as oracles that represent the client and the dence that guaranteed authentication of the server. server. As an example, we detail the code for the client: • In [61], each protocol participant may interact with hon- foreach iU ≤ NU do est participants (U and S here) but also with dishonest OC1() := x ←R Z ; X ← exp(g, x); return(U,X); participants, and in the latter situation, the exchanged OC2(= S, Ystar u : G) := Y u ← dec(ck, Ystar u, pw); key is published when the participant accepts. As K u ← exp(Y u, x); mentioned in Section III-E, in OEKE, we need not code auth u ← h1(hk1 , concat(U, S,X, Y u, K u)); explicitly for U and S interacting with other clients and sk u : hash0 ← h0(hk0 , concat(U, S,X, Y u, K u)); servers, so the output of the exchanged key disappears. return(auth u) Taking into account these points, we add events to record This code models NU sessions of the client, indexed by that the participants accept or terminate: iU . Each session defines two oracles OC1 and OC2. OC1 • event acceptU(U, X , S, Ystar u, auth u, sk u) when takes no argument and returns the first message of the the client accepts (line “accept ← true” of the client protocol U,X computed as specified in Figure 1. OC2 in Figure 1, that is, before the last line in the code of takes as argument the second message of the protocol Section III-E). S, Ystar u received by the client and returns the third • event termS(U, X s, S, Ystar, auth s, sk s) when one auth u. It also computes the shared key sk u. In the server terminates (line “terminate ← true” of the this code, concat(U, S,X, Y u, K u) is the concatenation server in Figure 1).

8 and we prove that the resulting process preserves the secrecy other words, each session of the server that accepts with of sk u and satisfies the correspondences transcript U, X, S, Ystar, a and shared key k corresponds inj-event(termS(U, X, S, Ystar, a, k)) ⇒ to a distinct session of the client that accepts with the (1) same transcript and same key. It corresponds to the au- inj-event(acceptU(U, X, S, Ystar, a, k)) thentication of the client. The keyword inj-event is used event(termS(U, X, S, Ystar, a, k)) ∧ in CryptoVerif to require injective correspondences, that (2) event(acceptU(U, X, S, Ystar, a, k0)) ⇒ k = k0 is, acceptU has been executed at least as many times with public variables {sk u}. A variant of [61, Proposi- as termS, and not only once. The correspondence (2) means that when events termS(U, X, S, Ystar, a, k) and tion 4] allows us to conclude one-way authenticated key 0 0 exchange. Next, we define secrecy and correspondences. acceptU(U, X, S, Ystar, a, k ) have been executed, k = k , Intuitively, the secrecy of sk u means that the keys that is, if a client and a server have the same transcript, sk u of all sessions of the client are indistinguishable from then they share the same key. These correspondences are independent random keys. Formally, secrecy is defined as proved “with public variables {sk u}”, that is, they hold follows: even when the adversary is allowed to access sk u directly. Formally, we write E ` ψ ⇒ ϕ when the sequence of events Definition 2 (Secrecy) Assume that the variable x of type E satisfies the correspondence ψ ⇒ ϕ. (This is formally T is defined in G under a single foreach i ≤ n. The game G defined in [61].) For instance, E ` inj-event(termS(U, X, S, preserves the secrecy of x up to probability p when, for all Ystar, a, k)) ⇒ inj-event(acceptU(U, X, S, Ystar, a, k)) if contexts C acceptable for G | Rx without public variables and only if, for each event acceptU(...) in E, there is a that do not contain S and S, Pr[C[G | Rx]: S] − Pr[C[G | distinct event termS(...) in E with the same arguments as Rx]: S] ≤ p(C) where the event acceptU(...). R Rx = O0() := b ← bool; return; G satisfies the 0 0 Definition 3 (Correspondence) The game (foreach i ≤ n do O(u : [1, n]) := correspondence ψ ⇒ ϕ with public variables V up to if defined(x[u]) then probability p if and only if, for all contexts C acceptable if b then return(x[u]) else G V 0 0 0 0 for with public variables that do not contain events, find u ≤ n suchthat defined(y[u ], u[u ]) ∧ Pr[C[Q]: D] ≤ p(C), where D(E, a) = (E 6` ψ ⇒ ϕ). u[u0] = u then return(y[u0]) else y ←R T ; return(y) IV. PROVING OEKE IN CRYPTOVERIF | O0(b0 : bool) := if b = b0 then event S; abort In the previous section, we have presented the formal- else event S; abort) ization of the protocol given as input to CryptoVerif. In this section, we explain how CryptoVerif proceeds with the O ,O,O0, b, b0, u, u0, y, S, and S do not occur in G. 0 proof. Some parts of the proof are automatic, some are We define the secrecy of x with the Real-or-Random model guided by the user. The commands for guiding CryptoVerif of [63]: in Rx, we choose a random bit b, and provide the can be given interactively, which allows one to see the oracle O that the adversary can use to perform several test current game and understand what should be done next, or queries on x[u]: if b = 1, the test query returns x[u]; if b = 0, in a proof {...} declaration in the CryptoVerif input file, so it returns a random value y (the same value if the same query that CryptoVerif can then run on its own. The input file pre- x[u] is asked twice). Finally, the adversary should guess the sented at http://www.cryptoverif.ens.fr/OEKE/ includes such bit b: it calls oracle O0 with its guess b0 and, if the guess a declaration. We stress that, even with manual guidance, all is correct, then event S is executed, and otherwise, event S game transformations are verified by CryptoVerif, so that is executed. The probability of getting some information on one cannot perform an incorrect proof. the secret is the difference between the probability of S and the probability of S. (When the game always runs oracle A. Applying Shoup’s Lemma 0 O , we have Pr[C[G | Rx]: S] = 1 − Pr[C[G | Rx]: S], The first step of the proof is to introduce the events so the advantage of the adversary is Pr[C[G | Rx]: S] − Auth and Encrypt, which correspond to cases in which the Pr[C[G | Rx]: S] = 2 Pr[C[G | Rx]: S] − 1, which is adversary succeeds in testing a password and were also used a more standard formula.) As shown in [63], the Real-or- in the manual proof of [55]. Random model is stronger than the Find-Then-Guess model By Shoup’s lemma [43], if G0 is obtained from G by used in [55], which allows a single test query and several inserting an event e and modifying the code executed after reveal queries. (Reveal queries always return the real x[u].) e, the probability of distinguishing G0 from G is bounded by The correspondence (1) means that each execution of the probability of executing e: for all contexts C acceptable event termS(U, X, S, Ystar, a, k) corresponds to a dis- for G and G0 (with any public variables) and all distinguish- tinct execution of event acceptU(U, X, S, Ystar, a, k); in ers D, | Pr[C[G]: D] − Pr[C[G0]: D]| ≤ Pr[C[G0]: e].

9 0 0 Hence, Pr[C[G]: D] ≤ Pr[C[G ]: e] + Pr[C[G ]: D]. We by Lemma 1, while Pr[C[G0]: e0] ≤ 2p(C, tD) by the improve over this computation of probabilities by consider- standard computation, so we have gained a factor 2. ing e and D simultaneously instead of making the sum of For secrecy, the advantage Pr[C[G | Rx]: S] − Pr[C[G | 0 {x} the two probabilities: Pr[C[G]: D] ≤ Pr[C[G ]: D ∨ e]. Rx]: S] introduces a factor 2 in the probability: if G ≈p 0 G , then Pr[C[G | Rx]: S] − Pr[C[G | Rx]: S] ≤ 2p(C[[ ] | R ], t ) + (Pr[C[G0 | R ]: S] − Pr[C[G0 | R ]: S]), since Lemma 1 Let C be a context acceptable for G and G0 with x S x x t = t . The next lemma avoids this factor 2 for probabilities public variables V . S S of events: 1) If G0 differs from G only when G0 executes event e, 0 then Pr[C[G]: D] ≤ Pr[C[G ]: D ∨ e]. 0 0 Lemma 2 Let C be a context acceptable for G and G 2) If G differs from G only when G executes event with public variables V . Let the distinguishers D,D0 be NonUnique and D = (D0∧¬NonUnique)∨e1∨...∨en disjunctions of events e1 ∨ ... ∨ en such that we abort just where we abort just after executing events e1, . . . , en, after executing each e . Let AdvSecrecy(C,D) = Pr[C[G | then Pr[C[G]: D] ≤ Pr[C[G0]: D]. i G V 0 Rx]: S ∨ D] − Pr[C[G | Rx]: S ∨ NonUnique]. 3) If G ≈p G , then Pr[C[G]: D] ≤ p(C, tD) + 0 0 Pr[C[G0]: D]. 1) If G differs from G only when G executes 0 0 event e and we abort just after executing e, then 4) Pr[C[G]: D ∨ D ] ≤ Pr[C[G]: D] + Pr[C[G]: D ]. Secrecy Secrecy AdvG (C,D) ≤ AdvG0 (C,D ∨ e). 2) If G differs from G0 only when G executes NonUnique, This lemma, and Lemma 2 below, are proved in Ap- Secrecy Secrecy then AdvG (C,D) ≤ AdvG0 (C,D). pendix C. In order to bound the probability that a distin- V 0 Secrecy D G 3) If G ≈p G , then AdvG (C,D) ≤ 2p(C[[ ] | guisher 0 returns true for some game 0, we consider Secrecy R ], t) + Adv 0 (C,D) where t = max(t , any context C acceptable for G0 with public variables V x G S∨D t ). and that does not contain events, and bound Pr[C[G0]: S∨NonUnique Secrecy 0 Secrecy D0 ∧ ¬NonUnique] which is equal to Pr[C[G0]: D0] 4) AdvG (C,D ∨ D ) ≤ AdvG (C,D) + Pr[C[G | 0 because no find[unique] occurs in the initial game. For Rx]: D ]. each game transformation, we assume that the introduced 5) If CryptoVerif proves the secrecy of x in game G, variables are fresh, so that C remains acceptable for all then Pr[C[G | Rx]: S] = Pr[C[G | Rx]: S], so Secrecy games of the sequence. We can then apply Lemma 1 for AdvG (C,D) ≤ Pr[C[G | Rx]: D]. each game transformation. Points 1, 2, and 3 of this lemma allow us to handle several events simultaneously, as long as In order to prove secrecy of x in the initial game G0, the proof uses the same sequence of games to bound their we bound Pr[C[G0 | Rx]: S] − Pr[C[G0 | Rx]: S] = AdvSecrecy(C, false), by applying Lemma 2 for each probabilities. Point 2 is useful for transformations that rely G0 on the uniqueness of the values that satisfy the conditions game transformation. When we apply points 4 and 5 of of find, detailed in Appendix E-B: these transformations this lemma, we use bounds on the probabilities of events, 0 preserve the behavior of the game when G does not execute Pr[C[G | Rx]: D ] and Pr[C[G | Rx]: D] respectively, event NonUnique. The distinguisher D is always of the which can be established using Lemma 1. (They can be written Pr[C[G | R ]:(false ∧ ¬NonUnique) ∨ D], so they desired form (D0 ∧¬NonUnique)∨e1 ∨...∨en because we x are of the form required by point 2 of Lemma 1.) These start from D0 ∧ ¬NonUnique and add events introduced by Shoup’s lemma using point 1; we abort immediately after probabilities are not multiplied by 2, so we improve over these events. When the proof uses different sequences of the standard computation of probabilities for secrecy. games to bound the probabilities of events, we use point 4 These improvements are implemented in CryptoVerif but of the lemma to bound each probability separately and also apply to manual proofs. For instance, by applying this compute the sum. The standard computation of probabilities result to the manual proof of OEKE [55], we obtain that corresponds to always applying point 4. the probability for any adversary to make a server instance For example, suppose that we want to bound the proba- accept with no terminating client partner is bounded by bility of event e0 in G0, G1 differs from G0 only when G1 NU + NS cdh 0 0 + qhSucc (t ) + p executes event e, G1 ≈p G2, and G2 executes neither e0 nor N G coll e. Suppose for simplicity that no find[unique] occurs, so that 2 2 0 (2qe + 2NU + 3NS + 3NP ) qh + 2NS with pcoll = + NonUnique never occurs. Lemma 1 yields Pr[C[G0]: e0] ≤ 2(q − 1) 2l1+1 Pr[C[G1]: e0 ∨ e] ≤ p(C, te0∨e) + Pr[C[G2]: e0 ∨ e] = and that no adversary can distinguish the session key from p(C, te0∨e). The standard computation of probabilities yields Pr[C[G0]: e0] ≤ Pr[C[G1]: e0] + Pr[C[G1]: e] ≤ a random key with advantage greater than p(C, te0 ) + p(C, te). The runtime tD of D is essentially the N + N U S + q Succcdh(t0) + 2p0 same for e0, e, and e0 ∨ e, so Pr[C[G0]: e0] ≤ p(C, tD) N h G coll

10 with the notations of Section II. (The detailed computation to h1 with lookups in the previous queries to h1. All is in Appendix D.) For both properties, the first term queries to h1 in the protocol have an argument of the NU +NS 0 0 0 0 0 of the probability N shows that the adversary can form concat(x1 , x2 , x3 , x4 , x5 ). When comparing test at most one password for each interaction with the this query to a query in the hash oracle, the compari- client or the server, which is the optimal result, while the son h1x = concat(x1 0, x2 0, x3 0, x4 0, x5 0) can then be standard evaluation of probabilities given in Section II yields simplified as follows: NU +2NS 2NU +4NS N for the first property and N for the second – If h1(h1x) was computed in the in branch one. Similar improvements could also be obtained for the of the introduced let, the comparison becomes AuthA protocol [55, Section 4.1] and for the forward secrecy concat(x1 , x2 , x3 , x4 , x5 ) = concat(x1 0, x2 0, property [55, Appendix D]. x3 0, x4 0, x5 0), that is, x1 = x1 0 ∧ ... ∧ x5 = x5 0. 1) Inserting events: In order to introduce events, we have – If h1(h1x) was computed in the else branch of this implemented a new game transformation in CryptoVerif: let, the comparison becomes false, because h1x insert event e o inserts event e; abort at program point o. cannot be of the form concat(...), since the in The program point o is an integer, which can be determined branch would have been taken in that case. using the command show game occ: this command displays • crypto rom(h1) applies the equivalence L1 ≈p1 R1 of the current game with the corresponding label {o} at each Figure 2, designated by rom for Random Oracle Model, program point. The command show game occ also allows to the hash function h1: it transforms calls to h1 into one to inspect the game, for instance to know the names lookups in the previous queries to h1, as outlined in of fresh variables created by CryptoVerif during previous Section III-B. transformations. Program points and variable names may 3) Event Auth: Next, we introduce event Auth: This depend on the version of CryptoVerif; this paper uses event corresponds to the case in which the group element CryptoVerif 1.14. CryptoVerif cannot guess where events X received by the server (denoted X s) does not come should be introduced, so the command insert event must from the client, the authenticator Auth received by the server be manually given to the tool. (denoted auth s) comes from a hash query by the adversary, We have also defined a command insert o ins which and authentication still succeeds. To be able to introduce this adds instruction ins at the program point o. The instruction event, we first make the program point appear, at which this ins can for instance be a test, in which case all branches event will be inserted: of the test will be copies of the code that follows program point o (so that the semantics of the game is unchanged). It • insert 179 “find j ≤ NU suchthat defined(X[j]) ∧ can also be an assignment or a random generation of a fresh X[j] = X s then” inserts a test after receiving the variable. In all cases, CryptoVerif checks that this instruction authenticator in the server, to distinguish the case in preserves the semantics of the game, and rejects it with an which X s comes from the client (X s = X[j] for error message if it does not. some j). 2) Transformations for h1: At the beginning of the proof, • insert 341 “find jh ≤ qH1 suchthat defined(x1 [jh], we transform the game using the random oracle assumption x2 [jh], x3 [jh], x4 [jh], hash1[jh])∧(U = x1 [jh])∧(S = for h1. This transformation helps us make a program point x2 [jh]) ∧ (X s = x3 [jh]) ∧ (Y = x4 [jh]) ∧ (auth s = appear at which we will next insert an event. Before actually hash1[jh]) then” inserts a test, in the else branch of the performing this transformation, we first introduce a case previous one, to detect when authentication succeeds distinction that leads to a simpler game after applying the with an authenticator auth s that comes from a hash random oracle assumption: query made by the adversary. The result of that hash query2 is hash [jh] and its arguments are x1 [jh],..., • By command insert 261 “let concat(x1 , x2 , x3 , x4 , 1 x5 [jh] x5 ) = h1x in”, we introduce a let in the hash oracle for . We purposely do not test that the 5-th argument h1. As the result, this hash oracle becomes OH1(h1x : of the hash query is the expected one. This avoids bitstring) := let concat(x1 , x2 , x3 , x4 , x5 ) = h1x in computing an exponentiation exp(X s, y) where X s y return(h1(hk1 , h1x)) else return(h1(hk1 , h1x)): the comes from the adversary and is a secret exponent, Ob meaning of this let construct is that, if h1x is of the thus removing a query to in the CDH equivalence. • Auth form concat(x1 , x2 , x3 , x4 , x5 ), then the in branch insert event 384 inserts the event itself in the is taken with x1 , x2 , x3 , x4 , x5 bound to their value then branch of the previous test. (which is uniquely determined because the length of the • Finally, simplify cleans up the obtained game. The jh fields of the concatenation is fixed); otherwise, the else else branch of the find inserted above is removed: in branch is taken. Thus, we distinguish cases depending that branch, authentication always fails so the protocol on whether h1x is of the form concat(...) or not. executes nothing. In the next transformation, which applies the random 2 In CryptoVerif 1.14, the variable hash1 is in fact named @11 r 134 . oracle assumption to h1, we are going to replace calls We have renamed it to hash1 for readability.

11 4) Event Encrypt: Next, we introduce the event Encrypt: random value independently of the value of Yp, so This event corresponds to the case in which the value Yp is also used only in comparisons with previous Y ? received by the client (denoted Ystar u) comes from encryption/decryption queries. an encryption query of the adversary under the correct • The value of Y in the server is also a fresh random password. As above, we have to prepare this insertion: group element; it is used in the test that decides whether • crypto icm(enc) applies the equivalence that repre- to execute event Auth and in comparisons with previous sents the Ideal Cipher Model, designated by icm, to encryption/decryption queries. the encryption scheme enc: it replaces calls to encryp- We have implemented new game transformations in Cryp- tion/decryption with lookups in previous queries, as toVerif, detailed in Appendix E, to handle this situation: outlined in Section III-C. • move array X delays the generation of a random value • insert event Encrypt 633 inserts the event Encrypt X until the point at which it is first used. when the lookup in previous encryption/decryption • merge arrays x11 . . . x1n, . . . , xm1 . . . xmn merges queries that comes from the decryption of Ystar u the variables xj1, . . . , xjn into a single variable xj1 for succeeds with an encryption query of the adversary. each j ≤ m. Each variable xjk must have a single 5) Transformations for h0: We proceed for h0 similarly definition. For each j ≤ n, the variables xj1,..., to what we did for h1 at the beginning of the proof: xjn must have the same type and indices of the same • insert 1251 “let concat(x01 , x02 , x03 , x04 , x05 ) = type. They must not be defined for the same value of h0x in” distinguishes cases depending on whether the their indices (that is, xjk and xjk0 must be defined in 0 argument h0x of the hash oracle for h0 is of the form different branches of if or find when k 6= k ), so that concat(...) or not. they can be merged into a single array. • crypto rom(h0) applies the random oracle assumption • merge branches merges branches of if and find when to h0 (Section III-B). they execute the same code. Using these transformations, we can eliminate the random B. Automatic Steps number generations for Y as outlined at the beginning of After distinguishing cases for h0 and h1 and introducing this section. We consider the three generations of Y in turn. events, we can use the automatic proof strategy of Cryp- For each of these generations, we first apply move array toVerif, by command auto. Basically, this strategy consists to the corresponding variable, to delay its generation. For in applying all possible cryptographic transformations (com- OEKE, this has the effect of generating it in the decryption ing from equivalences L ≈p R) and simplifying the game oracle available to the adversary. So, in this oracle, we end after each such transformation. When the transformations up with two possibilities of generating a fresh result, the one fail, they advise syntactic transformations that could make that comes from the delayed generation of Y , say Y 0, and them succeed; these transformations are executed and the the one that corresponds to the situation in which the query cryptographic transformation is then retried [49, Section 5]. is really a fresh decryption query, say Yd. We would like More precisely, in our case, CryptoVerif renames several to merge these two cases by merge branches. However, variables and simplifies terms, in order to be able to apply merge branches does not succeed directly: we first need to 0 the CDH assumption (Section III-D). Details are provided in merge the two variables Yd and Y into a single variable by 0 Appendix F. After these transformations, no automatic step merge arrays Yd Y , then we can apply merge branches. can be performed, so the automatic proof stops. In the case of the value of Y in the server, we additionally need to rewrite the condition that triggers the event Auth C. Reorganizing Random Number Generations for merge branches to succeed. This is done by a few We end up in a situation in which random values for Y are manual commands, checked correct by CryptoVerif. In this generated, but are used only in comparisons with previous process, the event Auth is renamed into Auth2. These steps queries. We would like to delay or remove these random are detailed in Appendix F. number generations. This situation occurs at three places: D. The Final Computation of Probabilities • When Y u (the value of Y in the client) is a fresh In the obtained game, the events Auth2 and Encrypt are random group element, auth u and K u are also fresh guarded by the following conditions (variables have been random values, independently of the value of Y u, renamed for readability): so Y u is used only in comparisons with previous encryption/decryption queries. (foreach iU ≤ NU do ... • The value of Y in the passive eavesdroppings, Yp, find[unique] je ≤ qE suchthat defined(re[je], ke[je]) ∧ is a fresh random group element; the encryption Y ? Ystar u = re[je] ∧ pw = ke[je] then event Encrypt ...) of Y is thus also a fresh random group element by | (foreach iS ≤ NS do ... the ideal cipher model, and the hash queries return a find jh0 ≤ qH1 , jd ≤ qD suchthat defined(x1 [jh0],

12 0 0 0 0 x2 [jh ], x3 [jh ], x4 [jh ], hash1[jh ], m[jd], kd[jd], that OEKE preserves the secrecy of sk u up to probability rd[jd]) ∧ m[jd] = Y star ∧ U = x1 [jh0] ∧ 0 0 0 NS + NU cdh 0 00 S = x2 [jh ] ∧ X s = x3 [jh ] ∧ rd[jd] = x4 [jh ] ∧ + (2qH0 + 3qH1 )Succ (t ) + 2pcoll 0 |passwd| G auth s = hash1[jh ] ∧ kd[jd] = pw then event Auth2 ...) | ... and satisfies the correspondences (1) and (2) with public variables {sk u} up to probability So, in order to bound the probabilities of these events, we just have to eliminate collisions between the password pw NS + NU cdh 0 00 + (4qH0 + 6qH1 )Succ (t ) + pcoll and the encryption and decryption keys, ke[je] and kd[jd]. |passwd| G This is done by the command simplify coll elim pw. where t0 = t+(2qH0 +3qH1 +qD +2NU +2NP +NS)τ The collisions on pw are not eliminated automatically by exp and the terms in p00 come from elimination of collisions CryptoVerif because the type passwd of pw is declared coll between hashes and between group elements: p00 ≤ (NS + with annotation password. This annotation allows manual coll NU + qH1 × NU + qH1 2)/|hash1 | + (qD × NU × NP + elimination of collisions but prevents automatic elimination NU 2 ×NP +qD ×NU ×NS +NU 2 ×NS +2qH1 ×NP + of collisions. For passwords, whose set is not very large, the 4qE ×NP +4qE ×NS +4NP 2 +3NS 2 +2.5qD 2 +9NP × automatic elimination of collisions would yield a too large NU + 9NU × NS + 7NS × qD + 6NP × qD + 10NS × probability bound. NP + 12.5NU 2 + 2qD × qE + qH1 × NU + 2qH0 × NU + We have to evaluate the probability of these collisions. A 4NU ×qD +3NU ×qE +1.5qE 2 +6NS +10NU )/|G|. The naive evaluation considers that one makes at most NU ×qE main term in this probability is (NS + NU )/|passwd|: the comparisons pw = ke[je] (there are NU sessions of the adversary can test at most one password per session with the client and the condition of find is evaluated at most qE client or the server (active attack), which is the best bound times) and similarly at most NS × qH1 × qD comparisons we can hope. In contrast, [55] yields a bound of at most 4 kd[jd] = pw, which yields the probability (NU × qE + passwords per session. In Section IV-A, by applying our im- NS × qH1 × qD)/|passwd|. A slightly more clever way is provement of the computation of probabilities to the manual to notice that pw = ke[je] contains as only index je ≤ qE, proof of [55], we obtained the same first term as CryptoVerif, so at most qE distinct comparisons are performed (there and even better second and third terms. CryptoVerif obtains are at most qE distinct encryption keys), and similarly at a second term larger than in Section IV-A because it counts most qD distinct comparisons kd[jd] = pw, which yields several Diffie-Hellman queries, which in fact correspond to the probability (qE +qD)/|passwd|. This is not satisfactory the same query, and because the CDH assumption does not yet, because the encryption and decryption queries can be benefit from the improvement of Lemma 2, points 4 and 5: performed by the adversary without interacting with the the probability of breaking CDH is taken into account using protocol, so qE and qD can be large. So we have extended Lemma 2, point 3, so it is multiplied by 2. CryptoVerif to improve this probability bound. We start from the most naive evaluation NU × qE and try to eliminate V. CONCLUSION each factor. We can eliminate NU as shown above, but We have proved the security of OEKE using the tool we can also eliminate qE: for each session of the client, CryptoVerif. This proof provides additional confidence that Ystar u is fixed; since Ystar u = re[je], re[je] is also the protocol is correct. Moreover, we have improved the fixed. By eliminating collisions on re, there is a unique je probability bound given in [55]: we have shown that the that can make the comparison Ystar u = re[je] succeed, adversary can test at most one password per session with so a unique je for which the comparison pw = ke[je] the client or with the server, which is the optimal result. is performed. Similarly, the comparison kd[jd] = pw is OEKE is a non-trivial case study, which is interesting on performed at most once for each session of the server. its own. It was also an opportunity to implement many Thus we obtain the probability (NU + NS)/|passwd|. To extensions to CryptoVerif, which will be useful for proving know which factors we should preferably eliminate, we many other protocols. We have already used the model of annotate qE and qD with noninteractive, which means CDH to prove a signed Diffie-Hellman protocol. We plan to that the adversary can perform the corresponding queries apply these extensions to other protocols, such as IKEv2 or without interacting with the protocol, so qE and qD will SSH, which also rely on Diffie-Hellman. Our improvement typically be larger than other bounds. Therefore, the bound of the computation of probabilities is also of general interest, (NU + NS)/|passwd| is better than (qE + qD)/|passwd|, and applies to manual proofs as well as CryptoVerif proofs. so CryptoVerif returns the former. Acknowledgments: We thank David Pointcheval for his CryptoVerif then concludes that the events Encrypt and advice and help during this project. This work was partly Auth2 can be executed with probability at most (NU + supported by the ANR project ProSe (decision number NS)/|passwd| in the last game. Finally, CryptoVerif shows ANR-2010-VERS-004-01).

13 REFERENCES [17] V. Cortier, S. Kremer, and B. Warinschi, “A survey of symbolic methods in computational analysis of cryptographic [1] B. Chor and R. L. Rivest, “A Knapsack type public key cryp- systems,” Journal of Automated Reasoning, vol. 46, no. 3–4, tosystem based on arithmetic in finite fields,” in CRYPTO’84, pp. 225–259, 2011. ser. LNCS, vol. 196. Springer, 1985, pp. 54–65. [18] V. Cortier, H. Hordegen,¨ and B. Warinschi, “Explicit random- [2] H. W. Lenstra Jr., “On the Chor-Rivest knapsack cryptosys- ness is not necessary when modeling probabilistic encryp- tem,” Journal of Cryptology, vol. 3, no. 3, pp. 149–155, 1991. tion,” in ICS 2006, ser. ENTCS, vol. 186. Elsevier, 2006, pp. 49–65. [3] S. Vaudenay, “Cryptanalysis of the Chor-Rivest cryptosystem,” in CRYPTO’98, ser. LNCS, vol. 1462. Springer, 1998, [19] M. Backes, B. Pfitzmann, and M. Waidner, “A composable pp. 243–256. cryptographic library with nested operations,” in CCS’03. ACM, 2003, pp. 220–230. [4] M. Bellare and P. Rogaway, “The exact security of digital signatures: How to sign with RSA and Rabin,” in EURO- [20] M. Backes and B. Pfitzmann, “Symmetric encryption in a sim- CRYPT’96, ser. LNCS, vol. 1070. Springer, 1996, pp. 399– ulatable Dolev-Yao style cryptographic library,” in CSFW’04. 416. IEEE, 2004, pp. 204–218.

[5] K. Ohta and T. Okamoto, “On concrete security treatment of [21] C. Sprenger, M. Backes, D. Basin, B. Pﬁtzmann, and signatures derived from identiﬁcation,” in CRYPTO’98, ser. M. Waidner, “Cryptographically sound theorem proving,” in LNCS, vol. 1462. Springer, 1998, pp. 354–369. CSFW’06. IEEE, 2006, pp. 153–166.

[6] M. Bellare and P. Rogaway, “Optimal asymmetric encryp- [22] C. Sprenger and D. Basin, “Cryptographically-sound tion,” in EUROCRYPT’94, ser. LNCS, vol. 950. Springer, protocol-model abstractions,” in LICS’08. IEEE, 2008, pp. 1994, pp. 92–111. 3–17.

[7] V. Shoup, “OAEP reconsidered,” Journal of Cryptology, [23] R. Canetti, “Universally composable security: A new vol. 15, no. 4, pp. 223–249, 2002. paradigm for cryptographic protocols,” in FOCS’01. IEEE, 2001, pp. 136–145. [8] E. Fujisaki, T. Okamoto, D. Pointcheval, and J. Stern, “RSA- OAEP is secure under the RSA assumption,” Journal of [24] R. Canetti and J. Herzog, “Universally composable symbolic Cryptology, vol. 17, no. 2, pp. 81–104, 2004. analysis of cryptographic protocols (the case of encryption- based mutual authentication and key exchange),” Cryptology [9] G. Barthe, B. Gregoire,´ S. Z. Beguelin,´ and Y. Lakhnech, ePrint Archive, Report 2004/334, 2004, available at http:// “Beyond provable security. Veriﬁable IND-CCA security of eprint.iacr.org/2004/334. OAEP,” in CT-RSA 2011, ser. LNCS, vol. 6558. Springer, 2011, pp. 180–196. [25] B. Blanchet, “Automatic proof of strong secrecy for security protocols,” in IEEE Symposium on Security and Privacy, [10] S. Halevi, “A plausible approach to computer-aided crypto- 2004, pp. 86–100. graphic proofs,” Cryptology ePrint Archive, Report 2005/181, 2005, http://eprint.iacr.org/. [26] J. C. Mitchell, A. Ramanathan, A. Scedrov, and V. Teague, “A probabilistic polynomial-time calculus for the analysis of [11] M. Abadi and P. Rogaway, “Reconciling two views of cryp- cryptographic protocols,” Theoretical Computer Science, vol. tography (the computational soundness of formal encryp- 353, no. 1–3, pp. 118–164, 2006. tion),” Journal of Cryptology, vol. 15, no. 2, pp. 103–127, 2002. [27] D. Nowak and Y. Zhang, “A calculus for game-based security proofs,” in ProvSec 2010, ser. LNCS, vol. 6402. Springer, [12] V. Cortier and B. Warinschi, “Computationally sound, auto- 2010, pp. 35–52. mated proofs for security protocols,” in ESOP’05, ser. LNCS, vol. 3444. Springer, 2005, pp. 157–171. [28] A. Datta, A. Derek, J. C. Mitchell, V. Shmatikov, and M. Tu- ruani, “Probabilistic polynomial-time semantics for a protocol [13] R. Janvier, Y. Lakhnech, and L. Mazare,´ “Completing the security logic,” in ICALP’05, ser. LNCS, vol. 3580. Springer, picture: Soundness of formal encryption in the presence 2005, pp. 16–29. of active adversaries,” in ESOP’05, ser. LNCS, vol. 3444. Springer, 2005, pp. 172–185. [29] A. Datta, A. Derek, J. C. Mitchell, and B. Warinschi, “Com- putationally sound compositional logic for key exchange [14] H. Comon-Lundh and V. Cortier, “Computational soundness protocols,” in CSFW’06. IEEE, 2006, pp. 321–334. of observational equivalence,” in CCS’08. ACM, 2008, pp. 109–118. [30] G. Barthe, M. Daubignard, B. Kapron, and Y. Lakhnech, “Computational indistinguishability logic,” in CCS’10. ACM [15] M. Backes, D. Hofheinz, and D. Unruh, “CoSP: A general Press, 2010, pp. 375–386. framework for computational soundness proofs,” in CCS’09. ACM, 2009, pp. 66–78. [31] R. Canetti, L. Cheung, D. Kaynar, M. Liskov, N. Linch, O. Pereira, and R. Segala, “Time-bounded task-PIOAs: A [16] V. Cortier and B. Warinschi, “A composable computational framework for analyzing security protocols,” in DISC’06, ser. soundness notion,” in CCS’11. ACM, 2011, pp. 63–74. LNCS, vol. 4167. Springer, 2006, pp. 238–253.

14 [32] P. Laud, “Secrecy types for a simulatable cryptographic [47] ——, “On formal verification of arithmetic-based crypto- library,” in CCS’05. ACM, 2005, pp. 26–35. graphic primitives,” in ICISC 2008, ser. LNCS, vol. 5461. Springer, 2008, pp. 368–382. [33] P. Laud and V. Vene, “A type system for computationally secure information flow,” in FCT’05, ser. LNCS, vol. 3623. [48] R. Affeldt, D. Nowak, and K. Yamada, “Certifying assembly Springer, 2005, pp. 365–377. with formal cryptographic proofs: the case of BBS,” in AVoCS’09, ser. Electronic Communications of the EASST, [34] G. Smith and R. Alp´ızar, “Secure information flow with vol. 23, 2009. random assignment and encryption,” in FMSE’06, 2006, pp. 33–43. [49] B. Blanchet, “A computationally sound mechanized prover for security protocols,” IEEE Transactions on Dependable and [35] J. Courant, C. Ene, and Y. Lakhnech, “Computationally Secure Computing, vol. 5, no. 4, pp. 193–207, 2008. sound typing for non-interference: The case of deterministic encryption,” in FSTTCS’07, ser. LNCS, vol. 4855. Springer, [50] B. Blanchet and D. Pointcheval, “Automated security proofs 2007, pp. 364–375. with sequences of games,” in CRYPTO 2006, ser. LNCS, vol. 4117. Springer, 2006, pp. 537–554. [36] M. Backes and P. Laud, “Computationally sound secrecy proofs by mechanized flow analysis,” in CCS’06. ACM, [51] P. Laud, “Handling encryption in an analysis for secure infor- 2006, pp. 370–379. mation flow,” in ESOP’03, ser. LNCS, vol. 2618. Springer, 2003, pp. 159–173. [37] J. Courant, M. Daubignard, C. Ene, P. Lafourcade, and Y. Lakhnech, “Towards automated proofs for asymmetric [52] ——, “Symmetric encryption in automatic analyses for confi- encryption schemes in the random oracle model,” in CCS’08. dentiality against active adversaries,” in IEEE Symposium on ACM, 2008, pp. 371–380. Security and Privacy, 2004, pp. 71–85.

[38] ——, “Automated proofs for asymmetric encryption,” in [53] I. Tsahhirovˇ and P. Laud, “Application of dependency graphs Concurrency, Compositionality, and Correctness, ser. LNCS, to security protocol analysis,” in TGC’07, ser. LNCS, vol. vol. 5930. Springer, 2010, pp. 300–321. 4912. Springer, 2007, pp. 294–311.

[39] G. Barthe, B. Gregoire,´ and S. Zanella, “Formal certiﬁcation [54] P. Laud and I. Tsahhirov,ˇ “A user interface for a game- of code-based cryptographic proofs,” in POPL’09. ACM, based protocol veriﬁcation tool,” in FAST2009, ser. LNCS, 2009, pp. 90–101. vol. 5983. Springer, 2009, pp. 263–278.

[40] G. Barthe, B. Gregoire,´ S. Heraud, and S. Z. Beguelin,´ [55] E. Bresson, O. Chevassut, and D. Pointcheval, “Security “Formal certiﬁcation of ElGamal encryption. A gentle intro- proofs for an efﬁcient password-based key exchange,” in duction to CertiCrypt,” in FAST 2008, ser. LNCS, vol. 5491. CCS’03. ACM, 2003, pp. 241–250. Springer, 2009, pp. 1–19. [56] S. M. Bellovin and M. Merritt, “Encrypted key exchange: [41] S. Z. Beguelin,´ B. Gregoire,´ G. Barthe, and F. Olmedo, “For- Password-based protocols secure against dictionary attacks,” mally certifying the security of digital signature schemes,” in in IEEE Symposium on Security and Privacy. IEEE, 1992, IEEE Symposium on Security and Privacy. IEEE, 2009, pp. pp. 72–84. 237–250. [57] M. Bellare and P. Rogaway, “The AuthA protocol [42] S. Z. Beguelin,´ G. Barthe, S. Heraud, B. Gregoire,´ and for password-based authenticated key exchange,” Mar. D. Hedin, “A machine-checked formalization of sigma- 2000, contributions to IEEE P1363. Available from protocols,” in CSF’10. IEEE, 2010, pp. 246–260. http://grouper.ieee.org/groups/1363/.

[43] V. Shoup, “Sequences of games: a tool for taming complex- [58] ——, “Random oracles are practical: A paradigm for design- ity in security proofs,” Cryptology ePrint Archive, Report ing efﬁcient protocols,” in CCS’93. ACM, 1993, pp. 62–73. 2004/332, 2004, available at http://eprint.iacr.org/2004/332. [59] M. Bellare, D. Pointcheval, and P. Rogaway, “Authenticated [44] M. Bellare and P. Rogaway, “The security of triple encryption key exchange secure against dictionary attacks,” in EURO- and a framework for code-based game-playing proofs,” in CRYPT 2000, ser. LNCS, vol. 1807. Springer, 2000, pp. EUROCRYPT 2006, ser. LNCS, vol. 4004. Springer, 2006, 139–155. pp. 409–426. [60] J.-S. Coron, “Security proof for partial-domain hash signature [45] G. Barthe, B. Gregoire,´ S. Heraud, and S. Z. Beguelin,´ schemes,” in CRYPTO 2002, ser. LNCS, vol. 2442. Springer, “Computer-aided security proofs for the working cryptogra- 2002, pp. 613–626. pher,” in CRYPTO 2011, 2011, to appear. [61] B. Blanchet, “Computationally sound mechanized proofs of [46] D. Nowak, “A framework for game-based security proofs,” correspondence assertions,” in CSF’07. IEEE, 2007, pp. 97– in ICICS 2007, ser. LNCS, vol. 4861. Springer, 2007, pp. 111, extended version available as ePrint Report 2007/128, 319–333. http://eprint.iacr.org/2007/128.

15 [62] T. Y. C. Woo and S. S. Lam, “A semantic model for M,N ::= terms authentication protocols,” in IEEE Symposium on Research i replication index in Security and Privacy, 1993, pp. 178–194. x[M1,...,Mm] variable access f(M1,...,Mm) function application [63] M. Abdalla, P.-A. Fouque, and D. Pointcheval, “Password- based authenticated key exchange in the three-party setting,” FC ::= find condition IEE Proceedings Information Security, vol. 153, no. 1, pp. M term 27–39, 2006. x[ei]: T ← M; FC assignment [64] V. Shoup, “Lower bounds for discrete logarithms and re- if defined(M1,...,Ml) ∧ M lated problems,” in EUROCRYPT’97, ser. LNCS, vol. 1233. then FC else FC0 conditional Springer, 1997, pp. 256–266. Lm find[unique?] ( j=1 uj1[ei] ≤ nj1, . . . , ujmj [ei] ≤ njmj (M ,...,M ) ∧ FC APPENDIX A. suchthat defined j1 jlj j 0 BASIC DEFINITIONS AND PROPERTIES then FCj) else FC array lookup This appendix recalls and sometimes adapts the definitions Q ::= oracle definitions of the basic concepts used by CryptoVerif. In CryptoVerif, 0 nil games are represented in a process calculus. A similar Q | Q0 parallel composition calculus was presented in detail in [49], using channels foreach i ≤ n do Q n parallel copies instead of oracles and asymptotic security instead of exact newOracle O; Q restriction for oracles security. The syntax of this calculus is recalled in Figure 5. O[ei](x1[ei]: T1, . . . , xk[ei]: Tk) := P oracle definition This calculus uses parameters, denoted by n, which rep- P ::= oracle body resent integer values. This calculus also uses types, denoted R by T , corresponding to subsets of bitstring ∪ {⊥} where x[ei] ← T ; P random choice bitstring is the set of all bitstrings and ⊥ is a special x[ei]: T ← M; P assignment symbol. We say that a type is large when its cardinal is if defined(M1,...,Ml) ∧ M large enough so that we can harmlessly eliminate collisions then P else P 0 conditional Lm between random values of this type. Particular types are find[unique?] ( j=1 uj1[ei] ≤ nj1, . . . , ujmj [ei] ≤ njmj predefined: bool = {true, false}, where false is 0 and true suchthat defined(Mj1,...,Mjlj ) ∧ FCj is 1; bitstring; bitstring⊥ = bitstring ∪ {⊥}; [1, n] where then Pj) else P array lookup n is a parameter. (We consider integers as bitstrings without event e(M1,...,Mm); P event leading zeroes.) (x1[ei]: T1, . . . , xk0 [ei]: Tk0 ) ← oracle call 0 The calculus also uses function symbols f. Each function O[M1,...,Ml](N1,...,Nk); P else P symbol comes with a type declaration f : T1×...×Tm → T , return(N1,...,Nk); Q return and represents a function from m-tuples of bitstrings or ⊥ end end in T1 × ... × Tm to a bitstring or ⊥. Particular functions abort abort are predefined, and some of them use the infix notation: M = N for the equality test, M 6= N for the inequality test C ::= contexts (both taking two values of the same type T and returning a [] hole value of type bool), M ∨ N for the boolean or, M ∧ N for C | Q parallel composition the boolean and, ¬M for the boolean negation (taking and Q | C parallel composition returning values of type bool). newOracle O; C restriction for oracles In this calculus, terms represent computations on bitstrings. The replication index i is an integer which serves Figure 5. Syntax of the process calculus in distinguishing different copies of a replicated process foreach i ≤ n do Q. (Replication indices are typically used as array indices.) The variable access x[M1,...,Mm] define new oracles. (An oracle definition Q follows the returns the content of the cell of indices M1,...,Mm of the return(N1,...,Nk) instruction.) m-dimensional array variable x. The function application The nil oracle definition 0 defines no oracle; Q | Q0 is 0 f(M1,...,Mm) returns the result of applying function f to the parallel composition of Q and Q : it makes available 0 M1,...,Mm. both oracles defined in Q and in Q ; foreach i ≤ n do Q The calculus distinguishes two categories of processes: represents n copies of Q in parallel, each with a different oracle definitions Q consist of a set of definitions of or- value of i ∈ [1, n]. The construct newOracle O; Q hides acles, while oracle bodies P describe the content of an oracle O outside Q: oracle O can be called only inside Q. oracle definition. Oracle bodies perform some computations The oracle definition O[ei](x1[ei]: T1, . . . , xk[ei]: Tk) := P and return a result. After returning the result, they may defines an oracle O, taking arguments x1, . . . , xk of types

16 T1,...,Tk respectively, and computed as described in oracle that a certain program point has been reached, with certain body P , where ei denotes a tuple i1, . . . , im. values of the arguments of the event. They do not influence R The random choice x[ei] ← T ; P chooses a new random the execution of the rest of the process. number uniformly in T , stores it in x[i], and executes The oracle call (x1[ei]: T1, . . . , xk0 [ei]: Tk0 ) ← O[M1, e 0 P . Function symbols represent deterministic functions, so ...,Ml](N1,...,Nk); P else P calls oracle O[M1,..., x[i] ←R T Ml] with arguments N1,...,Nk. When this oracle returns a all random numbers must be chosen by e . The 0 0 result by return(N ,...,N 0 ), this result is stored in x [i], assignment x[ei]: T ← M; P stores the bitstring value of 1 k 1 e M (which must be in T ) in x[i] and executes P . ..., xk0 [ei] and the process executes P . When the oracle e 0 Lm O[M1,...,Ml] terminates by end, the process executes P . Next, we explain the array lookup find ( uj1[ei] ≤ j=1 (Returning a result by return corresponds to the normal n , . . . , u [i] ≤ n suchthat defined(M ,...,M ) j1 jmj e jmj j1 jlj termination of the oracle O, while terminating with end ∧ FC then P ) else P . The order and array indices on j j corresponds to abnormal termination.) Finally, the instruc- tuples are taken component-wise, so for instance, uj1[ei] ≤ tion abort aborts the game: the whole game terminates n , . . . , u [i] ≤ n can be abbreviated u [i] ≤ n . j1 jmj e jmj ej e fj immediately and returns the special value abort. A simple example is the following: find u ≤ n suchthat 0 To lighten notations, ∧ true and defined() ∧ may be defined(x[u]) ∧ x[u] = a then P else P tries to find an omitted in conditions of if and find. Moreover, else end, a index u such that x[u] is defined and x[u] = a, and when 0 trailing 0, or a trailing end may be omitted. Types may be such a u is found, it executes P with that value of u; omitted when they can be inferred. otherwise, it executes P . In other words, this find construct The current replication indices at a certain program point looks for the value a in the array x, and when a is found, in a process are i , . . . , i when the considered program it stores in u an index such that x[u] = a. More generally, 1 m point is under foreach i ≤ n do ... foreach i ≤ find u [i] ≤ n , . . . , u [i] ≤ n suchthat defined(M , 1 1 m 1 e 1 m e m 1 n do . We abbreviate x[i , . . . , i ] by x when i , . . . , i ...,M ) ∧ FC then P 0 else P tries to find values of m 1 m 1 m l are the current replication indices, but it should be kept in u , . . . , u M ,...,M FC 1 m for which 1 l are defined and is mind that this is only an abbreviation. Similarly, an oracle P 0 true. In case of success, it executes . In case of failure, definition O[i , . . . , i ](...) := P under foreach i ≤ P m 1 m 1 it executes . This is further generalized to branches: n ... foreach i ≤ n is abbreviated O(...) := P . find (Lm u [i] ≤ n , . . . , u [i] ≤ n suchthat 1 m m j=1 j1 e j1 jmj e jmj Variables and oracles defined under foreach must be indexed defined(M ,...,M ) ∧ FC then P ) else P tries to j1 jlj j j by the current replication indices: for example foreach i ≤ j [1, m] u , 1 find a branch in such that there are values of j1 n do ... foreach i ≤ n do . . . x[i , . . . , i ]: T ← . . . , u for which M ,...,M are defined and FC is 1 m m 1 m jmj j1 jlj j M; ... true. In case of success, it executes P . In case of failure j We require some well-formedness invariants to guaran- for all branches, it executes P . More formally, it evaluates tee that several definitions of the same oracle cannot be the conditions defined(M ,...,M ) ∧ FC for each j j1 jlj j simultaneously available, that bitstrings are of their expected and each value of u [i], . . . , u [i] in [1, n ] × ... × j1 e jmj e j1 type, and that arrays are used properly (that each cell of an [1, n ]. If none of these conditions is true, it executes jmj array is assigned at most once during execution, and that P . Otherwise, it chooses randomly with (almost) uniform variables are accessed only after being initialized). Formally, probability one j and one value of u [i], . . . , u [i] such j1 e jmj e we require the following invariants: that the corresponding condition is true, and executes Pj. (When the number of possibilities is not a power of 2, a Invariant 1 (Single definition for oracles) The process probabilistic bounded-time Turing machine cannot choose Q satisfies Invariant 1 if and only if these values exactly with uniform probability, but it can 0 choose them with a probability distribution as close as 1) in every definition of O[i1, . . . , im] in Q0, the indices we wish to uniform.) Optionally, one may add a [unique] i1, . . . , im of O are the current replication indices at modifier to find, represented in Figure 5 by [unique?]. that definition, and When this modifier is present and there are several values of 2) two different definitions of the same oracle O in Q0 are in different branches of a find (or if). j, uj1[ei], . . . , ujmj [ei] such that the corresponding condition is true, we execute the event NonUnique and abort the game. The find conditions FC can themselves contain not only Invariant 1 guarantees that each oracle is defined at most terms but also assignments, conditionals, and array lookups. once for each value of its indices. (Indeed, item 2 shows that only one definition of each oracle can be available for The process if defined(M1,...,Ml) ∧ M then P else 0 given indices in each trace.) P is syntactic sugar for find suchthat defined(M1,..., 0 Ml) ∧ M then P else P . Invariant 2 (Single definition for variables) The process The construct event e(M1,...,Mm); P executes the Q0 satisfies Invariant 2 if and only if event e(M1,...,Mm), then executes P . Events just record

17 1) in every definition of x[i1, . . . , im] in Q0, the indices which set of bitstrings may appear at each point of the i1, . . . , im of x are the current replication indices at protocol. that definition, and These invariants are checked by the prover for the ini- 2) two different definitions of the same variable x in Q0 tial game and preserved by all game transformations. We are in different branches of a find (or if). suppose that all games satisfy these invariants. We use a context C to represent an adversary. A context Similarly to the previous invariant, Invariant 2 guarantees is a process with a hole. In this paper, we consider only that each variable is assigned at most once for each value evaluation contexts, generated by the grammar given at the of its indices. bottom of Figure 5. A context C is put around a process Q by C[Q]. This construct means that Q is put in parallel with Invariant 3 (Defined variables) The process Q0 satisfies some other process Q0 contained in C, possibly hiding some Invariant 3 if and only if every occurrence of a variable oracles defined in Q, so that, when considering C0[C[Q]], access x[M1,...,Mm] in Q0 is either C0 cannot call these oracles. • syntactically under the definition of x[M1,...,Mm] A context C is said to be acceptable for Q with public (in which case M1,...,Mm are in fact the current variables V if and only if the common variables of C and Q replication indices at the definition of x); are in V , and C[Q] satisfies the well-formedness invariants. • or in a defined condition in a find construct; We name Ostart the oracle called to start the experiment. 0 • or in FCj or Pj in a process of the form find We denote by Pr[Q : D] the probability that, for some 00 Lm 0 0 sequence of events E and bitstring a, when oracle Ostart() ( uj[i] ≤ nj suchthat defined(M ,...,M ) ∧ j=1 e e f j1 jlj 0 is called, Q executes exactly the sequence E, in the same FCj then Pj) else P where for some k ≤ lj, 0 order, and returns the result a, such that the algorithm x[M1,...,Mm] is a subterm of Mjk; 0 D(E, a) returns true. • or in FCj or FCj in a find condition of the form 00 Lm 0 We denote by var(Q) (resp. var(C)) the set of variables find ( j=1 uej[ei] ≤ nfj suchthat defined(Mj1,..., 0 0 of the process Q (resp. context C). M ) ∧ FC then FCj) else FC where for some jlj j The following lemma is a straightforward consequence of k ≤ l x[M ,...,M ] M 0 j, 1 m is a subterm of jk. Definition 1:

Invariant 3 guarantees that variables can be accessed only V Lemma 3 1) Q ≈0 Q. when they have been initialized. It checks that the definition V of the variable access is either in scope (first item) or 2) ≈p is symmetric. V 0 0 V 00 V 00 checked by the defined condition of a find (last two items). 3) If Q ≈p Q and Q ≈p0 Q , then Q ≈p+p0 Q . V 0 A variable access that does not correspond to the first item 4) If Q ≈p Q and C is a context acceptable for Q and 0 V 0 0 of Invariant 3 is called an array access. We furthermore Q with public variables V , then C[Q] ≈p0 C[Q ], 0 0 0 0 require the following invariant. where p (C , tD) = p(C [C[ ]], tD) and V ⊆ V ∪ var(C). Invariant 4 (Variables defined in find conditions) The APPENDIX B. process Q satisfies Invariant 4 if and only if the variables 0 THE COMPUTATIONAL DIFFIE-HELLMAN ASSUMPTION defined in conditions of find have no array accesses. A. Proof of the Reduction This invariant did not appear in previous versions of the First, let us rephrase the two games: calculus because conditions of find were restricted to be G1: the adversary is allowed to query terms. • for group elements, via oracles OA and OB: We use a type system (see [49, Appendix A]) to check OA[i]()3 provides a gai element for a random a that bitstrings of the proper type are passed to each function i (at most na queries), and OB[j]() provides a gbj and that array indices are used correctly. element for a random bj (at most nb queries); • for discrete logarithms, via oracles Oa and Ob: Invariant 5 (Typing) The process Q0 satisfies Invariant 5 Oa[i]() outputs ai (at most #Oa ≤ na queries), if and only if it is well-typed. Ob[j]() outputs bj (at most #Ob ≤ nb queries); • ODDHa We require the adversary to be well-typed. This requirement for Diffie-Hellman decisions, via ODDHb ODDHa[i](m, j) does not restrict its computing power, because it can always and oracles: checks m = gaibj naDDH define type-cast functions f : T → T 0 to bypass the type whether (at most queries a #ODDHa system. Similarly, the type system does not restrict the class for each , at most queries total), of protocols that we consider, since the protocol may contain 3The argument [i] between brackets is implicit in the CryptoVerif syntax type-cast functions. The type system just makes explicit and corresponds to the replication index.

18 ODDHb[j](m, i) checks whether m = gaibj As a consequence, the two games differ if for one DDH aibj (at most nbDDH queries for each b, at most query, m = g but neither ai or bj has been asked for #ODDHb queries total). We can thus combine an Oa or Ob query. In this case, with probability papb, both them into DDH(m, ai, bj) queries (at most γi = 1 and δj = 1: qddh = #ODDHa + #ODDHb ≤ na · nb queries) m = Z × Xβj Y αi gαiβj . which check whether m = gaibj . G2: the adversary is allowed to query If the two above games differ with probability ε, then such • OA and OB oracles, that answer as above; a critical DDH query happens with probability ε, since our • Oa and Ob oracles, that answer as above; simulation is perfectly indistinguishable from the second • for DDH(m, ai, bj), Diffie-Hellman decisions, or- game and such a critical query is the unique event that makes acle. But in this game, the correct answer is given the two games different. if either ai or bj has been asked before for an Oa Let us randomly choose k between 1 and qddh, and bet or Ob query. Otherwise, the answer is ’false’. that the k-th DDH query is the first critical one, which is true with probability ε/q . Furthermore, with probability We thus insist on the fact that the 2 games differ on ddh (1 − p )#Oa(1 − p )#Obp p the simulation did not fail DDH(m, a , b ) Diffie-Hellman decisions queries, if neither a b a b i j and the critical DDH query leads to the expected Z value, ai nor bj has been asked before for an Oa or Ob query. In by computing Z = m/Xβj Y αi gαiβj . This means that our the first game, the answer is the correct one; in the second simulator A achieves Succcdh(A) ≥ (1 − p )#Oa(1 − game, the answer is always ’false’. G a p )#Obp p ε/q , and is bounded by Succcdh(t + (na + Let us be given a CDH tuple (X = gx,Y = gy) for which b a b ddh G nb + q )τ ): we want to compute Z = gxy. And we provide a simulator ddh exp A for these games: q × Succcdh(t + (na + nb + q )τ ) ddh G ddh exp ε ≤ #Oa #Ob • For the query OA[i], one chooses a random bit γi with (1 − pa) (1 − pb) papb R bias pa, and a random scalar αi ← Zp, and sets Ai = Note that, two cases appear for the function x 7→ x(1−x)n: γi αi X g . This makes ai = αi + γix, and thus ai = αi • if n = 0, then the maximum is 1, for x = 1; if γi = 0; −2 • if n ≥ 1, then the maximum is greater than e /n ≥ • For the query OB[j], one chooses a random bit δj with R 1/7.4n, for x = 1/(n + 1). bias pb, and a random scalar βj ← Zq, and sets Bj = δj βj By choosing pa = 1/(#Oa + 1) and pb = 1/(#Ob + 1) in Y g . This makes bj = βj + δjx, and thus bj = βj #Oa the latter case, we get 1/(1 − pa) pa ≤ max(1, 7.4#Oa) if δj = 0; #Ob and 1/(1 − pb) pb ≤ max(1, 7.4#Ob), so • For the query Oa[i], with probability 1−pa, γi = 0, and then the correct answer αi can be sent. However, with ε ≤ (#ODDHa + #ODDHb)× p a probability a on the current , the simulation fails; max(1, 7.4#Oa) × max(1, 7.4#Ob) × • For the query Ob[j], with probability 1−pb, δj = 0, and Succcdh(t + (na + nb + #ODDHa + #ODDHb)τ ). then the correct answer βj can be sent. However, with G exp p b probability b on the current , the simulation fails. One could use Shoup’s amplification technique [64] to Since there are at most #Oa Oa queries and #Ob Ob eliminate the factor #ODDHa + #ODDHb, but at a com- #Oa #Ob queries, with probability at least (1−pa) (1−pb) , the putational cost: one runs the attack twice with different ran- simulation does not fail, and is perfectly indistinguishable domizations of the CDH instance, and looks for a collision from the real oracles OA, OB, Oa, and Ob. Let us now in the two executions: if the attack succeeded twice, we have consider the DDH Diffie-Hellman Decision queries, and the a collision on the correct answer; if the attack fails once, the simulation of the answers when no failure happens during collision probability is negligible. Oa and Ob simulation: for any DDH(m, ai, bj), B. Additional Modeling • if one of the ai or bj has been asked an Oa or Ob-query (and did not lead to a failure), which means that either In the CryptoVerif implementation, the equivalence γi = 0 or δj = 0, then one can either test whether L3 ≈p3 R3 additionally contains three proof strategy in- m = (gbj )αi or not, or whether m = (gai )βj or not, dications, which we have omitted in Figure 4: 0 and provide the correct answer. This leads to a perfect • In R3, we use the symbol exp instead of exp, al- simulation of the DDH oracle; though the two symbols represent the same function • otherwise, one can safely answer ’false’, which leads on bitstrings. This technique avoids infinite loops: if to a perfect simulation of the DDH oracle in the second we used exp in R3, R3 would be an instance of L3, game. However, it differs from the first game oracle if so the transformation of L3 into R3 could be applied aibj m = g . again on R3, leading to an infinite loop. By using

19 exp0, we prevent applying the transformation again on (6), and (7) allow CryptoVerif to simplify equalities between occurrences that have already been transformed. exponentials. x • In L3, the oracles Oa and Ob are marked with the If we choose uniformly x in Z and compute g , the result integer “[3]”. CryptoVerif tries to use oracles with the is a uniformly distributed group element, so we have the lowest mark first. (No mark means [0].) Here, the goal equivalence a is to make sure that g is obtained by calling OA and R not by calling Oa to obtain a and then computing ga foreach i ≤ n do x ← Z ; OX() := return(exp(g, x)) (and similarly for gab obtained by calling ODDHa or R ≈0 foreach i ≤ n do X ← G; OX() := return(X). ODDHb rather than Oa and Ob). Indeed, if Oa is (8) called, then the CDH assumption on that a can no 0 longer be applied. Therefore, CryptoVerif should use We have a similar equivalence for exp . Although equiva- OA, OB, ODDHa, or ODDHb rather than Oa or Ob lences are symmetric, CryptoVerif always applies them from where possible, hence we give Oa and Ob a higher left to right, replacing the code of oracles in the left-hand mark than the other oracles. side with the corresponding code in the right-hand side. For • In L3, the oracle ODDHa is marked [useful change]. this reason, we state the symmetric equivalence explicitly: This prevents the application of the transformation of foreach i ≤ n do X ←R G; OX() := return(X) L3 into R3 when the initial game can be encoded without calling ODDHa. Indeed, the transformation has ≈0 [manual] (9) a useful effect only when ODDHa or ODDHb are foreach i ≤ n do x ←R Z ; OX() := return(exp(g, x)). called and, by symmetry, we can require that ODDHa is called. However, this equivalence is applied only manually, as indicated by [manual]; otherwise, it would yield an infinite Moreover, we use the following properties. The multipli- loop by applying alternatively (8) and (9). We use the cation mult is commutative and we have the following following more restricted form for automatic proofs equalities: foreach i ≤ n do X ←R G; ∀a : G, ∀x : Z , ∀y : Z , (3) (OX() := return(X) | exp(exp(a, x), y) = exp(a, mult(x, y)) foreach i0 ≤ n0 do OXm(m : Z ) ∀x : Z , ∀y : Z , (exp(g, x) = exp(g, y)) = (x = y) (4) 0 0 [useful change] := return(exp(X, m))) ∀x : Z , ∀y : Z , (exp (g, x) = exp (g, y)) = (x = y) (5) (10) R ∀x : Z , ∀y : Z , ∀y0 : Z , ≈0 foreach i ≤ n do x ← Z ; (6) (mult(x, y) = mult(x, y0)) = (y = y0) (OX() := return(exp(g, x)) | foreach i0 ≤ n0 do OXm(m : Z ) := The commutativity of mult combined with (3) shows that return(exp(g, mult(x, m)))). (ga)b = gab = gba = (gb)a, the standard equality that shows that the client and the server compute the same key which can be applied only when X is used as argument of in the Diffie-Hellman key exchange. Equations (4) and (5) exp. express the injectivity of exp and exp0 respectively. They APPENDIX C. hold because g is a generator of the group G of order q and x, y ∈ [1, q − 1]. Equation (6) is obtained by dividing the PROOFSOF LEMMAS 1 AND 2 0 ∗ 0 equality xy = xy by x in the group Zq . Proof of Lemma 1: For Property 1, if C[G ] does The statement not execute e and D returns false, then C[G] behaves like C[G0] C[G] C[G0] e R R R R since and differ only when is executed, collision x1 ← Z ; x2 ← Z ; x3 ← Z ; x4 ← Z ; so D also returns false on the execution of C[G]. Hence return(mult(x1, x2) = mult(x3, x4)) (7) Pr[C[G0]: ¬(D ∨ e)] ≤ Pr[C[G]: ¬D]. Property 1 follows. For Property 2, if C[G] satisfies D = (D0 ∧ ≈1/|Z| return(false). ¬NonUnique) ∨ e1 ∨ ... ∨ en, then C[G] does not execute means that, when x1, x2, x3, x4 are uniformly randomly NonUnique: this is clear by definition when C[G] satisfies and independently chosen in Z , except with probability D0 ∧ ¬NonUnique; when it satisfies e1 ∨ ... ∨ en, C[G] 1/|Z|, one can replace mult(x1, x2) = mult(x3, x4) with also does not execute NonUnique because one aborts imme- false. Indeed, mult(x1, x2) = mult(x3, x4) if and only if diately after the events e1, . . . , en and after NonUnique, so x1 × x2/x3 = x4 so the probability of mult(x1, x2) = these events are pairwise incompatible. Hence, G0 behaves as mult(x3, x4) is the probability of choosing an x4 in Z equal G when C[G] satisfies D. Hence Pr[C[G]: D] ≤ Pr[C[G0]: to a given x1 × x2/x3, that is, 1/|Z|. The formulas (4), (5), D].

20 Property 3 is an immediate consequence of Deﬁnition 1. Therefore, Pr[C[G | Rx]: S] = Pr[C[G | Rx]: S]. Since Property 4 is obvious. we abort immediately after each event S, e1, . . . , en, S is Proof of Lemma 2: Property 1: By Lemma 1 (Prop- incompatible with e1, . . . , en, so 0 erty 1), Pr[C[G | Rx]: S∨D] ≤ Pr[C[G | Rx]: S∨D ∨e]. 0 0 Pr[C[G | Rx]: S ∨ D] Moreover, if C[G | Rx] executes S or NonUnique, C[G | = Pr[C[G | Rx]: S] + Pr[C[G | Rx]: D] Rx] does not execute e (since we abort immediately after S, 0 NonUnique, and e), so C[G | Rx] behaves like C[G | Rx], Hence thus C[G | Rx] also executes S or NonUnique. Therefore, Secrecy 0 Adv (C,D) Pr[C[G | Rx]: S ∨ NonUnique] ≤ Pr[C[G | Rx]: G S ∨ NonUnique]. Property 1 follows. = Pr[C[G | Rx]: S] + Pr[C[G | Rx]: D]

Property 2: We have − Pr[C[G | Rx]: S ∨ NonUnique]

≤ Pr[C[G | Rx]: D] Pr[C[G | Rx]: ¬(S ∨ NonUnique)] 0 ≤ Pr[C[G | Rx]: ¬(S ∨ NonUnique)] APPENDIX D. since, when G does not execute S nor NonUnique, a for- IMPROVED COMPUTATION OF PROBABILITIESFORTHE tiori, it does not execute NonUnique, so G0 behaves as G. MANUAL PROOFOF OEKE Therefore, To illustrate the use of our improved computation of prob- − Pr[C[G | Rx]: S ∨ NonUnique] abilities of Section IV-A, we apply it to the manual proof of 0 ≤ − Pr[C[G | Rx]: S ∨ NonUnique] OEKE [55]. We just recall the structure of the proof and the computation of probabilities, and refer the reader to [55] for Moreover, details of the proof. Let us consider the proof of semantic 0 security [55, Section 3.2]. The proof starts from a game Pr[C[G | Rx]: S ∨ D] ≤ Pr[C[G | Rx]: S ∨ D] G0 that represents the OEKE protocol, in which we deﬁne since, when G executes S or an event in D, it does not a test-query that returns either the session key or a random execute NonUnique (because one aborts immediately after value, depending on the value of a bit b, an event S executed S, the events in D, and NonUnique), so G0 behaves as G. when the adversary guesses b correctly, and an event S Property 2 follows. executed when the adversary guesses the wrong value of b. The probability that the adversary C guesses b correctly Property 3: Let t = max(tS∨D, tS∨NonUnique). By deﬁni- tion of indistinguishability, in G0 is Pr[C[G0]: S], the probability that it guesses the wrong value of b is Pr[C[G0]: S] and the advantage of the Pr[C[G | Rx]: S ∨ D] adversary C in distinguishing the session key from a random ake 0 key is Adv (C) = Pr[C[G ]: S] − Pr[C[G ]: S]. ≤ p(C[[ ] | Rx], t) + Pr[C[G | Rx]: S ∨ D] oeke 0 0 The proof then proceeds as follows. The game G0 is trans- and formed into games G1, G2, G3, by eliminating collisions, 0 such that Pr[C[G | Rx]: S ∨ NonUnique]

q q ≤ p(C[[ ] | R ], t) + Pr[C[G | R ]: S ∨ NonUnique] G0 ≈ q2 G1 ≈ S E G2 ≈ 2q2 +q2 q2 G3 x x E q−1 E S + h 2(q−1) 2(q−1) 2l1+1 So where qS is the number of involved server instances, qE Secrecy Secrecy is the number of encryption/decryption queries, qh is the AdvG (C,D) ≤ 2p(C[[ ] | Rx], t) + AdvG0 (C,D) number of hash queries, l1 is the length of the output of Property 4 is obvious. H1, q is the order of G. Then G is transformed into G by inserting event Property 5: When CryptoVerif proves the secrecy of x in 3 4 Encrypt. Game G is transformed into G by excluding game G, it shows that only a certain set of variables depends 4 5 traces in which a correct authenticator is guessed, so that on value of x, but the output messages and the control-flow G4 ≈ NS G5 where NS is the number of sessions of do not depend on x. Hence an execution of C[G | Rx] that 2l1 calls oracle O0 (defined in Definition 2) in which b = 1 the server S interacting with the adversary. Game G5 is 0 sends the same messages and has the same value of b0, as transformed into G6 by inserting event Auth , and G6 is the executions with the same random choices except that transformed into G7 by inserting event AskH. Finally, one b = 0, y[i] has the value of x[u[i]], and x takes any value. evaluates the probability of the various events in game G7: The execution with b = 1 executes S if and only if the N Pr[C[G ]: Encrypt] ≤ U executions with b = 0 execute S. 7 N

21 0 NS Pr[C[G7]: Auth ] ≤ Similarly, for unilateral authentication [55, Section 3.3], we N use an event Auth executed when the adversary submits Pr[C[G ]: AskH] ≤ q Succcdh(t0) 7 h G an authenticator accepted by the server and built by the Pr[C[G7]: S] = Pr[C[G7]: S] adversary itself, so the probability for an adversary C to make a server instance accept with no terminating client where the password in chosen in a dictionary of size N, partner is NU is the number of sessions of the client U interacting c−auth with the adversary, NS is the number of sessions of the Advoeke (C) = Pr[C[G0]: Auth] server S interacting with the adversary, N is the number of P We obtain similarly by Lemma 1 sessions between the client U and server S that the adversary 0 NS passively eavesdrops, t ≤ tC +(NU +NS +NP +qe +1)τG, Pr[C[G0]: Auth] ≤ pcoll0 + l + with qe denoting the number encryption/decryption queries 2 1 Pr[C[G ]: Auth ∨ Encrypt ∨ Auth0 ∨ AskH] asked by the adversary and τG denoting the computation 7 time for an exponentiation in G. ake Since G7 never executes event Auth, From this proof, we can bound the advantage Advoeke(C) ake Auth ∨ Encrypt NU NS in G0. Let Adv (C,D) = Pr[C[G]: S∨D]−Pr[C[G]: S] cdh 0 G Pr C[G7]: 0 ≤ + +qhSucc (t ) as in Lemma 2. (Here, G already includes the test queries, ∨ Auth ∨ AskH N N G so we need not compose with Rx in parallel; the event so NonUnique never occurs, so we omit it.) By Lemma 2, N + N Advc−auth(C) ≤ U S + q Succcdh(t0) + oeke h G Advake (C) = Advake(C, false) N oeke G0 (2q + 2N + 3N + 3N )2 q2 + 2N ake e U S P h S ≤ 2pcoll0 + Adv (C, false) (Lemma 2, Point 3) + G3 2(q − 1) 2l1+1 2 2 2 2 qE qSqE 2qE + qS qh where pcoll0 = + + + APPENDIX E. 2(q − 1) q − 1 2(q − 1) 2l1+1 NEW GAME TRANSFORMATIONS Advake (C) oeke The CryptoVerif proof of OEKE requires new game ≤ 2p + Advake(C, Encrypt) coll0 G4 (Point 1) transformations that we have implemented. We ﬁrst describe 2NS ake these games transformations, then summarize the proof ≤ 2pcoll0 + + AdvG (C, Encrypt) (Point 3) 2l1 5 itself. For a better understanding, we recommend reading 2NS ake 0 Appendix A before reading this appendix. ≤ 2pcoll0 + + AdvG (C, Encrypt ∨ Auth ) 2l1 6 (Point 1) A. The transformation move array

2NS ake 0 The transformation move array X delays the generation ≤ 2pcoll0 + + AdvG (C, Encrypt ∨ Auth ∨ AskH) 2l1 7 of a random value X until the point at which it is first used. (Point 1) This transformation is implemented as a particular case of a 2NS 0 cryptographic transformation by the following equivalence: ≤ 2pcoll0 + + Pr[C[G7]: Encrypt ∨ Auth ∨ AskH] 2l1 R (Point 5) foreach i ≤ n do X ← T ; 2N N N (foreach iX ≤ nX do OX() := return(X) | S U S cdh 0 0 ≤ 2pcoll0 + + + + qhSucc (t ) foreach ieq ≤ neq do Oeq(X : T ) := 2l1 N N G return(X0 = X)) Moreover, ≈#Oeq/|T| [manual] 2 2 2 2 foreach i ≤ n do qE + 2qSqE + 2qE + qS qh pcoll0 = + 2(q − 1) 2l1+1 (foreach iX ≤ nX do OX() := (2q + q )2 q2 find[unique] j ≤ nX suchthat defined(Y [j]) ≤ E S + h R 2(q − 1) 2l1+1 then return(Y [j]) else Y ← T ; return(Y ) | 0 (2q + 2N + 3N + 3N )2 q2 foreach ieq ≤ neq do Oeq(X : T ) := ≤ e U S P + h find[unique] j ≤ nX suchthat defined(Y [j]) 2(q − 1) 2l1+1 then return(X0 = Y [j]) else return(false)) since q ≤ q + N + N + N and q ≤ N + N . So E e U S p S S P where T is the type of X. Two oracles are defined, OX NU + NS and Oeq. In the left-hand side, OX returns the random X Advake (C) ≤ + q Succcdh(t0) + oeke N h G itself. In the right-hand side, OX uses a lookup to test if the (2q + 2N + 3N + 3N )2 q2 + 2N random value was already generated; if yes, it returns the e U S P + h S q − 1 2l1 previously generated random value Y [j]; if no, it generates a

22 fresh random value Y . Transforming the left-hand side into branch of a find[unique]: we transform the right-hand side therefore moves the generation of the Mk random number X to the first call to OX, that is, the first find[unique]( u˜j ≤ n˜j suchthat cj j=1 X Oeq usage of . The oracle provides an optimized treatment then Pj) else P of equality tests X0 = X: when the random value X was 0 false Lk 0 0 not already generated, we return instead of generating where Pj0 = find[unique]( j0=1 u˜j0 ≤ n˜j0 0 0 0 0 a fresh X, so we exclude the case that X is equal to a suchthat cj0 then Pj0 ) else P into X 1/|T | fresh . This case has probability for each call to M Oeq, so the probability of distinguishing the two games is find[unique]( u˜j ≤ n˜j suchthat cj j=1..k,j6=j0 #Oeq/|T |. (Notice that, similarly to the reasoning done in then Pj) Section III-B for the Random Oracle Model, there never k0 exist several choices of j that satisfy the conditions of the M 0 0 0 ⊕ ( u˜j0 ≤ n˜j0 , u˜j0 ≤ n˜j0 suchthat cj0 ∧ cj0 j0=1 finds in the right-hand side of this equivalence, so these finds 0 then P 0 ) can be marked [unique] without modifying their behavior.) j

else find[unique]u ˜j0 ≤ n˜j0 suchthat cj0 0 B. Extensions of simplification then P else P u˜ We have also extended simplification with the following We advise renaming the variables j0 to distinct transformations: names, since they now have multiple definitions. This transformation cannot be performed when the finds are 1) If some then branches of a find[unique] execute not unique because it might change the probability of the same code as the else branch (up to renaming taking each branch. of variables defined in these branches and that do 5) We reorganize a find[unique] that occurs in a condi- not have array accesses), and the variables bound in tion of a find: we transform the condition of these then branches have no array Mk accesses, then we remove these then branches. find[unique?] ( u˜j ≤ n˜j suchthat cj Indeed, these then branches have the same effect as j=1 then Pj) else P the else branch. The hypotheses are needed for the ˜ 0 following reasons: where cj0 = defined(M ) ∧ find[unique] 0 Lk 0 0 0 0 • The renamed variables must not have array ac- ( j0=1 u˜j0 ≤ n˜j0 suchthat cj0 then Mj0 ) else cesses because renaming variables that have ar- false into ray accesses requires transforming these array M find[unique?] ( u˜j ≤ n˜j suchthat cj accesses. The transformation merge arrays pre- j=1..k,j6=j0 sented in Section E-C below can rename variables then Pj) k0 with array accesses. M 0 0 ⊕ ( u˜j0 ≤ n˜j0 , u˜j0 ≤ n˜j0 suchthat • The variables bound in conditions of the removed j0=1 ˜ 0 0 0 branches must not have array accesses, because defined(M ) ∧ cj0 ∧ Mj0 then Pj0 ) removing the definitions of these variables would else P modify the behavior of the array accesses. 2) If all branches of if or find execute the same code The indication [unique?] corresponds to either (up to renaming of variables defined in these branches [unique] or empty. The find is marked [unique] after and that do not have array accesses), and the variables transformation if the outer find was [unique] before bound in the conditions of the then branches have no transformation. array accesses, then we replace that if or find with its For all these transformations, the correctness proof else branch. shows that, when the initial game does not execute event In this transformation, we ignore the array accesses NonUnique, the transformed game behaves in the same way that occur in the conditions of the find under consid- as the initial game. We can then apply point 2 of Lemmas 1 eration, since these conditions will disappear after the and 2 to bound the probability of attack. transformation. 3) If one of the then branches of a find[unique] always C. The transformation merge arrays succeeds, we keep only that branch. The transformation merge arrays x11 . . . x1n, ..., Indeed, the other branches are never taken: the find xm1 . . . xmn merges the variables xj1, . . . , xjn into a single aborts when there are several choices. variable xj1 for each j ≤ m. Each variable xjk must have a 4) We reorganize a find[unique] that occurs in a then single definition. For each j ≤ n, the variables xj1, . . . , xjn

23 must have the same type and indices of the same type. They P {xjk/xj1, j = 1...m} execute the same must not be defined for the same value of their indices (that code up to renaming of variables defined in is, xjk and xjk0 must be defined in different branches of if Pl or P {xjk/xj1, j = 1...m} and that do not 0 or find when k 6= k ). The arrays xj1, . . . , xjn are merged have array accesses. into a single array xj1 for each j ≤ m. The transformation – if l(k) does not exist, then we show that proceeds as follows: FB T{xjk/xj1, j = 1...m} can in fact not be executed, because its condition cannot hold: the • If, for each k ≤ n, x1k is defined above xjk for all variables of M˜ {xjk/xj1, j = 1...m} cannot 1 < j < m, we introduce a fresh variable bk defined by be simultaneously defined or M{xjk/xj1, j = bk ← mark just after the definition of x1k. We call bk a 1...m} cannot hold. branch variable; it is used to detect that xjk has been defined: xjk[M˜ ] is defined before the transformation If the transformation above fails and we have in- if and only if xj1[M˜ ] and bk[M˜ ] are defined after the troduced branch variables, we replace each condition defined(x [M˜ ]) with defined(x [M˜ ], b [M˜ ]). transformation, and xj1[M˜ ] after the transformation is jk j1 k If the transformation above fails and we have not equal to xjk[M˜ ] before the transformation. introduced branch variables, the whole merge arrays • For each find that requires that some variables xjk are defined, we leave the branches that do not require the transformation fails. • The definition of x is renamed to x and each definition of xjk unchanged and we try to transform the jk j1 reference to x [M˜ ] is renamed to x [M˜ ]. other branches FB l =u ˜l ≤ n˜l suchthat defined(M˜ l)∧ jk j1 Ml then Pl as follows. D. The transformation merge branches 1) We require that, for each l, there exists a distinct The transformation merge branches extends again the k such that the defined condition of FB l refers 0 first two extensions of simplification mentioned in Ap- to xjk for some j but not to xjk0 for any other k . pendix E-B. Instead of applying these transformations to (Otherwise, the transformation fails.) We denote a single find at a time, merge branches applies them by l(k) the value of l that corresponds to k. globally to all finds of the game for which the simplification 2) We choose a “target” branch FB T =u ˜ ≤ is possible. As a consequence, one can ignore array accesses ˜ n˜ suchthat defined(M) ∧ M then P : if the to all variables in conditions of find that will be removed, defined condition of some branch FB l refers to so more transformations are enabled. xj1 for some j, we choose that branch FB l. Otherwise, we choose any branch FB l and re- APPENDIX F. name its variables xjk to xj1. We require that THE PROOFIN CRYPTOVERIF ˜ the references xj1[M] to the variables xj1 in the A. Initial configuration defined condition of the target branch all have the First, we configure CryptoVerif to iterate the same indices M˜ . If the transformation succeeds, simplification of games at most 3 times, by we will replace all branches FB with the target l set maxIterSimplif = 3, instead of at most twice branch. by default. The complexity of the intermediate games of 3) The branch FB T after transformation is equiv- n OEKE requires more simplifications than in many other alent to branches L FB {x /x , j = k=1 T jk j1 examples. One can also iterate simplification until a fixpoint 1...m} before transformation. We show that these is reached, which is slightly slower but works for all branches are equivalent to the branches FB . l examples. For each k ≤ n, – if l(k) exists, then we show that B. Events Auth and Encrypt FB T{xjk/xj1, j = 1...m} is equivalent As explained in Section IV-A, we manually introduce to FB l(k). Let l = l(k). We first events Auth and Encrypt and distinguish cases in hash rename the variables u˜l of FB l to the functions. variables u˜ of the target branch. For C. Automatic Steps simplicity, we still denote by FB l =u ˜l ≤ n˜l suchthat defined(M˜ l) ∧ Ml then Pl the Then, we can use the automatic proof strategy of Cryp- obtained branch. Then we show that, if the toVerif, by command auto. Basically, this strategy consists variables of M˜ l are defined, then the variables in applying all possible cryptographic transformations (com- of M˜ {xjk/xj1, j = 1...m} are defined, and ing from equivalences L ≈p R) and simplifying the game conversely; Ml = M{xjk/xj1, j = 1...m} after each such transformation. When the transformations (knowing the equalities that hold fail, they advise syntactic transformations that could make at that program point), and Pl and them succeed; these transformations are executed and the

24 cryptographic transformation is then retried [49, Section 5]. is now named @6 X 416 , so we use the com- This automatic strategy performs the following transforma- mand move array ”@6 X 416 ” to delay its gener- tions: ation. The game is automatically simplified after this 1) It renames each occurrence of K u to a distinct name. command, which reorganizes find constructs. Before Indeed, as part of crypto icm(enc), the definition of move array, @6 X 416 is used in the following K u has been copied once for each possible origin ways: of Y u (a previous encryption/decryption query, or a 1) to compare it with the argument of encryption fresh Y u if no previous query matches). After this queries in the encryption oracle. This usage is renaming, simplification can simplify many tests of transformed using oracle Oeq of the transforma- the form K u = K s that appeared as a result of tion move array; no random value is generated. the transformation of the hash functions; it uses the 2) as a result of decryption queries in the decryption values of K u and K s as well as properties (4), (6), oracle. This usage is transformed using oracle and (7). OX; the generation of @6 X 416 in the client 2) Using equivalence (10) twice, it replaces the genera- is replaced with a generation of @2 Y 418 in tion of a fresh group element X with the generation the decryption oracle. of an exponent x and the computation X ← exp(g, x) 3) as a result of the decryption query dec(Y ?, pw) in as a result of decryption when no previous encryp- the client. That result is unused, so @6 X 416 tion/decryption query matches, in the decryption ora- appears only in a defined condition, which Cryp- cle and in the client. toVerif leaves unchanged. 3) It removes assignments on the copies of K u created in step 1 above, on K s (the key of the server), and Therefore, in the decryption oracle, when the result Kp (the key used in passive eavesdroppings), thus was not generated before, we have two cases: ei- replacing these variables with their values everywhere ther the result was in fact an Yu whose genera- in the game. tion has been delayed, and it is now generated as 4) It can then apply the CDH assumption (Section III-D). @2 Y 418 , or the query is really a fresh decryp- The oracles Oa and Ob are in fact not used in this tion query, and the result is named @6 X 412 . example (the code that would use them has been We would like to merge these two cases. However, removed by introducing events), so the situation is merge branches does not succeed directly because particularly simple: expressions of the form m = these variables have array accesses, so we first ap- exp(g, mult(a[i], b[j])) are replaced with false. ply merge arrays ”@6 X 412 ” ”@2 Y 418 ” to 5) At this point, CryptoVerif can bound the probability merge @2 Y 418 into @6 X 412 . Furthermore, in of breaking all desired properties (secrecy of sk u, some branches that we would like to merge, some correspondences (1) and (2)). However, the obtained random number generations are not ordered in the bound depends on the probability of executing the same way: in the client, the authenticator named events Auth and Encrypt which are not eliminated @11 r 130 is generated sometimes before and some- yet, so the proof continues in order to eliminate these times after the shared key sk u. We need to make events. sure that they are in the same order in all branches for 6) Using the version of equivalence (8) for exp0, we merge branches to succeed. This is done by the trans- replace the computation of exp0(g, x) for a fresh formation move binder @11 r 130 , which moves random x with the generation of a random group definitions of @11 r 130 as much as possible down- element X, for the result of the decryption oracle and wards in the game. Then, we apply merge branches for the computations of Yp and Xp (the values of Y successfully. and X in passive eavesdroppings), Y (in the server), • Second, the value of Y in passive eavesdroppings, Yp. Y u and X (in the client). This variable is now named @6 X 413 . We proceed similarly, using move array ”@6 X 413 ”, then After these transformations, no automatic step can be per- merge the delayed @6 X 413 named @2 Y 425 formed, so the automatic proof stops. into the result of decryption @6 X 412 by D. Reorganizing random number generations merge arrays ”@6 X 412 ” ”@2 Y 425 ”, and finally apply merge branches. Using manually guided transformations, we can eliminate • Third, the value of Y in the server, now the random number generations for Y . We consider the three named @6 X 415 . We again proceed similarly, generations of Y in turn. using move array ”@6 X 415 ”, then merge • First, Yu (the value of Y in the client), when the delayed @6 X 415 named @2 Y 432 it is a fresh random group element. This variable into the result of decryption ”@6 X 412 ” by

25 merge arrays ”@6 X 412 ” ”@2 Y 432 ”. We by guessing the password. After the command (12), by cannot apply merge branches directly because the insert event Auth2 184, we insert the event Auth2 condition that triggers the event Auth, in the then branch of the find of (12). CryptoVerif can show that the condition (11) implies the condition find @i 435 ≤ qD, jh ≤ qH1 suchthat of (12), so in the else branch of (12), the condition (11) defined(@i 437 [@i 435 ], x1 [jh], x2 [jh], x3 [jh], never holds, hence by simplification (simplify), we x4 [jh], @6 X 412 [@i 435 ], @11 r 134 [jh]) ∧ remove that else branch. Simplification also merges the @i 437 [@i 435 ] = iS ∧ U = x1 [jh] ∧ cases of find, without an explicit merge branches. At this point, event Auth does not occur in the current S = x2 [jh] ∧ X s = x3 [jh] ∧ game. The events Encrypt and Auth2 are eliminated x4 [jh] = @6 X 412 [@i 435 ] ∧ and their probabilities are bounded as explained in auth s = @11 r 134 [jh] then Section IV-D. (The variables @8 re 161 , @8 re 167 , (11) @11 r 134 , and @6 X 412 have been renamed to Y star, re, hash , and rd respectively there.) refers to the variable @i 437 which is defined in 1 the condition of a find whose branches we would like to merge; this merging is not possible because it would make the definition of @i 437 disappear. So we manually rewrite the condition (11) to remove the reference to @i 437 . By insert 121 “find jh0 ≤ qH1 , jd ≤ qD suchthat defined(x1 [jh0], x2 [jh0], x3 [jh0], x4 [jh0], @11 r 134 [jh0], m[jd], kd[jd], @6 X 412 [jd]) ∧ m[jd] = @8 re 161 ∧ U = x1 [jh0]) ∧ S = x2 [jh0]) ∧ X s = x3 [jh0] ∧ x4 [jh0] = @6 X 412 [jd] ∧ auth s = @11 r 134 [jh0] ∧ kd[jd] = pw then” (12) we insert a test just above the find (11). The variables jh and @i 435 of the find (11) are renamed to jh0 and jd respectively in (12) (without change in the meaning), and the condition @i 437 [@i 435 ] = iS of (11), that is, @i 437 [jd] = iS is replaced with m[jd] = @8 re 161 ∧ kd[jd] = pw in (12). In the considered game, the variable @i 437 is defined in a find with condition m = @8 re 161 [@i 437 ] ∧ kd = pw, so when @i 437 [jd] is defined, we have m[jd] = @8 re 161 [@i 437 [jd]] ∧ kd[jd] = pw; when @i 437 [jd] = iS, we obtain exactly the condition of (12), knowing that the index iS can be omitted because it is the index of the replication above the find (12). Explained another way, the find of (12) looks for a hash query indexed by jh0 and a decryption query indexed by jd, such that the adversary has decrypted the value of Y ? generated by the server, @8 re 161 , under the correct password pw, obtaining @6 X 412 [jd] (which is then the correct value of Y ) using that decryption query, and then has passed a value (U, S, X s, @6 X 412 [jd], ) to the hash query, obtaining the correct authenticator auth s = @11 r 134 [jh0]. This corresponds exactly to the situation in which the adversary authenticates to the server