Design and Implementation of a Post-Quantum Group Authenticated Key Exchange Protocol With the LibOQS Library: A Comparative Performance Analysis From Classic McEliece, Kyber, NTRU, and Saber

Group authenticated key exchange protocols (GAKE) are cryptographic tools enabling a group of several users communicating through an insecure channel to securely establish a common shared high-entropy key. In the last years, the need to design cryptographic tools which provide security in the presence of attackers with access to quantum resources has become unquestionable; the field dealing with these types of protocols is usually referred to as Post-Quantum Cryptography. The U.S. National Institute for Standards and Technology (NIST) launched in 2017 an open call to find suitable post-quantum public-key algorithms for standardization. In this work, we design a GAKE that can be instantiated with any key encapsulation mechanism (KEM) that satisfies the strong security notion IND-CCA, matching NIST’s requirements for this primitive. We have implemented our GAKE with the four finalist KEMs from the NIST process: Classic McEliece, Kyber, NTRU, and Saber, making use of the open-source library LibOQS where these algorithms are provided. We have conducted a detailed comparative performance analysis of the resulting GAKE protocols, taking into account all the parameter sets proposed in the submissions. We have also made a performance analysis of all the involved building pieces, including the four finalist KEMs. Finally, we also compare our GAKE with a previous proposal implemented with Kyber.


I. INTRODUCTION
Group authenticated key exchange (GAKE) protocols are cryptographic constructions that allow a group of n ≥ 2 users or parties, communicating through an insecure network, to agree on common session keys. These keys are then typically used to provide security guarantees, such as The associate editor coordinating the review of this manuscript and approving it for publication was Wei Huang . confidentiality, integrity, and/or authentication, for further communication among the group members.
In the last years, we have seen a growing concern about the threat that quantum computation presents to the security of many existing cryptographic primitives based on mathematical problems related to integer factorization or computation of discrete logarithms. This led the U.S. National Institute of Standards and Technology (NIST) to launch an open call in 2017 asking for proposals of post-quantum algorithms VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ that could be subsequently standardized. The term ''postquantum'' in this context refers to algorithms that could be considered to offer security against attackers that have access to quantum computational resources. In the NIST call for proposals, two types of cryptographic primitives were allowed: Key Encapsulations Mechanisms (KEMs) and digital signatures. At the beginning of 2022, there were three rounds of announcements from NIST stating which candidates advanced in the process. After round 3, there were 7 finalists: 4 KEMs and 3 signature schemes. NIST also proposed a list of alternate candidates for further study and future consideration; it was composed of 5 KEMs and 4 signature schemes. During the revision process of this paper, NIST announced the algorithms selected for standarization, namely Kyber as the KEM and Dilithium, Falcon and SPHINC+ as digital signatures. In this work, we focus on the four finalist KEMs, as they are known to be a basic building block from which GAKE protocols can be constructed.

A. RELATED WORK
There have been several recent proposals of group key exchange protocols that provide some kind of resistance against quantum attacks (see Table 1 for a comparison between the main GAKE protocols). The protocol presented in [1] by Fujioka et al. is based on the problem of finding isogeny mappings between two supersingular elliptic curves with the same number of points. In the same line, Hougaard and Miyaji presented in [2] several designs based on isogenies. The authenticated protocols are named A-SIT and A-P2P-SIT, with the latter being the peer-to-peer version of A-SIT, which means that it reduces the protocol complexity in terms of communication and memory. Both are authenticated protocols, resistant to active attacks, and achieve authentication through a signature scheme. Apon et al. ( [3]) constructed an unauthenticated protocol proven secure under the ring learning with errors (RLWE) assumption. This scheme may be transformed into an authenticated one by using the Katz and Yung compiler ( [12]), that adds a signature scheme and an additional round to the original protocol. The protocols from Choi et al. ([4], [5]) are also based in the same problem; the authors build on [12] and propose three different protocols: the first is unauthenticated, the second (STAG) adds authentication, and the third is, in addition, dynamic (meaning that users may join or leave the group at any time). Choi et al. [6] proposed a generic GAKE also relying on the RLWE assumption, built on a tree structure in the dynamic setting. In more detail, this protocol has been instantiated with NewHope [13]: a KEM submitted to the NIST standardization process, but which has not been selected as a finalist in Round 3. Takashima constucted in [7] two different families of GAKEs based on static lattice and isogeny assumptions respectively, where static means that the size of the computational problem does not depend on the number of participants in the group.
There also exist protocols, like the one we propose in this work, that use compilers, which produce a quantum-resistant GAKE from simpler post-quantum primitives. In this line, the protocol from Persichetti et al. ( [8]) was constructed from a KEM and a signature scheme. González Vasco et al. ([9]) introduced a protocol derived from a KEM and a Message Authentication Code (MAC). However, this construction cannot be considered completely post-quantum; security holds in the future-quantum scenario, where adversaries do not have access to quantum resources during the protocol execution but only later. Escribano Pablos et al. ( [11]) used the compiler from Abdalla et al. ( [14]) to obtain a GAKE from the IND-CPA Public Key Encryption (PKE) scheme included in the Kyber suite ( [15]) and the FO AKE transformation, and proved it to be secure in the Quantum Random Oracle Model (QROM). The compiler introduced in [10] allows to obtain a GAKE protocol using any two-party key exchange, being a generalization of the Burmester and Desmedt [16] protocol in the G-CK+ security model. Two versions of the compiler have been proposed: the original version known as GKE-C and the peer-to-peer version (P2P-GKE-C). The latter reduces the resources consumption (memory and communication) compared to the original compiler.

B. OUR CONTRIBUTION
In this work, we propose a generic post-quantum GAKE protocol in the same line of [11]. We rely only on three primitives: an IND-CCA secure KEM, a one-time symmetric encryption scheme, and a cryptographic hash function. The FSXY transformation by Fujioka et al. ([17] provides a two-party authenticated key exchange 2AKE from the KEM. Then we use Abdalla et al.'s compiler ( [14]) to obtain the GAKE from the 2AKE. The compiler also requires a commitment scheme satisfying certain properties, but we show that it can be obtained from the same KEM used for the FSXY transformation. Whereas this construction may be seen as a generalization of [11] (which also builds on Abdalla et al.'s compiler and a generic transformation from KEM to AKE), this is not exactly so, as here the FSXY transformation is used instead of the FO AKE (see [18] and [19]), which is used in [11].
Our aim is to design a generic protocol that may be implemented with any of the four Round 3 KEM finalists from the NIST post-quantum standardization process, namely Classic McEliece, Kyber, NTRU, and Saber. In fact, our design can be implemented with any IND-CCA KEM (yet its final security against quantum adversaries is of course not guaranteed if the KEM is not post-quantum). We would like to point out that the FO AKE transformation offers some advantages over FSXY, such as having a security proof in the Quantum Random Oracle Model (QROM) and being simpler. However, it cannot be directly applied to the public key encryption schemes described in the Classic McEliece and NTRU submissions, as they are deterministic and cannot satisfy the IND-CPA requirement from [18] and [19]. Therefore, our rationale for choosing FSXY is that it is the simplest transformation we are aware of which allows for a uniform treatment of the four KEM finalists when constructing the GAKE.
As far as we now, our protocol is the only existing GAKE that simultaneously satisfy the two following properties: can be implemented from any KEM, offers security in the post-quantum setting and does not make use of post-quantum signatures. To justify this fact, note that among the protocols enumerated in Table 1, [1], [2], [3], [4], [5], [6], [7], [11] use specific KEMs or post-quantum mathematical problems, [8] makes use of a post-quantum signature and [9], [10] depart from a two-party key exchange protocol, not from a KEM. As every NIST finalist must include a KEM, this allows us to provide full and working implementations of our GAKE with all the finalists.
We have instantiated and implemented our GAKE protocol with the aforementioned four finalists from the NIST competition. Our implementations make use of the open-source library LibOQS and they cover the four KEMs and all the different parameter sets proposed for each one. We have conducted a performance analysis of the whole GAKE protocol and compared the different versions.
In addition, we have independently studied the performance of the different building blocks, including each of the KEMs. We consider this comparative performance analysis of the Round 3 finalists to be an interesting additional and independent contribution.
Finally, we provide performance figures comparing our GAKE implemented with Kyber to the GAKE presented in [11], which is also Kyber based but uses the FO AKE transformation ( [18], [19]) to obtain the 2AKE. The GAKE in [11] is the only one in the previous literature, as far as we know, to have been implemented with one of the four KEM finalists from NIST competition.

C. PAPER ROADMAP
We start by providing some preliminaries in Section II, which will help the reader understand our GAKE design, subsequently depicted in Section IV. The security model we are considering is described in Section III and we provide a security proof for our protocol in Section IV. Section V describes the different implementation possibilities and gives a detailed explanation of our comparative experiments, which results are further analyzed in Section VI. We finalize with a brief summary of our conclusions in Section VII, which is followed by two appendices. Appendix A depicts a complete run of the GAKE protocol using Classic McEliece as a building block, whereas Appendix B shows some numerical results (linked to the graphics from Section VI).

II. PRELIMINARIES
A. ABDALLA ET AL. 's COMPILER: FROM 2-PARTY AKE TO GAKE Here, we briefly describe the compiler due to Abdalla et al. ([14]), which derives a group authenticated key exchange protocol GAKE from an arbitrary 2-party key exchange protocol 2AKE. Abdalla et al.'s compiler only adds 2 additional rounds of communication to 2AKE, i.e., if 2AKE needs in r rounds to run, GAKE requires r + 2 rounds. Moreover, the compiler does not require any authentication method beyond the ones required by 2AKE. It only assumes that participants in GAKE are distributed on a ring, i.e., user U i is aware of the identity of its left neighbour U i−1 and its right neighbour U i+1 .
We denote with P the set of users that can participate in the protocol GAKE and with G the subset {U 0 , U 1 , . . . , U n−1 } ⊂ VOLUME 10, 2022 P of n ≥ 2 users that want to agree on a session key. A user U i can run a polynomial number of (parallel) instances of GAKE. 2AKE assumes long-term authentication keys that have been established in a trusted authentication phase. It allows a pair of public/secret keys for each user U i , a high entropy symmetric key, or a low entropy password. shared for each pair of users, and a common secret for all users.
The compiler depends on the following cryptographic tools: A non-interactive non-malleable commitment scheme C that is perfectly binding and achieves non-malleability for multiple commitments, a collision-resistant pseudorandom function family F, and a hash function H selected from a family of universal hash functions.
We briefly describe the compiler (see details in [14]): in Round 1 ∼ r, each user U i runs 2AKE with U i and U i+1 , obtaining two keys − → K i and ← − K i , shared with U i+1 and U i−1 . In Round r + 1, each user U i computes a commitment Finally, in Round r + 2, each user U i broadcasts M 2 i = (U i , X i , r i ), checks that n−1 i=0 X i = 0 and the correctness of the commitments C i . If any one of last two conditions fails, then user U i ends the protocol at this point. Then, U i computes the master key K = (K 0 , K 1 , · · · , K n−1 , G), where U i sets the session key sk i and the session identifier sid i , derived from F and H, respectively.

B. POST-QUANTUM KEMs
We instantiate both the 2AKE and the commitment scheme C (needed for the compiler described in Section IV) from a post-quantum KEM. Next we recall the formal definition of a KEM: it is a triple of algorithms KEM = (KeyGen, EnCap, DeCap) such that: • The probabilistic key generation algorithm KeyGen(1 ) takes as input the security parameter and outputs a key pair (dk, ek).
• The probabilistic encapsulation algorithm EnCap(ek; r) takes as input a public encapsulation key ek and outputs a ciphertext c and a key 1 k. The value r corresponds to the random coins used by EnCap. We include it as an explicit input as we will need to refer to it in the description of our GAKE.
• The deterministic decapsulation algorithm DeCap(dk, c) takes as input a secret decapsulation key dk and a ciphertext c and outputs a key k or ⊥ (meaning decryption failure). We will consider the four Round 3 KEM finalists from NIST's Post-Quantum standardization process. All of them target the IND-CCA2 security notion as required by NIST in its call for proposals, which is also usually named just IND-CCA; we will use the latter denomination throughout this paper. A KEM is considered to be IND-CCA secure if, given an encapsulated ciphertext and a key which is either the encapsulated key or a random one, an adversary (modeled as a probabilistic polynomial-time algorithm) with access to a decapsulation oracle is unable to distinguish between these two options with a probability non-negligibly better than a random guess. For a more formal definition see, for instance, [20].
Concerning the practical security strength of the candidates, NIST establishes 5 security levels ( [21]). These security levels ask for resistance against attacks that use computer resources comparable to or greater than those required for key search against a block cipher or collision search for a certain hash function. More precisely, the security levels are summarized in Table 2.
Next, we briefly overview the four finalists KEMs. The full description of all the algorithms submissions to Round 3 can be found in the NIST webpage [22].

1) CLASSIC McEliece
Classic McEliece [23] is the only candidate based on codes. The KEM is built from an OW-CPA deterministic PKE, namely Niederreiter's dual version of McEliece's PKE, which uses binary Goppa codes ( [24]). The Round 3 submission of McEliece comes with 5 different parameter sets, each one with two versions, depending on whether the parity check matrix of the code is reduced to systematic or semi-systematic form. The names of the parameter sets and their claimed security levels are shown in Table 3.

2) CRYSTALS-KYBER
Kyber [25], like two other finalists, NTRU and Saber, bases its security on a lattice problem, in this case, the Module learning with errors (MLWE) problem. The proposal is based on an IND-CPA PKE that allows decryption failures to occur with a negligible probability. Then, a modification of the Fujisaki-Okamoto transformation is used to obtain an IND-CCA KEM. The submission includes 3 different parameter sets pointing at NIST security levels 1, 3, and 5, respectively, depicted in Table 4.

3) NTRU
The NTRU submission for Round 3 is a merger of two different previous submissions, namely NTRUEncrypt and NTRU-HRSS-KEM ( [26]), both based in the NTRU cryptosystem ( [27]). Although the original NTRU was a partially correct probabilistic PKE, this submission starts 120954 VOLUME 10, 2022  by defining a correct and deterministic PKE, which is assumed to be OW-CPA. Then an IND-CCA KEM is obtained from it by making small changes to the Saito-Xagawa-Yamakawa variant of NTRU-HRSS-KEM ( [28]). The Round 3 submission proposes parameter sets which are shown in Table 5. The authors of the NTRU submission make two different estimations for the security level of their parameter sets, depending on whether the computation model is non-local or local. Details about these models and the motivation for differentiating the security levels depending on them can be found in the submission ( [22]).

4) SABER
Saber (first proposed in [29]) is similar to Kyber, in the sense that the authors present in their Round 3 submission an IND-CPA PKE, and then they use a Fujisaki-Okamotolike transformation to obtain an IND-CCA KEM. In addition, the PKE also comes with a negligible decryption failure probability, and the security is reduced to a lattice problem, in this case, the Module Learning With Rounding (MLWR) problem. The authors propose three different parameter sets for the KEM which are shown in Table 6 together with their claimed security levels.

C. FSXY: A GENERIC CONSTRUCTION FROM KEM TO POST-QUANTUM AKE
Generic transformations that convert secure KEMs into AKEs have been proposed in the standard model in [30] and [31]. These transformations give AKE protocols from IND-CCA secure KEM schemes using pseudorandom functions (PRFs). The resulting AKEs are proven secure in widely accepted security models, CK [32] and CK+ [31], respectively. Unfortunately, KEM schemes secure in the standard model are computationally inefficient for both classical and post-quantum communications.
In [17], Fujioka et al., proposed an efficient generic construction of AKE protocols from OW-CCA secure KEM schemes (which we denote by FSXY) by relaxing the security model to the Random Oracle Model (ROM). The resulting AKE protocols were proved to be CK+ secure in the ROM. Moreover, it was shown that the (ring-)LWE, McEliece one-way, NTRU one-way (among others) postquantum assumptions can be used to construct secure AKE protocols. In addition, it was shown that by adapting the ROM in the security proof of the FSXY construction, the AKE protocols obtained from each post-quantum assumption become efficient on the communication cost.
The FSXY construction is as follows. Let The session state of a session owned by U A contains an ephemeral secret key r and a KEM key K A . Similarly, the session state of a session owned by U B contains ephemeral secret keys (r 1 , r 2 ) and KEM keys (K B,1 , K B,2 ).
It was shown in [17] that if KEM 1 is OW-CCA secure, and if KEM 2 is OW-CPA secure, then the FSXY transformation is CK + secure under the Random Oracle Model.

D. BUILDING THE COMMITMENT SCHEME FROM THE KEM
The compiler described in Section II-A requires as a building block, a non-interactive non-malleable commitment scheme that is perfectly binding and achieves non-malleability for multiple commitments. Such a commitment scheme is realized by applying the transformation proposed in [33] to a KEM scheme (in particular, any Post-Quantum KEM described in Section II-B) to obtain an IND-CCA PKE from the KEM. As pointed out in [14], the commitment scheme with the required security properties follows readily from the PKE.
Let KEM = (KeyGen, EnCap, DeCap) be a key encapsulation mechanism and let SKE = (Enc, Dec) be a one-time symmetric key encryption scheme (as defined in Section 7.2 of [33]). The key lengths of both primitives must be the same for any value of the security parameter . Then, a PKE scheme PKE is obtained as follows.
The key generation algorithm for PKE is the same as that of KEM, and, hence, the secret and public keys for PKE are the same as those of KEM. That is, PKE runs KeyGen and obtains (sk, pk), where sk and pk are the secret and public key, respectively. The encryption algorithm for PKE runs as follows. Upon receiving a message m, PKE runs the encapsulation algorithm of KEM and obtains (k, ξ ) ← EnCap(pk; r), where k is a symmetric key, r are random coins, and ξ is a ciphertext encrypting k. The message m is encrypted using the key k and the encryption algorithm of SKE, ν ← Enc(k, m). The output of the encryption algorithm is c = (ξ, ν).
The decryption algorithm is defined as follows. Given a ciphertext c = (ξ, ν), PKE runs the decapsulation algorithm of KEM and obtains k = DeCap(sk, ξ ), and then runs the decryption algorithm of SKE with the key k to obtain m = Dec(k, ν). The output of the decryption algorithm is the plaintext m.
As shown in [33], the IND-CCA security of PKE is inherited form the IND-CCA sucrity of KEM and SKE. As pointed out in [14], it is known that in the CRS model with a common reference string ρ, the required commitment schemes depending on ρ can be constructed from any public-key encryption scheme that is non-malleable and secure for multiple encryptions (in particular, from any IND-CCA secure public-key encryption scheme).
The approach in this section is usually known as the KEM-DEM paradigm, where DEM stands for data encapsulation mechasism. Here the algorithm SKE plays the latter role, so we will usually refer to it as the DEM.

III. SECURITY MODEL
In this section we present the security model under which our protocol is proven to be secure. The model is taken from [14] which is in turn based on the one from Bellare et. al. [34]. We assume a fully connected communication network, that is, each pair of users are able to communicate through a point-topoint channel. We consider an active adversary who is in full control of the network: it has the power to eavesdrop, delay, insert or delete messages in communication flow at will.

A. PROTOCOL INSTANCES
Let U 0 , U 1 , U 2 , . . . , U n−1 be the set of participants. Each of them may run any polynomial number of protocol instances in parallel. Given i ∈ {0, 1, . . . , n − 1} and s i ∈ N we denote with s i i the s i -th instance vinculated to user U i . Each instance s i i has seven variables associated with it: • used s i i is a boolean variable which indicates if this instance has been used in a protocol run; it is set to true only if the instance receives a protocol due to a call to the Execute or to the Send oracle (described later).
• state s i i stores all the protocol information that the instance needs during the protocol execution together with long term keys.
• term s i i is a boolean variable which indicates if the execution has finished.
• sk s i i stores the session key if it has been accepted by the instance; before it is initialized to a distinguished null value.
• acc s i i is a boolean variable indicating if the instance has accepted the session key.
• sid s i i stores a public session identifier for the session key sk s i i . • pid s i i stores the set of identities of participants that are involved in the instance execution, including U i .

B. ADVERSARIAL CAPABILITIES
An adversary A is a polynomial probabilistic time algorithm. The adversarial power is modelled by providing A access to several oracles during a security game (described later). The oracles are the following: Executes a complete protocol run within the specified instances. It outputs a transcript of all sent messages. A query to this oracle models a passive eavesdropping by A.
The output of this oracle depends on a bit b chosen uniformly at random at the beginning of the security game. The adversary may query this oracle only if the session key is defined (that is, acc s i i = true and sk s i i = null) and the instance s i i is fresh (freshness is defined later in this section). Then, the session key sk s i i is returned if b = 0 or a value chosen uniformly at random from the key space is returned if b = 1. In this model, an arbitrary number of Test queries is allowed; but, once a value has been returned for an instance s i i , subsequent queries for all instances partnered with s i i will return the same value (partnering is defined later in this section).
• Corrupt(U i ): Returns all long-term secrets of user U i .

C. SECURITY DEFINITIONS
First we need a definition of partnering, which indicates that two instances are participating in the same protocol session. Before providing the definition of a secure protocol we need to limit when a query to the Test oracle, to avoid trivial attacks from the adversary.
Definition 4: A Test query should only be allowed to instances holding a key that is not for trivial reasons known to the adversary. To achieve this, an instance s i i is called fresh if none of the following condition holds: • For some U j ∈ pid s i i a query Send(U k , s k , M ) after a query Corrupt(U j ).
• The adversary have queried Reveal(U j , s j ) with s i i and s j j being partnered. The last notion we need before defining a secure group key establishment protocol is adversarial advantage.
Definition 5: Given a security parameter and an adversary A, the advantage Adv A ( ) in attacking the protocol is a function in , defined as where Succ is the probability that the adversary queries Test only on fresh instances and outputs correctly the bit b used by the Test oracle (without later breaking the freshness of those instances queried with Test).
Definition 6: We say that an authenticated group key establishment protocol is secure if for every adversary A we have that where negl is a negligible function.

IV. OUR GAKE CONSTRUCTION
In this section we describe our GAKE protocol for n ≥ 2 users or parties U 0 , U 1 , U 2 , . . . , U n−1 . They are organized in a cycle: each user U i has as his left neighbour U i−1 and as his right neighbour U i+1 . The indices are taken modulo n, so U n means U 0 and U −1 means U n−1 . We assume that each user is aware of his index and the rest of the indices identifying the other users of the protocol.
For the construction of the GAKE we use the following primitives: Dec) is an one-time symmetric key encryption scheme used as a DEM.
• H is a hash function (theoretically modeled as a random oracle).
To obtain the GAKE, we feed the tools described in Sections II-A, II-C and II-D with these primitives (Fig. 2). First we instantiate a 2-party AKE with the FSXY transformation from Section II-C, using KEM as both KEM 1 and KEM 2 . Note that the security notion IND-CCA is well known to imply both the OW-CPA and OW-CCA requirements for KEM 1 and KEM 2 . The resulting 2AKE satisfies the strong security notion CK+ ( [31]), which is enough for the compiler described in Section II-A. We would like to stress that, as pointed out in [35], an integrity property is also needed for 2AKE in order to attain the claimed security notion. It is a straightforward comprobation that the 2AKE obtained from FSXY has integrity because of the way session identifiers are computed. The other ingredient needed for the compiler is a commitment scheme, which is also obtained from KEM as described in Section II-D. Note that all the KEMs enumerated in Section II-B fulfill the IND-CCA security and can be used in our construction. Finally, the hash function H is used to derive session identifiers and keys, both in the 2AKE and the final step of the protocol. It is worth pointing out that the resulting GAKE achieves security in the model described in Section II-A, which covers strong adversaries that are in full control of the communication network and may delay, eavesdrop, insert, and delete messages at will.
Next, we describe the resulting GAKE protocol which is composed of 4 rounds of communication: Init: Each U i is assumed to hold a pair (dk i , ek i ) generated with KeyGen. Here ek i is the long-term public encapsulation key for U i and is assumed to be certified and known by the rest of the users, whereas dk i is the long-term secret decapsulation key for U i .
Round 1-2: For each i ∈ {0, 1, . . . , n − 1} the 2AKE is run between U i and U i+1 . The two rounds are as follows: Round 1: Each U i follows these steps: -Generates an ephemeral key pair -Generates another encapsulated key -Computes key (shared with U i−1 ) . Round 3: Each U i follows these steps: • Generates randomness r i ← RSE for KEM and a random IV i for DEM.
• Sets commitment to com i = (c i , C i ) and stores randomness r i = (IV i , r i ).
• Broadcasts M 1 i = (U i , com i ). Round 4: Each U i follows these steps: • Checks that X 0 ⊕X 1 ⊕· · ·⊕X n−1 = 0 and the correctness of the commitments. If any one of these conditions fails, then U i ends the protocol execution.
• Computes the n − 1 values K j for j = 0, 1, 2, . . . , n − 1 with j = i, • Defines session key sk i and session identifier sid i as (sk i ||sid i ) = H (K 0 , . . . , K n−1 , U 0 , . . . , U n−1 ). Next, we provide some comments pointing out differences between the compiler described in Section II-A and our implementation and also explaining some design choices and protocol steps in more detail: • The input of KeyGen() in the asymptotic description of the KEM is the security parameter. In our implementation KeyGen() outputs keys of fixed length for each KEM and parameter set, so it has no input. The sets {0, 1} f ( ) and RSE are the randomness spaces described in Section II-C.
• To compute the commitment com i to X i , first an encapsulated key κ i is generated with EnCap. Then the message i||X i (where || denotes concatenation) is encrypted with Enc using key κ i . The randomness r i used by EnCap needs to be stored by U i to open the commitment in the next round. Therefore we needed to modify EnCap for each KEM in our implementation to make the randomness an explicit output of the algorithm instead of being generated by the algorithm itself.
• The verification of the commitments in Round 4 is done by recovering the key κ i from r i with EnCap, then generating a new commitment com i with X i and r i and checking that com i and com i are equal.
• In the original compiler, the final key and session identifier derivation is done with a collision-resistant pseudorandom function family. The reason for using this tool is that, if the 2AKE has a security proof in the standard model, the compiled GAKE is also secure in the standard model. As the FSXY transformation already uses a hash function, our GAKE is only secure in the random oracle model, so we have chosen to simplify the compiler and use the same hash function for key and session identifier derivation.
• The hash function we have chosen in our implementation has output length which is double of the GAKE session key length. So the hash value H ( ← − K 0 , ← − K 1 , . . . , ← − K n−1 , U 0 , U 1 , . . . , U n−1 ) is computed and sk i is set to be the first half of this value and sid i is set to be the second one.

A. SECURITY OF OUR PROPOSED GAKE PROTOCOL
Next we prove a security result for our protocol under the security model described in Section III.
Theorem 1: In the random oracle model, the protocol presented in Section IV is a correct and secure authenticated group key establishment protocol fulfilling integrity.
Proof: We follow the security proof of Theorem 1 in [14]. Correctness. It is easily verified that in an honest execution of the protocol, all participating users will terminate by accepting and computing the same session identifier and session key.
Integrity. As a consequence of the collision-resistance of the random oracle H , all oracles that accept with the same session identifiers also hold, with overwhelming probability, identical session keys K 0 , . . . , K n−1 and associated these keys with the same participants U 0 , . . . , U n−1 .
Key secrecy. The proof of the secrecy is organized in a sequence of games, starting with a real attack of an adversary A against the key secrecy of the GAKE protocol and ending in a game in which the advantage of the adversary is negligible. The idea is that we can bound the difference of the adversary's advantage between any two consecutive games. We denote the advantage of the adversary in Game i, as usual, by Adv(A, G i ). For the sake of clarity, we classify the Send queries into three categories depending on the stage of the protocol to which the query is associated. More preceisely, Send-t denotes the Send query associated with round t.
The first three games of this proof coincide with the same as those in Theorem 1 of [14]. Here we summarize the bounding of the adversary's advantage and refer the interested reader to the original paper for the details.
Game 0. In this game, a real attack is performed by the adversary A, in which all the parameters such as the public parameters and the long-term secrets of each user are chosen as in the actual scheme. By definition we have It is not difficult to see that the difference between the advantage of this game and the previous one is bounded by the probability that the adversary breaches the security of any of the underlying 2AKE protocols executions. Therefore, VOLUME 10, 2022 we have where q send denotes the number of distinct protocol instances in Send queries. Game 2. Here, the simulation of the Send oracle is modified so that a fresh instance s i i does not accept in Round 4 whenever one commitment com j , j = i, it receives in Round 3 was generated by the simulator but not generated by the respective instance s j j in the same session. If the adversary A replays a commitment that should have let to acceptance in Round 4 in Game 1, then A detects the difference between this and the previous games. Therefore, Game 3. In this game, the simulation of the Send oracle changes so that a fresh instance s i i does not accept in Round 4 whenever one commitment com j , j = i it receives in Round 3 was generated by the adversary. The advantage of the adversary differs from the previous game by a negligible amount, that is, On the other hand, the simulator keeps a list of strings (K 0 , . . . , K n−1 , U 0 , . . . , U n−1 ) and once an instance receives the last Send-4 query, the simulator computes K 0 , . . . , K n−1 and checks if for the corresponding string (K 0 , . . . , K n−1 , U 0 , . . . , U n−1 ) has already been used. If this is the case, the simulator assigns the corresponding string to the instance. If no such strings exist, the simulator assigns a session key sk s i i ∈ {0, 1} uniformly at random. Note that even if the messages from Round 4 are sent out, the list of strings still contains sufficient entropy so that the output of the random oracle H is indistinguishable from a random sk s i i with overwhelming probability. Consequently, Together, all the bounds obtained in the games imply that Adv(A) ≤ 2 · Adv 2AKE ( , 2 · q send ) + negl( ).

V. IMPLEMENTING THE GAKEs
In the following, we describe the implementation of the GAKE protocol, which is publicly available at https: //github.com/jiep/pq-gake-fsxy. To do so, we describe separately each of the building blocks that make up the protocol.

A. BUILDING BLOCKS 1) KEM
The KEMs are taken from the open-source library LibOQS ( [37]). It provides all the finalist implementations submitted to the NIST standardization process. 2 It has been developed by the Open Quantum Safe project, which aims at prototyping and experimenting with post-quantum cryptography, but as of today, it is not production-ready. It is written in C99 and its advantages include: • Dynamic management of the KEMs, making it possible to exchange one for the other without the need to modify the code of the protocol.
• Building the library with only the KEM implementations that are needed in the application.
• Provides common functions (e.g. hash and random bits functions, among others). LibOQS provides 10 parameter sets for Classic McEliece, 3 for Kyber, 3 4 for NTRU, and 3 for Saber. Table 7 shows the key sizes (public and secret), the size of the shared secret and ciphertext, as well as the claimed security level and security model of all parameter sets in LibOQS. It can be noted that the public key size of Classic McEliece is several orders of magnitude larger than the other KEMs. On the other hand, the ciphertext size is smaller than the other finalists in the standardization process.
Two different implementations come from each parameter set: the reference implementation (called ref, clean, or vec by the KEMs) and the optimized implementation (named avx2 or avx). All information on these implementations can be found in Table 8. It can be noted that the reference implementations do not present any architecture or operating system limitation, whereas the optimized implementation runs only on the x86_64 architecture for macOS and Linux operating systems. It is noteworthy that the Classic McEliece implementations have large stack usage and may cause failures when run on threads or in constrained environments ( [36]).
The KEM is the basic building block on which the subsequent ones depend.

2) 2-PARTY AKE
The 2AKE has been implemented by following the FSXY transformation of Fig. 1. It has been split into three algorithms: • Init: the algorithm that runs U A at the beginning of the protocol and outputs message − → M .
• AlgB: the algorithm that runs U B by taking the message − → M and outputs the message ← − M and the session key SK. • AlgA: the algorithm that runs U A at the end of the protocol by taking as input the message ← − M and outputs the session key SK. Note that Init corresponds to Round 1 of our GAKE description in Section IV whereas AlgB and AlgA constitute Round 2.
In the implementation, KEM 1 = KEM 2 and the hash functions H 1 and H 2 are SHA3-256 provided by LibOQS.

3) COMMITMENT SCHEME
The commitment scheme has been implemented as an IND-CCA PKE with the KEM/DEM approach (see details in Section II-D), with the KEM being any of those implemented in LibOQS and the DEM being set to AES256-GCM imported from OpenSSL 1.1.1f ( [38]). The commitment is given by the ciphertext of the KEM and the tag of the DEM. The randomness r i is given by the coins of the KEM and the IV of the DEM. Note that in Round 4 of the GAKE protocol, r i is broadcast, so it was required to modify all LibOQS implementations (see Table 8) to make the KEM deterministic to preserve the randomness.
Three algorithms are implemented: • Init allocates space for KEM and DEM ciphertexts.
• Commit creates a commitment as described in Section II-D.
• Check creates a commitment and checks if it is equal to a commitment created previously.

B. GAKE PROTOCOL
The GAKE protocol has been implemented using the aforementioned building blocks. All hash functions come from the SHA-3 hash functions implemented in LibOQS. In addition, the implementation assumes a zero-delay communications network.
The protocol allows for a polynomial number of instances running in parallel. Hence, certain variables are required to keep the state of the instance. These are inherited from the Abdalla et al.'s compiler ( [14]): • public_key contains authentication public key. • secret_key contains authentication secret key. • pid contains the user identifiers U i that are involved in the protocol instance.
• sk is the session key. Its size is 32 bytes. By default, its value is set to 0 256 .
• sid is the public identifier for sk. Its size is 32 bytes.
• term is a boolean variable that indicates whether an instance has terminated. In the implementation, 0 indicates false and 1, true.
• acc is a boolean variable that indicates whether an instance has been accepted.
• Other variables that contain all the needed values for the protocol (e.g.

1) INIT
During the Init phase, all parties generate their long-term authentication keys, and all the public keys are assumed to be known by the rest of the users.

2) ROUND 1-2
During Round 1-2, two types of messages are exchanged: • Message − → M contains a public key, a ciphertext, and U A and U B . The size of U A and U B is set to 20 bytes.
• Message ← − M contains two ciphertexts, as well as U A and U B . Their size depends on the KEM in use (see Table 7). VOLUME 10, 2022

4) ROUND 4
In Round 4, n messages M 2 i are broadcast. The message contains U i and the randomness r i (coins of the KEM and IV of the DEM). The size of X i is 32 bytes and the IV is 12 bytes. The size of coins depends on the KEM being used (see Table 7).
The session key sk and sid is generated from master key K with SHA3-512, where first 32 bytes are set to be the sk and last 32 bytes are set to be the sid. Fig. 3 shows a run of GAKE protocol for Kyber1024 and Classic-McEliece-8192128f with 100 parties. See Appendix A for a complete run of the protocol.

C. BENCHMARKING ENVIRONMENT
A workflow has been developed on GitHub Actions that allows reproducing the experiments in an isolated environment. The workflow is described in Fig. 4 and includes all the required steps from building the GAKE protocol binaries to executing them and obtaining the experimental results. The workflow runs on an Ubuntu 20.04 runner hosted on GitHub Actions and consists of 4 steps: 1) Build: It builds all the binaries and the libraries they depend on. Fig. 5 shows the complete process. A A custom library is built from the LibOQS v0.7.0 library ( [37]). In it, all the KEM implementations have been modified to be deterministic to keep the randomness of the commitment scheme. Its building has been automated with CMake by enabling the options -DOQS_ DIST_BUILD = ON and -DOQS_MINIMAL_ BUILD = "${ENABLED_ALGS}", where ENABLED_ALGS is an array that enables desired KEMs (see details in [36]). It enables only the algorithms specified in the LibOQS library in Table 7. In addition, OpenSSL 1.1.1f is statically • TIME_OPERATION_ITERATIONS: It executes a piece of code for a given number of iterations.
• TIME_OPERATION_SECONDS: It executes a piece of code for a given number of seconds. All experiments are run with the former macro. This step is run on a self-hosted runner with Ubuntu 20.04 on WSL2 ( [39]) under Windows 10 on with specifications given in Table 9. This was done with this approach because runners hosted on GitHub Actions can only run for a maximum of 6 hours ( [40]), which is not enough time to run all the necessary experiments.
The tests defined in this step are: • test_speed_kem: This test measures the performance (in CPU cycles and execution time) of each KEM implemented in LibOQS (see Table 7). Key generation, encapsulation, and decapsulation are measured separately. The result of this test is an average of 10 000 iterations.
• test_speed_ake: It measures the performance of the FSXY transformation for each of the KEMs implemented in LibOQS. Each algorithm of the transformation is measured independently.   The result is an average of the execution of 10 000 iterations.
• test_speed_commitment: It measures the performance of the commitment scheme for each of the KEMs implemented in LibOQS. The DEM is always fixed to AES256-GCM. 10 000 iterations are run to measure the performance of key generation, generate a commitment and check it.
• test_speed_gake: It measures the performance of the GAKE protocol for each of the KEMs implemented in LibOQS based on the number of parties, n, running the protocol. It is run for n = 2, 2 2 , . . . , 2 11 = 2048. In addition, the performance of each round of the protocol is measured separately. All of the tests above generate tables that are converted to CSV format to be processed in the subsequent steps.
3) Generate graphics: This step generates the graphics of Section VI. The graphics are plotted with Python and the seaborn visualization library ( [41]). All graphics are saved in png format. 4) Release: It creates a new release on GitHub and uploads all the data that has been generated during the workflow, which was stored in Artifacts on GitHub Actions ( [42]): binaries, graphics, and CSV files.

VI. EXPERIMENTAL RESULTS: COMPARISON AMONG THE FOUR KEMs
In this section, we compare the experimental results achieved from the aforementioned tests. More precisely, we present the results of the tests described in Section V-C. For each of the four KEMs and each security level, we compare the performance of all the cryptographic primitives involved, including all the underlying operations (algorithms) of each of them. Namely, KEM, the two-party AKE, the commitment scheme and, finally, the GAKE protocol. Note that we only compare the optimized implementation of each parameter set (see Table 8). Numerical results can be found in Appendix B. Fig. 6 shows the performance of each KEM operation for each security level. It can be observed that, for all security levels, the KeyGen algorithm is significantly slower on Classic McEliece than on the other KEMs. This is caused by the huge size of the keys in Classic McEliece (see Table 7). The Encaps algorithm does not show significant differences, whereas the Decap algorithm does show this difference Classic McEliece vs. other KEMs, but it is not as meaningful as in the case of the KeyGen algorithm. Fig. 7 shows the performance of the AKE achieved from the FSXY transformation (Fig. 1). It can be seen that, for each security level and each AKE algorithm, the performance difference between Classic McEliece and the rest of the schemes is significant. This is because the AKE is KEM dependent, with the KeyGen and Decap algorithms being slower in Classic McEliece than in the other KEMs.
Concerning the commitment scheme (Fig. 8), Classic McEliece is faster during the Init algorithm. This is mainly because Classic McEliece ciphertexts are smaller than the rest (see Table 7). The Commit and Check algorithms perform better with NTRU, at any security level. Fig. 9 shows the performance of the GAKE protocol in each round. The Init round initializes the structure and variables needed to store the state of the protocol instance. It can be observed that Kyber is noticeably more efficient than the rest of the schemes, at any security level. In Round 1-2 (AKE) and Round 3 (commitment generation), the same applies: Kyber parameter sets offer the best performance. Finally, in Round 4 (commitment checking, master key derivation, and session key generation) the performance at security level 1 is very similar among the parameter sets. The most efficient is NTRU-HPS-2048-677 for level 3 and NTRU-HPS-4096-821 for level 5. Fig. 10 shows the performance of the GAKE protocol as a function of the number of parties participating in the protocol. It can be noted that, at all security levels, Classic McEliece is significantly less efficient than the rest of the KEMs and this is found to worsen as the number of parties in the protocol  increases. The most efficient at security level 1 is Kyber 512, at level 3 is NTRU-HRSS-701, and at level 5 is Kyber1024. VOLUME 10, 2022  In this section, we provide experimental comparisons between the performance of the the FSXY transformation described in Section II-C with the FO AKE transformation ( [18], [19]) used in [11] on Kyber. In this section, we compare experimentally the performance of the FSXY transformation described in Section II-C with the FO AKE transformation ( [18], [19]) used in [11] on Kyber. The latter is a novel transformation analogous to FSXY, i.e., it derives a secure two-party AKE from another cryptographic primitive (in this case, from an IND-CPA public-key novel encryption scheme). FO AKE is proved to be secure in the QROM, but it cannot be applied to just any KEM, only to those that satisfy several properties (see details in [19] and [11]). It is shown in [11] that it can be applied to Kyber. Table 10 shows a theoretical comparison between FSXY and FO AKE transformations. The FO AKE transformation consists of 2 messages in the same way as the FSXY transformation, but the former sends messages − → M and ← − M that do not contain U A and U B , which, consequently, produces messages of a smaller size. As in Section VI, we compare the performance of all the involved operations of each security level of Kyber. Fig. 11 shows the comparison between both transformations with Kyber. It can be seen that the FO AKE transformation performs better than FSXY. The results show that, if Kyber is applied as KEM on this GAKE protocol, FO AKE should be considered instead of FSXY providing, in addition, a higher level of security by being secure in the QROM.

VII. CONCLUSION
This paper shows the performance of a post-quantum key authenticated key exchange (GAKE) protocol constructed by applying the generic FSXY transformation to the all NIST finalist post-quantum KEMs. The protocol has been implemented with LibOQS, an open-source library that provides all the finalist KEMs of the NIST standardization process.
We show experimentally that Classic McEliece is not suitable in this GAKE because it is significantly slower than the other KEMs. The most appropriate KEM for security level 1 is Kyber 512, for level 3 is Kyber768 and NTRU-HRSS-701, and, for level 5 is Kyber1024. In addition, the FO AKE transformation is compared against FSXY on Kyber, showing that the latter is significantly faster than FSXY and provides a higher level of security by being QROM secure. This last result is especially noteworthy considering that Kyber is the first post-quantum KEM that will be standardized by NIST.

APPENDIX A COMPLETE RUN OF THE GAKE PROTOCOL
Here, we show a complete run of GAKE protocol with Classic-McEliece-8192128f for 3 parties (for brevity). VOLUME 10, 2022 Tables 11-18 show numerical results for each graphic shown in Section VI.            JOSÉ IGNACIO ESCRIBANO PABLOS received the double degrees in mathematics and software engineering, the master's degree from Universidad Rey Juan Carlos, Spain, in 2015 and 2017, respectively, and the Ph.D. degree in mathematical sciences. He also works as a Machine Learning and Security Researcher at BBVA Next Technologies. His main research interests include postquantum cryptography, machine learning security, and adversarial machine learning.

APPENDIX B NUMERICAL RESULTS OF TESTS
MISAEL ENRIQUE MARRIAGA received the Ph.D. degree in mathematical engineering from Universidad Carlos III de Madrid, Spain. He is currently an Assistant Professor (Profesor Contratado Doctor Interino) at the Universidad Rey Juan Carlos, Spain. His main field of research is approximation theory in higher dimensions and multivariate orthogonal polynomials. Most recently, he has started doing research in cryptographic designs for multi-party key exchange in non-standard scenarios.
ÁNGEL L. PÉREZ DEL POZO received the Ph.D. degree in mathematics from Universidad Complutense de Madrid (Spain). He is currently an Assistant Professor (Profesor Contratado Doctor Interino) at the Universidad Rey Juan Carlos, Spain. His main research interests include cryptographic designs for key exchange in nonstandard scenarios, secret sharing schemes, and applications of multi-party computation.