Game G1. We refer to Forge as the event that asks for a SendServer(m')-query, such that the verification of the signature is correct and m' was not previously output by a client as an answer to another Send-query. In other words, is sending a message it has built by itself, after having seen at most qs correct signatures (of a specific format). In that case, we abort the game and fix b' randomly. The games G1 and G0 are identical as long as Forge does not occur. By guessing the impersonated client, one easily gets: SIGN | Pr[S1] — Pr[S0]| ≤ Pr[Forge] ≤ N·Succcma (t, qs). ←
Game G1. This is the game of minute simulation for the adversary, so that we simulate all the oracles for each query in Figure 5. To make our simulation sound, we keep three lists of transcripts: Lh for random oracle queries to hi() for i ∈ {1, 2, 3, 4} and H0, LA for the random oracle queries directly asked by the adversary, and P for the exchanged protocol messages. Internal variables and states are postulated to be written on the corresponding tapes. We assume that h1(·) and H0(·) are queried with (C, π) at most once in the whole games. We also postulate that the adversary queries hi(·) without loss of generality for i ∈ {2, 3, 4}. The inter- nal variables, OpenU[i,j] , CloseU[i,j] and AcceptU[i,j] , are all set false initially. Another internal variable AcceptableSj is set true initially. If OpenCi and OpenSj are all true and there is a Send(Ci, (µ, k1)) query, then Ci is paired with Sj and thus we have ((C, m), (µ, k1), ∗) ∈ LP . Similarly, if OpenCi and OpenSj are all true and there is a Send(Sj, k2) query only for the case that a Send(Ci, (µ, k1)) query was asked, then Sj is paired with Ci and thus we have (( ) ( ) ) ∈ L C, m , µ, k1 , k2 P . CloseU [i,j] and AcceptU [i,j] can be used to allege partnering. From this minute simulation, we can easily see that the game is perfectly indistinguishable from the real attack game in the random oracle model. Thus we have: Pr[Succ1] = Pr[Succ0].
Game G1. We refer to Forge as the event that A asks for a SendServer(m0)-query, such that the veri cation of the signature is correct and m0 was not previously output by a client as an answer to another Send-query. In other words, A is sending a message it has built by itself, after having seen at most qs correct signatures (of a speci c format). In that case, we abort the game and x b0 randomly. The games G1 and G0 are identical as cma long as Forge does not occur. By guessing the impersonated client, one easily gets: j Pr[S1] Pr[S0]j Pr[Forge] N SuccSIGN(t; qs):
Game G1. We modify the previous game by simulating the hash and the encryption/decryption ora- cles, in a quite natural and usual way. For the ideal tweakable cipher, we allow S to maintain a list Λε of entries (queries, responses) of length qε + qD, composed of the two sub-lists: {(pw, (ssid, i), Y, α, E , Y ∗)} for the encryption queries, and {(pw, (ssid, i), Y, α, D, Y ∗)} (for decryption). The first (resp. second) sub-list is indeed used to indicate that the element Y (respectively Y ∗) has been encrypted (“ E”) (respectively decrypted (“D”)) to produce the ciphertext Y ∗ (resp. the plaintext Y ) via a symmetric encryption algorithm that uses the key pw and tweak (ssid, i). Actually, for a new encryption query, Y ∗ is randomly chosen, and α is set to ⊥. For a new decryption query, α is randomly chosen in Z∗, and Y is set to gα. Such a list is used by S to be able to provide answers which are consistent with the following requirements: 1) the same question for the same password/tweak pair will receive the same answer; 2) the simulated scheme (for each password/tweak) is actually a permutation over G; 3) in order to help S to later extract the password used in the first flow, there should not be two encryption entries of the form (question, answer) with identical ciphertext and tweak, but different passwords: a ciphertext (obtained by encryption) should correspond to a unique password. On the other hand, any decryption of a ciphertext not obtained by encryption will provide the discrete logarithm at the same time. S also maintains a list ΛH of tuples (i, q, r) where Hi(q) = r, used to properly manage the queries for the random oracles Hi, excluding the collisions too. More precisely, we cancel the games where these two kinds of collisions appear. More precisely, the list Λε described above is actually composed of the two following sublists: {(pw, (ssid, i), Y, α, E , Y ∗)} and {(pw, (ssid, i), Y, α, D, Y ∗)}. The first (resp. second) sublist is used to indicate that the element Y (respectively Y ∗) has been encrypted (“ E”) (respectively decrypted (“D”)) to produce the ciphertext Y ∗ (resp. Y ) via a symmetric encryption algorithm that uses the key pw for user i in session ssid (with tweak (ssid, i)). The role of α will be explained later on. The simulator manages the list of encryption and decryption queries through the following rules: – For an encryption query E ssid,i(Y ) such that (pw, (ssid, i), Y, ∗, ∗, Y ∗) appears in the list Λ , the pw ε answer is Y ∗. ...
Game G1. Modeling the ideal layout. We first regroup and create new machines, similar to Game 1 in the proof of Theorem 7. The new machine executes the code of the CRS, RO and IC functionalities as depicted in Figures 13, 14, and 15. Game G2: Simulating the ideal functionalities. We modify simulation of FRO and FIC as follows. We let S implement Figure 15 by maintaining a list ΛIC with entries of the form (k, m, α, E|D, c). S handles encryption and decryption queries as follows: – Upon receiving (sid, E, k, m) (for shortness of notation, we will also write Ek(m) for this query), if k ∈/ Fp or m ∈/ G then abort. Else, if there is an entry (k, m, ∗, ∗, c) in ΛIC, S replies with (sid, c). Else, S chooses c ←$ G \{1}. If there
Game G1. Modeling the ideal layout. We first make some purely conceptual changes that do not modify the input/output interfaces of Z. We add one relay (also referred to as dummy party ) on each of the wires between Z and a party. We also add one relay covering all the wires between the dummy parties and real parties and call it F (and let F relay messages according to the original wires). We group all the formerly existing instances except for Z into one machine and call it S. Note that this implies that S executes the code of the A-iPAKE functionality FA-iPAKE. The differences are depicted in Figure 20 with FOT replaced by FA-iPAKE. fPAKE fPAKE
