Design and Implementation of Constant-Round Dynamic Group Key Exchange from RLWE

,


I. INTRODUCTION
These days, network topology is becoming more and more complicated such as group chatting in instant messaging applications, file sharing between multiple parties, etc. Hence, secure communication between multiple parties is required to keep the confidentiality of their messages.
Key establishment is a pre-determined protocol where two or more parties make a shared secret for subsequent cryptographic use [1]. This can be subdivided into key transport and key agreement protocols. Key transport protocol enables one party to create a secret value and securely transfer it to other parties but key agreement protocol derives the shared secret of two or more parties as a function of information contributed by each party, so that no party can estimate the result.
The associate editor coordinating the review of this manuscript and approving it for publication was Yanjiao Chen .
A group key exchange (GKE) protocol provides a set of specific cryptographic procedures that establishes a group secret key that is derived from group members. Compared to secret sharing scheme, GKE protocol allows distinct keys for distinct groups while secret sharing scheme starts with a secret and divides it into pieces called shares. Information exchanged between parties in GKE protocol is non-secret and transferred over open channels, while shares are distributed secretly. Each party individually computes the session key in GKE protocol but pooling shares can be reconstructed among K participants of all N parties where K ≤ N for secret sharing scheme [1]. In general, GKE protocol consists of three phases: key generation phase, intermediate value broadcasting phase, and key computation phase.
Authenticated key exchange protocol authenticates the identity of parties in the protocol to prevent any attacks like the man-in-the-middle attack even in the presence of active adversaries who controls the underlying communication by eavesdropping and modifying transmitted messages during communication over a network.
To construct (authenticated) GKE protocol, we need to define the computational power of a group member. If all group members are assumed to have equal power, we need to handle some disputes that happen by the malicious actions of group members. To overcome this issue, a trusted authority (TA) must be provided as a communication infrastructure, but it is quite costly.
As the membership status of a party changes or remains the same, we say GKE protocol is in either a static or a dynamic setting. The static setting keeps membership status for a long time while the dynamic setting provides frequent membership status changes in a short time, i.e., any member can join or leave the protocol at any time in a dynamic setting. It is suitable to deploy a TA in a protocol in a static setting, but hard to deploy a TA in a dynamic setting such as resource-constrained environments like IoT. There have been numerous publications on GKE protocols [2]- [20].
It is well-known that quantum algorithms like Shor's algorithm [21] can solve number-theoretic problems like integer factorization and discrete logarithm problems including their elliptic curve versions in polynomial time so that quantum adversaries can break the cryptographic protocol like RSA, Diffie-Hellman key exchange, or ECDSA. Since quantum computers may be realized in a decade or so in a best-case scenario, the National Institute of Standards and Technology (NIST) has been soliciting standard post-quantum cryptographic algorithms such as key exchange, encryption, and signature schemes. (Authenticated) GKE protocol is out of the scope of this competition. Beyond NIST post-quantum algorithm standardization, there are a few publications on post-quantum GKE protocols. Ding et al. [22] constructed the first lattice-based GKE protocol and Yang et al. [15] and Apon et al. [16] independently suggested constant-round lattice-based GKE protocols, where constant-round means that the number of phases for each party does not change regardless of the number of group members.
While Ding et al. and Apon et al.'s protocols do not rely on a TA to agree on a group secret key among the group members, Yang et al.'s protocol requires the role of a TA that calculates the group secret key by getting the ephemeral key of each party and sends it to each party.
However, to the best of our knowledge, there exists no post-quantum dynamic GKE in the open literature regardless of the existence of TA. Our goal is to design a novel post-quantum constant-round dynamic GKE protocol from Ring Learning with Errors (RLWE) without a TA and provide implementation details with pseudocode as a proof of concept that can be a reference implementation of other quantum-resistant group key exchange protocols since there are no public-domain implementation result to our understanding.
The organization of this paper is as follows: We introduce the basic terminologies including notations and definitions used to design our protocol in Chapter II. Previous works and a security model of GKE are given in Chapter III and IV, respectively. Our key idea to design a novel dynamic GKE protocol is discussed in Chapter V and a full description with a detailed procedure is given in Chapter VI. Then, we give a rigorous security proof of our dynamic (authenticated) GKE protocol in Chapter VII. We compare our dynamic authenticated GKE protocol with the previously known lattice-based GKE protocols and give implementation details in Chapters VIII and IX, respectively. Finally, the conclusion is summarized in Chapter X with future work.

II. PRELIMINARIES A. NOTATIONS AND DEFINITIONS
Let Z be the set of integers and [N ] = {0, 1, 2, · · · N − 1}. For a set A, x i ← A denotes a uniformly random sampling of x i ∈ A. Let χ(E) stand for the probability of a set E of events to occur under distribution χ. We set Supp(χ) = { : χ( ) = 0} and letĒ be the complement of an event set E. Let f (a, b) be a function f on a and b. A function g(x) is negligible when g(x) ≤ x −c for all c > c 0 when c 0 is large enough.
Given a polynomial p, (p) j denotes the j-th coefficient of p. log(x) and exp(x) are notations for log 2 (x) and e x , respectively. P[0, 1, · · · , k] = {P 0 , P 1 , · · · , P k } means an array of parties where P i denotes the i-th party of a group. λ is a computational security parameter used as a security level of a cryptographic primitive and ρ denotes a statistical security parameter used in Gaussian distributions.

B. RING LEARNING WITH ERRORS
We set public parameters R, q, χ , l for RLWE problem as below: 1) R = Z[x]/(f (x)) is a polynomial ring where f (x) is an irreducible polynomial, 2) q is a positive integer modulus defining a quotient ring R q = R/qR = Z q [x]/(f (x)), 3) χ = (χ s ; χ e ) is a pair of noise distributions over R q where χ s is a secret-key distribution and χ e is an error distribution concentrated on small elements, 4) and u is the number of samples that are given to the adversary. Decisional RLWE problem [23] is defined as to distinguish whether samples {a i , b i } are either (1) RLWE instances, i.e., b i = a i s + e i ∈ R q with uniform a i ∈ R q , secret key s ← χ s and error e ← χ e or (2) uniformly sampled from R q × R q .
Adv RLWE n,q,χ s ,χ e ,u (B) denotes the advantage of adversary B for decisional RLWE and Adv RLWE n,q,χ s ,χ e ,u (t) denotes the maximum advantage of any adversary B in time t. If χ = χ s = χ e , we write Adv RLWE n,q,χ,u for simplicity.

C. RÉNYI DIVERGENCE
For two discrete probability distributions P and Q with Supp(P) ⊆ Supp(Q), their Rényi divergence is defined as Rényi divergence measures the closeness of two probability distributions and widely used in cryptographic research [23]- [26]. We introduce some important results related to Rényi divergence. Proposition 1 [26]: For discrete distributions P and Q with Supp(P) ⊆ Supp(Q), let E ⊆ Supp(Q) be an arbitrary event. We have Intuitively, the proposition says that if RD 2 (P Q) is bounded by some polynomial, then any event set E that occurs with negligible probability Q(E) under Q also occurs with negligible probability P(E) under P.

D. GENERIC KEY RECONCILIATION MECHANISM
The concept of a key reconciliation mechanism was first introduced by Ding et al. [22] to handle error between two approximately agreed ring elements in their lattice-based key exchange protocol. Since then, this mechanism has been widely used in several publications on lattice-based two-party key exchange protocol [27]- [31]. Based on Apon et al.'s paper [16], we describe a generic key reconciliation mechanism that is performed between two parties in the key computation phase.
A key reconciliation mechanism KeyRec = (recMsg, recKey) allows two parties to derive the same shared secret key from approximately agreed ring elements. One of two participants runs recMsg taking the security parameter λ and a ring element b ∈ R q and outputs rec and a key k ∈ {0, 1} λ . The other participant runs recKey taking rec and a ring element b ∈ R q and outputs a key value A key exchange protocol works correctly when two participants have the same shared secret key (i.e. k = k ). To hold this equality, b and b have to be sufficiently close. In particular, if b − b is bound by some value β Rec , two participants share the same shared secret key from the output of KeyRec except with negligible probability.
Security is defined by the indistinguishability between shared secret key k, the result of key exchange, and a uniformly random value. Formally, an attacker A is computationally infeasible to distinguish two distributions, For a fixed value of λ, we denote the advantage of adversary A in distinguishing these two distributions by Adv KeyRec (A), and the maximum advantage of any such adversary running in time t by Adv KeyRec (t).

III. PREVIOUS WORKS
A. CONSTANT-ROUND GROUP KEY EXCHANGE Burmester and Desmedt [7] proposed the first constant-round GKE protocol (hereinafter, BD94). In BD94, all participants in a protocol are assumed to form a ring topology to generate a group secret key and every group member participates in key generation with equal privilege during the protocol execution. This property is called contributory. Just and Vaudenay [32] proposed an authenticated GKE protocol by combining the idea from BD94 and a public key signature scheme. This protocol is more efficient than BD94 from the view of communication bandwidth but requires four-round to generate the group secret key.
A compiler proposed by Katz and Yung (hereinafter, Katz-Yung compiler) [5] can convert any unauthenticated GKE protocol into an authenticated one. They also suggested an authenticated GKE protocol by applying Katz-Yung compiler to BD94.
For dynamic GKE, Kim et al. [33] suggested a two-round authenticated GKE protocol for an ad-hoc network, in which no TA is involved. In their protocol, XOR operation is introduced into the generation of the group secret key to reduce the computational cost of each group member. For a dynamic setting, the computation and communication overheads of each group member rely on the number of joining/leaving members rather than relying on the number of previous group members. Dutta and Barua [6], [34] proposed a two-round authenticated GKE protocol (hereinafter, DB05), which is constructed by combining a variant of BD94 and a signature scheme modified from [5]. For a dynamic setting, the membership addition procedure generates a new group secret key by making a new ring topology with the joining members with the support of the previously agreed group members. For the membership deletion procedure, a new ring topology with the remaining members is formed to run the protocol.

B. SECURITY MODEL OF GROUP KEY EXCHANGE
Bresson et al. [2] suggested the first formal security model called BCPQ model for authenticated GKE protocols in a static setting. In their paper, they defined AKE security and mutual authentication (MA) security. AKE security guarantees that an active adversary who does not participate in the session cannot distinguish a group secret key from a random number. MA security ensures that only legitimate participants can compute an identical session group secret key.
After that, Katz and Yung [5] revised this model to compile unauthenticated GKE protocol into authenticated GKE protocol. They proved the security of BD94 [7] in the presence of a passive adversary who can only eavesdrop on messages and 94612 VOLUME 8, 2020 make a compiler from unauthenticated GKE to authenticated GKE with an active adversary. After that, Katz and Shin [35] proposed another compiler that can transform an implicitly secure authenticated GKE into a secure authenticated GKE resistant to insider attacks, with the universally-composable (UC) model.
For a dynamic setting, Bresson et al. [3], [4] suggested two formal security models for authenticated GKE protocols depending on the power of corruption and the presence of MA security. A strong corruption model enables an adversary A to reveal the long-term secret key as well as the ephemeral keys or internal states of the protocol but a weak corruption model only leaks the long-term secret key of the party while the ephemeral keys or internal states of protocol participants are not corrupted.

C. LATTICE-BASED KEY EXCHANGE
Ding et al. [22] suggested the first lattice-based key exchange protocol in 2012 by modifying Diffie-Hellman key exchange protocol [36] into RLWE setting. Following this research, numerous publications [15], [16], [27]- [31], [37]- [48] have looked at the construction and implementation of key exchange protocols based on lattices, but most of them are only designed for two-party key exchange.
For lattice-based GKE protocol, Diffie et al. [36] suggested the natural extension to GKE protocol (hereinafter, DXL12.G) based on their key exchange protocol using the GKE compiler by Bresson et al. [3]. After that, Yang et al. [15] proposed the first provably-secure (authenticated) GKE protocol (hereinafter, YMZ15) based on the hardness of LWE/RLWE assumption and security property of secure sketch in the random oracle model. For the secure sketch, TA is necessary and YMZ15 is said to be not contributory.
Recently, Apon et al. [16] proposed the first constant-round authenticated GKE protocol (hereinafter, ADGK19) based on the hardness of RLWE assumption, without TA. ADGK19 uses Katz-Yung compiler for authentication and is contributory since they adopt the protocol in [7].

IV. SECURITY MODEL
We describe the adversary model by Bresson et al. [3], which is suitable for our dynamic authenticated GKE protocol since their model covers authenticated GKE with a dynamic setting with a weak corruption model.
Let P = P [0, 1, · · · , N − 1] be a set of N parties. Any subset of P wishes to establish a group secret key. We identify the execution of protocols for (authenticated) GKE or addition/deletion of a party or a set of parties as different sessions. We assume that the adversary never participates as a party in the protocol.
This adversary model allows concurrent execution of the protocol. The interaction between adversary A and the protocol participants only happens via oracle queries.
We denote a set of session identity and partner identity of the party P as sid i P and pid i P , respectively. For an instance (U j , i j ) ∈ S where U j is the j-th party and i j is the counter value that counts the number of queries that U j is requested by the given protocol or the adversary, we define sid when U [0, 1, · · · , l − 1] wish to agree on a group secret key.
Let S, S 1 , and S 2 be three sets of instances defined as: is any non-empty subset of P.
We assume that the adversary has full control over all communications in the network. All information that the adversary can get is written in a transcript since a transcript consists of all public information flowing across the network. The following oracles describe adversary's interaction with the protocol participants: • Join(S, S 1 ): This oracle models the addition of S 1 to S, where all parties in S and S 1 are in P. For S, Execute oracle has already been queried. The output is a transcript generated by the honest execution of the membership addition procedure. If Execute(S) is not preprocessed, the adversary gets no output.
• Leave(S, S 2 ): This oracle models the removal of S 2 ⊆ S from S where all parties are in P. Similar to Join(S, S 1 ), if Execute(S) is not preprocessed, the adversary gets no output. Otherwise, the membership deletion procedure is invoked. The adversary obtains the transcript from the honest execution of the membership deletion procedure.
• Reveal(U , i): This oracle models the misuse of the group secret key. This query outputs the group secret key sk i U for a session with an instance (U , i). • Corrupt(U ): This oracle models (perfect) forward secrecy. This query outputs the long-term secret key of party U .
• Test(U , i): We can query this oracle only once during the adversary's execution. A bit b ∈ {0, 1} is chosen uniformly at random. The adversary gets sk if b = 1 and a random group secret key sk if b = 0. This oracle checks the adversary's ability to distinguish a real group secret key from random. An adversary who can access for Execute, Join, Leave, Reveal, Corrupt and Test oracles is considered ''passive'' while an ''active'' adversary has full access to the VOLUME 8, 2020 above-mentioned oracles including Send oracle. (For a static case, Join or Leave queries do not need to be considered.) The adversary can ask Send, Execute, Join, Leave, Reveal and Corrupt queries several times, but Test query is asked for only once for a fresh instance. An instance (U , i) is fresh if none of the following occurs: (1) the adversary queried Reveal(U , i) or Reveal(U , j) with U ∈ pid i U , (2) the adversary queried Corrupt(U ) (with U ∈ pid i U ) before a query of the form Send(U , i, ) or Send(U , j, ) where U ∈ pid i U . The adversary outputs a guess b . Then, the adversary wins the game if b = b where b is the bit chosen from Test oracle.
Let Succ denote the event that the adversary A wins the game for a protocol XP. We define Adv A,XP := |2·Pr[Succ]− 1| to be the advantage that adversary A has in attacking the protocol XP.
The protocol XP provides secure unauthenticated/ authenticated GKE (KE/AKE) security if there is no polynomial time passive adversary A p and active adversary A a with a non-negligible advantage, respectively.
Let t be the running time for A and q E , q J , q L , q S be the number of queries to Execute, Join, Leave, Send oracles respectively. Adv KE XP (t, q E ) is the maximum advantage of any passive adversary A p attacking protocol XP and Adv AKE XP (t, q E , q S ) and Adv AKE XP (t, q E , q J , q L , q S ) are the maximum advantage of any active adversary A a attacking protocol XP.

V. METHODOLOGY
Before giving a detailed description of our dynamic GKE protocol based on RLWE, we give a key idea to modify ADGK19 into a dynamic GKE protocol. For that, we check the relationship between BD94 and DB05. Given two public parameters, a group G of prime order q and a generator g ∈ G, BD94 and DB05 in a static setting are described as below: - j=0 Y i,i+j as a shared key. All elements after computation are in G since a group is closed under addition and scalar multiplication. Phases a1 and a2 can be interpreted as key generation phase and intermediate value broadcasting phase, respectively.
After computation, each party P i receives the value z j or X j where i = j.
For key computation phase in Phase a3, DB05 requires pre-computation on the value Y i,j for each P i , which results in a simpler expression for each b i . The group secret key b i becomes g N −1 i=0 r i r i+1 for both BD94 and DB05. Similarly, by modifying the key computation phase of ADGK19, we show that yet another unauthenticated GKE protocol can be designed and also extended to dynamic GKE protocol. Given two public parameters, a ring R q and a ring element a ← R q , ADGK19 and our basic construction for static GKE protocol are described as below: -Phase b1[KeyGen] Each party P i generates a ''small'' secret value s i ∈ R q as his/her secret key and ''small'' noise e i ∈ R q and broadcasts his/her public key z i = as i + e i to all other parties.

-Phase b2[BroadIntValue]
Each party P i calculates an intermediate value • Our basic construction: All elements after computation are in R q since a ring is closed under addition and ring multiplication. For key computation phase in Phase b3, our basic construction requires pre-computation on the value Y i,j with a simpler expression for each b i like DB05.
Like two-party key exchange protocol from lattice, the output b i will be a N −1 i=0 s i s i+1 + err i for both ADGK19 and our basic construction with an error err i . However, similar to the two-party case, we can obtain the shared key by a key reconciliation mechanism when err i is small enough.

VI. OUR DYNAMIC (AUTHENTICATED) GKE
In this chapter, our (authenticated) GKE protocol with static and dynamic membership is described by replacing modular exponentiations and multiplications in DB05 into ring multiplication and ring addition in RLWE setting.
For the static setting, we set KeyRec = recMsg, recKey as a subroutine. Note that there are two security parameters for security analysis, λ and ρ, where λ is used for security proof and ρ is used for correctness check.

A. UNAUTHENTICATED STATIC GKE
In the static setting, given R q = Z q [x] /(x n + 1) and a ← R q , all parties calculate the intermediate values X i and Y i,j and agree on ''close'' values b 0 ≈ b 1 ≈ · · · ≈ b N −1 after key computation phase (Phase b3). Then, party P N −1 runs recMsg from KeyRec to allow all parties to get a common value k = k 0 = k 1 = · · · = k N −1 .
Since we only show that k is difficult to compute for a passive adversary in the security proof, we need to hash k using random oracle H to get the group secret key sk, which is indistinguishable from random. A detailed description of our unauthenticated GKE, called STUG (STatic constant-round Unauthenticated GKE), is in Protocol 1.
Broadcasts rec and gets the group secret key as gets the group secret key as sk i = H(k i )

B. AUTHENTICATED STATIC GKE
To design authenticated GKE called STAG (STatic constant-round Authenticated GKE), we need to add a digital signature scheme DSig = (K, S, V) where K is the key generation with output (sk i , pk i ) for each party P i , S outputs a signature δ i for a message m i , and V outputs whether the input signature is valid. Following DB05 [6], at the start of the session, P i does not need to know the entire session identity set sid d i P i . As the protocol proceeds, we build this set from partial session identity set psid d i P i . Initially, psid d i P i = {(P i , d i )} and after completing the procedure, psid d i P i becomes equal to the full session identity set sid d i P i . We assume that all parties know their partner identity pid d i P i .
From STUG, we concatenate a broadcasting message m i = P i | 1 | z i and its signature δ i = S(m i ) in Phase d1 and m i = P i | 2 | X i | d i and δ i = S(m i ) in Phase d2. Then, each party checks the validity of the signature before proceeding to the next phase. This extension can guarantee that a message is delivered without any modification. A detailed description of STAG is given in Protocol 2.
For each party P i for i = 0 to N − 1, do the following in parallel.
1) Sets partial session-identity psid d i For each party P i for i = 0 to N − 1, do the following in parallel.
1) Verifies δ i−1 of m i−1 and δ i+1 of m i+1 and proceeds only if both signatures are valid (otherwise, aborts) 2) If i = 0, party P 0 samples e 0 ← χ σ 2 and otherwise, party 1) Verifies all δ j of m j where j = N − 1 and proceeds only if both signatures are valid (otherwise, aborts) 2) Extracts d j from m j and sets psid Broadcasts rec and gets the group secret key as 1) Verifies all δ j of m j where j = i and proceeds only if both signatures are valid (otherwise, aborts) 2) Extracts d j from m j and sets psid d i gets the group secret key as sk i = H(k i ) VOLUME 8, 2020

C. DYNAMIC GKE 1) MEMBERSHIP ADDITION PROCEDURE
In DB05, membership addition can be described as a ring topology that consists of joining members and three previously agreed group members P 0 , P 1 , and P N −1 , while a new secret key of P 1 is the group secret key from the previously agreed group.
We cannot directly adopt this technique in our membership addition procedure U.Join since the group secret key sk does not belong to R q . Instead, we define another function H 1 , which outputs a value from the distribution χ σ 1 , and apply H 1 (sk) ∈ R q as a new secret key of U 1 = P 1 .
If there are M parties in the set P[N , N +1, · · · , N +M −1] who wish to join the group P[0, 1, · · · , N − 1] who already shared the group secret key sk, we can make a new ring that consists of three parties P 0 , P 1 , P N −1 from previously agreed parties P[0, 1, · · · , N − 1] and all parties from the set P[N , N + 1, · · · , N + M − 1]. P 1 chooses the previously agreed group secret key sk as ephemeral key s 1 .
After making the new ring topology, we follow the procedure of STUG to make a new shared key. A detailed description of U.Join is given in Procedure 1.
For authenticated membership addition procedure A.Join, the extended definition for partial session-identity is given as This extension is clear since the ephemeral keys s 1 and z 1 are from the group secret key sk of the previously-agreed group P [0, 1, · · · , N − 1]. Then, we achieve a common session identity sid d i Since the signature generation and verification of A.Join follow the same procedure as STAG, we omit the detailed description of A.Join.

2) MEMBERSHIP DELETION PROCEDURE
Let the set of parties P l 1 , P l 2 , · · · P l D want to leave the group P [0, 1, · · · , N − 1]. Then, the new group becomes . Instead of l i − 1 and l i + 1, l i − L and l i + R is used since there might be consecutive parties who want to leave the group P [0, 1, · · · , N − 1]. E.g., if P l , P l−1 , P l−2 , · · · , P l−(j−1) are consecutive parties who want to leave, then P l−L = P l−j .
After making a new group U , we simply relabel orders to make a new array U [0, 1, · · · , N − D − 1] of the parties in the protocol and run U.Leave procedure for U [0, 1, · · · , N − D − 1] based on the remaining parties and run STUG protocol. For authenticated version A.Leave, STAG protocol is applied instead of STUG protocol.
Our dynamic GKE protocols DRUG (Dynamic constant-Round Unauthenticated GKE) and DRAG (Dynamic constant-Round Authenticated GKE) consist of three

Phase e1[RingGen]
Rearrange the order with a new array of N = M + 3 parties

VII. SECURITY
In this chapter, we check the correctness of our protocol and give a full security proof using the security model by Bresson et al. [3]. Our proof techniques are used similarly to ADGK19 [16] and DB05 [6]. We adopt ''unpredictability-based'' security analysis (i.e., given the transcript, it is infeasible to determine the real group secret key) instead of the ''indistinguishability-based'' one (i.e., given the transcript, the real group secret key should be indistinguishable from random) to apply the characteristic of bounded Rényi divergence.
But instead of applying Katz-Yung compiler for authenticated GKE with active adversary A AKE , the security model of Bresson et al. [3] is considered to give a full security analysis of the dynamic case. Hence, our authenticated GKE protocol also achieves forward secrecy, and is almost fully symmetric and constant-round without additional rounds to achieve AKE security, compared to ADGK19.

A. CORRECTNESS PROOF
The correctness of GKE protocol is guaranteed if all parties agree on the group secret key. In Theorem 1, we give a condition that our GKE is correct. Most parts of our correctness proof follow the correctness proof of ADGK19 but there is some modification on error bound.
Note that padding the signature to the broadcasting messages does not change the size of the error and both membership addition and deletion procedures use the ring topology and the computation process is exactly the same as STUG. Hence, if we show the correctness of STUG, it is obvious that our dynamic and authenticated protocols satisfy the correctness condition.
Lemmas 2 and 3 are restated from ADGK19 [16]. Lemma 2 [16]: Given s i for all i defined in the group key exchange protocol, fix c = 2ρ π log(e) and let bound ρ be the event that for all i ∈ [N ] and all coordinate j ∈ [n], Proof: Since the complementary error function satisfies Then, there are 3nN samplings from D Z q ,σ 1 and n samplings from D Z q ,σ 2 in STUG. Under the assumption that 3nN + n ≤ exp(c 2 π/2), Lemma 3 [16]: Given bound ρ defined in Lemma 2, let product s i , e j be the event that for all v-th coordinate, Proof: Note that for l ∈ [n], (s i ) l denotes the l-th coefficient of s i and s i = n−1 l=0 (s i ) l X l . Since we take X n + 1 as modulus of R, (s i e j ) l = n−1 π ·log(e) , by Hoeffding's inequality [49], Theorem 1: For a fixed ρ, and assume that Then all participants in a group agree on the group secret key except with a probability of at most 2 −ρ+1 . Let product ALL be the event that for all terms in the form of s i · e j . Each coefficient of this form is bounded by √ nρ 3/2 σ 2 1 . Under an assumption that 2n( by Lemma 3. Denote fail by the event that at least one of parties does not agree on the group secret key. Given a condition that (N − 1)N /2 · √ nρ 3/2 σ 2 1 + (N (N + 1)/2 + N )σ 1 + (N − 2)σ 2 ≤ β Rec , by Lemma 2 and the above inequality. Therefore, all parties agree on the group secret key except with a probability 2 · 2 −ρ .
From the result of Theorem 1, the number of error terms in STUG is smaller than ADGK19. Then, the probability Pr STUG AbortKey of the event AbortKey that error between b i 's exceeds β Rec in STUG is smaller than the probability Pr Apon AbortKey in ADGK19. Thus, STUG has a higher probability to output the agreed group secret key between protocol participants and so does DRAG. Theorem 2: For unauthenticated GKE protocol STUG, , and t 2 = t + O(N · t ring ) such that t ring is the maximum time required to make operations in R q .
Proof: See Appendix A. For Theorem 3, q E and q S are the maximum number of Execute and Send queries, respectively, that an adversary for STAG may ask for.
Theorem 3: The authenticated GKE protocol STAG is secure against an active adversary under RLWE assumption, achieves forward secrecy and satisfies the following: where t ≤ t + (|P|q E + q S )t STAG when t STAG is the time required for execution of STAG by any one of the protocol participants.
Proof: See Appendix B. For Theorem 4, q E , q S , q J and q L are the maximum number of Execute, Send, Join and Leave queries that an adversary for DRAG may ask for.
Theorem 4: The dynamic authenticated GKE protocol DRAG is secure against an active adversary under RLWE assumption, achieves forward secrecy and satisfies the following: where t ≤ t + (|P|q E + q J + q L + q S )t DRAG when t DRAG is the time required for execution of DRAG by any one of the protocol participants.
Proof: See Appendix C.

VIII. COMPARISON WITH OTHER PROTOCOLS
A comparison between DRAG and other previously known lattice-based GKE protocols [15], [16], [22] is given in TABLE 1. For computational complexity, we ignore ring addition/deletion, or scalar multiplication due to its relatively smaller computing power, and only consider the following: Samp total number of Gaussian samplings R.Mult total number of ring multiplication computed Sign total number of signatures generated Verify total number of verification From TABLE 1, we define a round as the number of interactions where one party sends their message to another.
DXL12.G requires N − 1 rounds to have N approximately agreed ring elements and one round to obtain the group secret key by key reconciliation. For each party, there are N Gaussian samplings (one secret sampling and N − 1 error samplings) and N − 1 ring multiplications. YMZ15 provides the minimum communication rounds but Yang et al.'s protocol has TA which causes more security issues such as a single point of failure. Moreover, this protocol does one more computation for the secure sketch, which requires huge computing power. Neither DXL12.G and YMZ15 specify a digital signature scheme in the paper.
For ADGK19 and DRAG, both provide scalability without TA. DRAG remains three rounds to make the group secret key of authenticated GKE while ADGK19 requires four rounds to apply Katz-Yung compiler. The number of Gaussian sampling and ring multiplications are 3N + 1 and 2N + 1, respectively, for both protocols. However, DRAG expects a smaller number of signature verification since we only verify the signatures from the neighborhood.
By modifying modular exponentiation and multiplication in DB05 into ring multiplication and ring addition in RLWE setting, we design the first lattice-based dynamic group key exchange protocol in the open literature, to the best of our knowledge.

IX. IMPLEMENTATION
We instantiate and implement DRUG for two purposes: to provide the proof of concept and check the performance of our protocol. Since DRUG is a 3-round GKE protocol from RLWE assumption with a generic key reconciliation mechanism, we instantiate DRUG with one of the previous key reconciliation mechanisms whose implementation is open in public domain. We implement STUG considering the network topology and membership addition/deletion procedures based on the source code of STUG. Then, we analyze the test results from our implementation. Pseudocode of our implementation is given in Appendix D. The full reference source code is available in our GitHub address (https://github.com/hansh17/DRAGKE).

A. INSTANTIATION 1) RESTRICTIONS ON THE PARAMETERS
To instantiate DRUG, we should consider the restrictions for choosing parameters. There are three restrictions from security analysis and performance requirements.
Considering Theorems 1 and 2, we set a statistical security parameter ρ = 256 that is related to the correctness and a computational security parameter λ = 128 that ensures level 1 NIST security that is as hard as breaking AES128. λ = 128 is selected for a practical reason since λ = 256, which ensures level 5 NIST security that is as hard as breaking AES256, requires more than a day to make a precomputed table for sampling.

2) PARAMETER SELECTION
Some ring parameters, such as the dimension n and the modulus q, are highly dependent on the implementation of the basic ring operations. Generally, n can be a power of two as cyclotomic rings are used for RLWE. q can be any integers since decisional RLWE is hard over a prime cyclotomic ring with any modulus.
We chose the key reconciliation mechanism of Bos et al.'s protocol (BCNS) [28] where n = 1024, q = 2 32 −1, and σ 1 = 8/ To make broadcasting easy, we deployed an arbiter-based network for communication. Different from TA who has a dedicated role in a protocol, an arbiter is a designated party who all group members have agreed on in the initialization phase that does broadcasting, being independent of the protocol. The role of an arbiter is similar to a public bulletin board, except that the arbiter actively broadcasts the received message to the other peers while the public bulletin board is queried by the peers. Since any peer can behave as an arbiter in a fully connected network, we pick P N −1 as the arbiter for simple implementation.
In summary, the roles of an arbiter are as follows: i) participates in a protocol ii) receives public information such as z i or X i from a peer in DRUG, and broadcasts the information to the other peers iii) runs the key reconciliation mechanism and broadcasts rec to other peers (since we selected P N −1 as the arbiter).
The roles of peers (P 0 , P 1 , · · · and P N −2 ) are as follows: i) participates in a protocol ii) calculates and sends public information to the arbiter iii) calculates the group secret key from the data received from the arbiter.

C. OUR TESTS
We conducted three tests to verify correctness (Test 0) and performance (Tests 1 and 2). The test environment is as follows: Intel(R) CPU i5-8250, RAM 8GB, and OS Ubuntu v16.04.5 LTS. Since we use a virtual machine, only a partial power of the computer is used for performance evaluation. We use two processors with a 100% execution cap for CPU and 4GB for RAM. gcc v5.4.0 is used as a compiler with −O3 optimizations.

1) TEST 0: VERIFYING THE SUCCESS OF KEY EXCHANGE
In Test 0, we verified that peers can successfully exchange the group secret key using our implementation. We built two executable programs; one for the arbiter and the other for peers who are not an arbiter. These executable programs support all three modes (static, join and leave) with the −m option. An index of the peer and the number of members before and after the dynamic operations can be provided.
Our programs are configured to run on a local environment to exclude network latencies while measuring time on the subsequent tests. Each peer is deployed in one independent process, and communication between peers and the arbiter is done by sockets toward the localhost. Small modifications would allow programs to communicate through an actual network; in the actual network, the values such as the peer indices should be determined before a protocol is given as the argument. In Fig. 1, we can observe that a group of four outputs the same value as the agreed group secret key. Figs. 2 and 3 demonstrate that the U.Join and U.Leave procedures were done without errors.

2) TEST 1: PERFORMANCE CHECK ON COMPONENTS
In Test 1, we checked the runtime and cycles of each operation and function of our implementation. TABLE 3 shows the performance of each operation on average after running 200 times.    As we can see in TABLE 3, random sampling from χ σ 2 takes a longer time than random sampling from χ σ 1 . This is a result of the difference in size of σ 1 = 8/ √ 2π and σ 2 = 14, 198, 340/ √ 2π . The ring polynomial addition running time is almost 0, but the ring polynomial multiplication running time is 185 µsec. Therefore ring polynomial multiplication and random sampling is an important factor in performance as we stated in Chapter VIII. TABLE 4 shows the performance of each function. We measure the computational time for z i , X i , reconcile, and the group secret key. As we can see in TABLE 4, computing X 0 takes longer than computing X i due to the sampling from χ σ 2 . Even though only one peer, P 0 , samples values from χ σ 2 , its runtime is much longer than random samplings from χ σ 1 or ring polynomial multiplications. Hence, random sampling from χ σ 2 is another important factor in measuring the performance of DRUG.
To claim that the performance of DRUG is reasonable compared to other previous key exchange protocols, we compare our protocol with the previously standardized two-party key exchange protocols like Diffie-Hellman key  exchange (DH), MQV [50], and their elliptic curve variants (ECDH, ECMQV). For the sake of simplicty, we limit the comparison with the Crypto++ library [51]. Given the 128-bit security level, key size should be 3072 bit for DH and MQV and 283 bit for elliptic curve variants. The runtime of our protocol takes around 3 msec which is comparable to the runtime of Diffie-Hellman-like key exchange protocols, which takes around 2 to 3 msec. Our protocol is faster than elliptic curve variants whose runtime requires around 6 to 8 msec. We increase the security without losing efficiency by adopting RLWE setting since most of current key exchange protocols can be totally broken by quantum adversaries.

3) TEST 2: PERFORMANCE CHECK ON DYNAMIC OPERATIONS
In Test 2, we checked the total runtime of U.Join and U.Leave procedures. The measurement was performed when the number of group members changes from four to five and five to four. The whole procedure of GKE is measured, i.e., the protocol ends when all peers calculate a group secret key. Since the calculation in each phase is performed in parallel, we add the longest time for calculation in each phase.
In TABLE 5, U.Join procedure takes 3,168 µsec and U.Leave procedure takes 2,956 µsec, which is reasonable for practical use.

X. CONCLUSION AND FUTURE WORK
In this paper, we deal with the novel construction of quantum-resistant constant-round dynamic authenticated GKE protocol. Former dynamic GKE protocols rely on number-theoretic problems such as Diffie-Hellman problem which is vulnerable to quantum computing attacks. To make a quantum-resistant dynamic GKE protocol, underlying number-theoretic problems should be replaced by other quantum-resistant ones like RLWE problem.
The main contributions of this paper are as follows: • We designed a novel constant-round dynamic authenticated GKE protocol from RLWE with quantum resistance.
• DRAG is theoretically more efficient than the previous constant-round authenticated GKE protocol from RLWE in regard to the computational complexities and communication round.
• We provided implementation details with pseudocode, as a proof of concept, to meet level 1 NIST security (128-bit AES security) in Ubuntu v16.04.5 LTS.
After checking the distinctive features between BD94 and DB05 in a static unauthenticated setting, we found that they differ only in key computation phase, Also, DB05 supports a group to agree on the group secret key with a dynamic setting. Similarly, we designed yet another quantum-resistant constant-round GKE protocol in a static setting by modifying the key computation phase of ADGK19. Then, a novel construction of a quantum-resistant constantround dynamic authenticated GKE protocol is proposed in a dynamic setting with the quantum-resistant digital signature with the existential unforgeability under chosen message attack. For membership addition/deletion procedures, our protocol is built from RLWE setting, while the former ones are from Diffie-Hellman problem.
We consider the adversary model by Bresson et al. [3] that covers a dynamic authenticated GKE protocol with a weak corruption model and suggested a rigorous security proof in the random oracle model. Compared to ADGK19, our dynamic authenticated GKE protocol, DRAG, requires fewer computational complexities and a smaller communication round for authenticated GKE.
Our implementation is claimed to be practical with suitable parameter selection since the total runtime to get the group secret key takes about 3 msec. This result can be considered as a reference implementation of other quantum-resistant GKE protocols.
As future work, the vulnerability of DRAG to key reuse attacks [52]- [54] is required to be addressed. Another challenge is to reduce the size of q for better performance. .

APPENDIX A PROOF OF THEOREM 2
Proof: Let A be an adversary that breaks the STUG protocol. From this, we construct an adversary B that solves RLWE problem with a non-negligible advantage. Since we do not have any long-term secret key in STUG, Corrupt can be ignored and the protocol achieves the forward secrecy.
Let Query be the event that k N −1 is among the adversary A's random oracle queries and Pr i Query be the probability of Query in Experiment i.
Then, by a sequence of experiments, we show that an efficient adversary who queries the random oracle in Ideal experiment can query the random oracle in Exp 0 experiment. For Ideal experiment, the input k N −1 is chosen at uniformly random while k N −1 is chosen by the honest execution of STUG in Exp 0 and Exp 1 experiments.
Experiment 0: This is the original experiment that is equal to the procedure of STUG.
: (T, sk) The rest are the same as the previous experiment.
: (T, sk) using the property of Rényi divergence. VOLUME 8, 2020 Proof: Let X 0 , X 0 be the random variables in experiments Exp 0 and Exp 1 , respectively. Error and main can be defined as respectively. Then, X 0 = main + Error + e 0 and X 0 = main + e 0 where e 0 ← σ 2 . We check whether Rényi divergence between two distributions of X 0 and X 0 is small using Lemma 1. Let bound Error be the event that for all participants j, Error j ≤ β Rényi . Then, π log e and let bound be the event that (e 0 ) j ≤ cσ 2 , (s i ) j , (e i ) j , (e N −1 ) j ≤ cσ 1 , and (e i ) j ≤ cσ 1 for all i > 0 and j.

Experiment 2:
Replace z 0 with the uniform element in R q . The rest are the same as the previous experiment.

Experiment 3:
Replace z 0 into z 2 − r 1 and X 1 into r 1 s 1 + e 1 where r 1 ← R q . The rest are the same as the 94622 VOLUME 8, 2020 previous experiment.
: (T, sk) s i , e i ← χ σ 1 and z i = as i + e i for 1 ≤ i ≤ N − 1; Since both z 0 and z 2 − r 1 are uniform, Pr 3 Query = Pr 2 Query . Experiment 4: Replace z 1 , X 1 with the uniform element in R q . The rest are the same as the previous experiment.
: (T, sk) s i , e i ← χ σ 1 and z i = as i + e i for 2 ≤ i ≤ N − 1; Between Experiment 3 and Experiment 4, two RLWE instances are replaced by two independent random values. Hence, Pr 4 Query − Pr 3 Query ≤ Adv RLWE n,q,χ σ 1 ,2 (t 1 ) where t 1 is the time to solve RLWE problem which is the sum of t and some minor overhead O(t ring ) for simulation. Experiment 5: Replace z 0 into the uniform element in R q . The rest are the same as the previous experiment.
Since both z 0 and z 2 − r 1 are uniform, Similarly, we can design the distribution of (T, sk) in Experiment 3j, 3j + 1, 3j + 2 as below: Experiment 3j: Replace z j−1 with z j+1 − r i and X i into r j s j + e i where r j ← R q . The rest are the same as the previous experiment.
Experiment 3j+1: Replace z j , X j with the uniform element in R q . The rest are the same as the previous experiment.
The rest are the same as the previous experiment.
The rest are the same as the previous experiment.
Between Experiment 3N − 1 and Experiment 3N , k N −1 from recMsg(b N −1 ) are replaced into random. Hence, where t 2 is the time to break KeyRec which is the sum of t and some minor overhead O(t ring ) for simulation.
Since an adversary attacking STUG makes at most q E queries to the random oracle, Pr 1 Query = q E 2 λ , which is negligible in λ.
With the Lemma 4 and Adv KE STUG (t, q E ) ≤ Pr 0 Query , we derive the result of the theorem.

APPENDIX B PROOF OF THEOREM 3
Proof: From an adversary A that attacks STAG, we construct an adversary A that attacks STUG. We divide the event Succ that A wins the security game defined in Chapter IV into the one that A can forge a signature and the one that A cannot forge a signature.
For the former case, we claim that the probability of event Forge that the adversary can forge a signature is bounded by |P|Adv DSig (t ) where |P| is the number of participants.
Suppose event Forge occurs. Then, A makes a query of the type Send (V , i, m) where m is either of the form m = P i | 1 | z i or of the form m = P i | 2 | X i | d i with V(pk P i , m, δ m ) = 1 where δ m is not output by any instance of P i on the message m.
We construct an algorithm F that forges a signature for a signature scheme DSig using A . Given a public key pk, F chooses a random party P ∈ P and sets pk P = pk. The other public/secret keys are honestly generated. Then, F simulates all queries of A and obtains the proper signatures with respect to pk P from its signing oracle. If A outputs a valid message/signature pair with respect to pk P = pk for any party P ∈ P, F outputs this pair as a forgery. The success probability of F is equal to Pr[Forge] |P| and hence, For the latter case, we claim that A can simulate oracle queries of A by its own oracles. Suppose A makes an Execute query with an instance {(P 0 , i 0 ), · · · , (P k , i k )}. Then, A defines a set of instances S = {(P 0 , i 0 ), · · · , (P k , i k )} and sends S to Execute oracle to obtain a transcript T of STUG. Then, (S, T ) are added to the set tlist which stores session identity/transcript pairs. A outputs a transcript T of STAG by expanding T and returns T to A .
For Send query in A , we have two types of Send queries since for each instance (P 0 , i 0 ), there is a first send query Send 0 to start a new session and the other send queries with a message/signature pair. With an instance {(P 0 , i 0 ), · · · , (P k , i k )}, Send 0 (P j , i j {P 0 , · · · , (P k )} \ P j ) for each 0 ≤ j ≤ k. A defines S = {(P 0 , i 0 ), · · · , (P k , i k )} and sends S to Execute oracle to obtain a transcript T of STUG. Then, (S, T ) is added to tlist. For other send queries, A verifies the query according to Protocol 2. If the verifications fail, A aborts an instance (P j , i j ). Otherwise, A finds (S, T ) from tlist such that (P j , i j ) ∈ S and from T , it finds the appropriate message with respect to (P j , i j ) in A and returns the public information to A .
For Reveal and Test queries in A , if a session is terminated properly with an instance (P j , i j ), T is well defined. Then, A finds (S, T ) where (P j , i j ) ∈ S and runs Reveal and Test queries for a transcript T . Then, the result is sent to A .
If Forge occurs, the success probability becomes 1 2 since A aborts the instance and outputs a random value. for j = 0 to N − 1 do 6: tmp ← tmp + tmp2 7:

Adv
Y mod(2+j,N ) ← tmp 8: tmp2 ← X mod(3+j,N ) 9: end for 10: result ← 0 11: for j = 0 to N − 1 do 12: tmp ← Y j 13: result ← result + tmp 14: end for 15: return H(recKey(result, rec)) 16: end function Then, A makes Execute queries for each Execute and Send 0 queries in A . Since a session has at least two instances, the number of Execute queries in A is at most q E + q S 2 . Thus,

APPENDIX C PROOF OF THEOREM 4
Proof: Similar to Theorem 3, we separate the event Succ that adversary A wins into two cases: one with forging a signature and the other without forging. Then, we design how to answer Execute, Join, Leave and Send queries from DRAG using Execute queries from STUG.
From an adversary A which attacks DRAG, we construct an adversary A who attacks STUG.

Pseudocode 6
Arbiter for STUG and U.Leave 1: procedure Arbiter_leave_or_static(N 2 , N 1 ) 2: N 2 peers after leave, N 1 peers before leave 3: N 1 is not used in this procedure. 4: establish connections with peers 5: assign an index i of each peer 6: k ← N 2 7: s k−1 , z k−1 ← calc_pk (s) 8: step ← 0 9: while step < 4 do 10: for i = 0 to N 2 − 2 do 11: receive index of peer i 12: if rec is not calculated and X is available then 13: sk end if 32: save that the step is completed with peer i 33: if the step is completed with all peers then 34: step ← step + 1 35: end if 36: end for 37: end while 38: print sk N 2 −1 39: end procedure For the former case, the proof is the same as Theorem 3 and we obtain that Pr[Forge] ≤ |P|Adv DSig (t ).
For the latter case, we claim that A can simulate all oracle queries of A by its own oracles. Execute query in A can be returned as the same procedure of the proof of Theorem 3.
For Send query in A , we have two special types of Send queries as the join send query Send J and the leave send query Send L to initiate Join and Leave queries in A .
We define three lists Tlist, Jlist and Llist to store the result from Execute, Join and Leave queries as a set.
If a set S J = {(P k+1 , i k+1 ), · · · , (P k+l , i k+l )} of unused instances wants to join the group S = {(P 0 , i 0 ), · · · , (P k , i k )}, A sends Send J (P j , i j , {P 0 , · · · , (P k )}) for each k + 1 ≤ j ≤ Pseudocode 7 Peer for STUG and U.Leave 1: procedure Peer_leave_or_static(N 2 , N 1 ) 2: N 2 peers after leave, N 1 peers before leave 3: N 1 is not used in this procedure. 4: establish connection to the arbiter 5: k ← N 2 6: while step < 4 do 7: send index of peer i 8: receive step 9: if step = 0 then 10: s i , z i ← calc_public_key(a) 11: send the public key z i end if 22: end while 23: print sk i 24: end procedure k + l to initiate Join(S, S J ) query. A finds whether S is in Tlist with (S, T ), Jlist with (S , S , T ) where S = S ∪ S or Llist with (S , S , T ) where S = S \ S . If nothing is found, A runs Execute oracle to get a transcript T and store (S, T ) into Tlist. When transcript T is found, A runs Reveal oracle to obtain sk and simulates a membership addition procedure A.Join to obtain a transcript T . Then, (S, S J , T ) is added to Jlist.
Similarly, when a set S L of unused instances wants to leave the group S = {(P 0 , i 0 ), · · · , (P k , i k )}, A sends Send L for each party in S L to initiate Leave(S, S L ) query. Then, (S, S L , T ) is added to Llist.
For Join(S, S J ) and Leave(S, S L ) queries in A , A finds (S, S J , T ) in Jlist and (S, S J , T ) in Llist for a transcript T , respectively. Then, the result is sent to A .
Both Reveal and Test queries in A can be returned with the same procedure in the proof of Theorem 3.
If Forge occurs, the success probability becomes 1 2 since A aborts the instance and outputs a random value. Then, Then, A makes Execute queries for each Execute, Send J , Send L , and Send 0 query in A . A session has at least two instances, and the number of Execute queries for non-special Send queries is at most q S − q J − q L 2 . Hence, the number of VOLUME 8, 2020 Pseudocode 8 Arbiter for U.Join 1: procedure arbiter_join(N 2 , N 1 ) 2: N 2 peers after join, N 1 peers before join 3: Establish connections with peers 4: index ← the array of indices of peers 5: for i = 2 to N 1 − 2 do The 3 peers performing join 6: index[i] ← −1 7: end for 8: k ← N 2 − N 1 + 3 9: s k−1 , z k−1 ← calc_pk (s) 10: step ← 0 11: while step < 4 do 12: for i = 0 to N 2 − 2 do 13: receive index of peer i 14: if rec is not calculated and X is available then 15: sk end if 45: end if 46: save that the step is completed with peer i 47: if the current step is completed with all peers then 48: step ← step + 1 49: end if 50: end for 51: end while 52: print sk N 2 −1 53: end procedure Pseudocode 9 Peer for U.Join 1: procedure peer_join(N 2 , N 1 ) 2: N 2 peers after join, N 1 peers before join 3: establish connection to the arbiter 4: j ← received index[i] on the arbiter side 5: k ← N 2 − N 1 + 3 6: while step < 4 do 7: send index of peer i 8: receive step 9: if step = 0 then 10: if 2 <= i <= N 1 − 2 then 11: continue Existing peers do nothing 12: end if 13: s j , z j ← calc_public_key(a) 14: send the public key z j 15: if i = 1 then 16: send the secret key s  33: sk i ← calc_session_key(j, k, s j , rec) 34: end if 35: end if 36: end while 37: print sk i 38: end procedure Execute queries in A is at most q E + q S + q J + q L 2 . Thus, Adv AKE DRAG (t, q E , q J , q L , q S ) ≤ Adv KE STUG (t , q E + q J + q L + q S 2 ) + |P|Adv DSig (t ).

APPENDIX D PSEUDOCODE OF THE IMPLEMENTATION
See Pseudocode 1-9.