Split Functionality sF. The split functionality is a generic construction based upon an ideal functionality: Its description can be found on Figure 1. In the initialization stage, the adversary adaptively chooses disjoint subsets of the honest parties (with a unique session identifier that is fixed for the duration of the protocol). More precisely, the protocol starts with a session identifier sid. Then, the initialization stage generates some random values which, combined together and with sid, create the new session identifier sid′, shared by all parties which have received the same values – that is, the parties of the disjoint subsets. The important point here is that the subsets create a partition of the players, thus forbidding commu- nication among the subsets. During the computation, each subset H activates a separate instance of the functionality F. All these functionality instances are independent: The executions of the protocol for each subset H can only be related in the way the adversary chooses the inputs of the players it controls. The parties Pi ∈ H provide their own inputs and receive their own outputs (see the first item of “computation” in Figure 1), whereas the adversary plays the role of all the parties Pj ∈/ H (see the second item).
Split Functionality sF. The split functionality is a generic construction based upon an ideal functionality: Its description can be found on Figure 1. In the initialization stage, the adversary adaptively chooses disjoint subsets of the honest parties (with a unique session identi er that is xed for the duration of the protocol). More precisely, the protocol starts with a session identi er sid. Then, the initialization stage generates some random values which, combined together and with sid, create the new session identi er sidj, shared by all parties which have received the same values that is, the parties of the disjoint subsets. The important point here is that the subsets create a partition of the players, thus forbidding commu- nication among the subsets. During the computation, each subset H activates a separate instance of the functionality F . All these functionality instances are independent: The executions of the protocol for each subset H can only be related in the way the adversary chooses the inputs of the players it controls. The parties Pi ∈ H provide their own inputs and receive their own outputs (see the rst item of computation in Figure 1), whereas the adversary plays the role of all the parties Pj ∈/ H (see the second item). The Group Password-Based Key Exchange Functionality with Mutual Authentication. In this section, we discuss the FGP AKE functionality (see Figure 2). The multi-session extension of our functionality would be similar to the one proposed by Xxxxxxx and Xxxxx [27]. Our starting points are the group key exchange functionality described in [34] and the (two party) password-based key exchange functionality given in [25]. Our aim is to combine the two of them and to add mutual authentication and (t, n)-contributiveness. The new de nition still remains very general: letting t = 1, we get back the case in which the adversary may manage to set the key when it controls at least a player, as in [25]. First, notice that the functionality is not in charge of providing the passwords to the participants. Rather we let the environment do this. As already pointed out in [25], such an approach allows to model, for example, the case where some users may use the same password for di erent protocols and, more generally, the case where passwords are chosen according to some arbitrary distribution (i.e. not necessarily the uniform one). Moreover, notice that allowing the environment to choose the passwords guarantees forward secrecy, basically for free. More gener...
