Centralized and Decentralized Group Key Management
Dept. of Computer Science
University of South Carolina
Columbia, SC 29208
Dept. of Computer Science
University of South Carolina
Columbia, SC 29208
Manton M. Matthews
Dept. of Computer Science
University of South Carolina
Columbia, SC 29208
Group communication has been widely deployed. To trans-
mit data securely in a dynamic group we need have a secure
and efficient group key management protocol. In this paper
we first give an overview of centralized and decentralized
group key management protocols, after that we proposed
our own protocols: Fast Chinese Remaindering Group Key
Protocol (FCRGK) and Hierarchical Chinese Remaindering
Group Key Protocol (HCRGK). The FCRGK protocol is de-
signed for moderate size group key management while the
HCRGK protocol is designed for large groups. Both of our
protocols have minimal group user side computation and
storage requirement with a reasonable increase of computa-
tion on the server (and group controllers for HCRGK).
Categories and Subject Descriptors
C.2.2 [Computer-Communication Networks]: Network
Protocols; K.6.5 [Management of Computing and In-
formation Systems]: Security and Protection
Design, Management, Performance, Security
Chinese Remainder Theorem (CRT), Congruence System,
Group Key Management(GKM), Pairwise Relative Prime
Group-oriented applications have been widely used in the
different areas of communication, such as secure conferenc-
ing, TV pay per viewing, controlled satellite service access-
ing, and so on. All those applications need to enforce data
confidentiality for group communication, which requires data
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Computer Security Conference 2007 , April 11-13, 2007,
Myrtle Beach, SC, USA. Copyright 2007 CSC 2007 .
encryption. While the technical issues of applying crypto-
graphic algorithm to secure unicast communication are fairly
well understood, the scenario for group communication in-
volving dynamically changing members is very different. In
the setting of group communication, every time a current
member is evicted from a group or a new member is added
to a group the group key must be changed. The members of
the group must also be able to receive and/or compute the
new group key efficiently, while arbitrary collusions of previ-
ous members must not be able to obtain it within tractable
During the past decade a variety of group key manage-
ment protocols have been proposed. Those protocols aim at
tackling different scenario of group key management prob-
lem, such as with or without a key server, with or without a
hierarchical structure, large or small groups, and so on. The
structures and the algorithmic foundations of those proto-
cols, hence, are very different for different categories of them.
In this paper, we will firstly provide a high level descrip-
tion of the related work in three large categories; then we
will describe our protocols for two of the three categories;
after that we will present an overall comparison of some of
the representative protocols.
In the next section we will outline briefly some of the re-
lated work. In section 3 we will describe the basic group
operations and some of the necessary preliminaries for our
protocols. We will present the centralized and decentralized
group key management protocols in section 4 and 5, respec-
tively. In section 6 we will provide a detailed comparison
of some of the representative protocols. We will summarize
our paper in section 7.
2. RELATED WORK
Since early 1990s, following the fast development of In-
ternet, many researches have been done concerning secure
group communication, and a number of group key manage-
ment solutions have been proposed.
group key management protocols can be largely classified
into three categories , , , :
• Centralized Group Key Management Protocols: one
single center is engaged in managing the entire group;
• Decentralized Group Key Management Protocols: the
management of a large group is divided among hierar-
chically structured managers, in an attempt to mini-
mize the problem of concentrating the work in a single
• Distributed Group Key Management Protocols: there
is no explicit key distribution center, and each group
member can contribute to the key generation and dis-
In the following subsections we will summarize current group
key management procotols proposed by other authors.
2.1Centralized Group Key Management
The class of centralized group key management protocols
is the most widely explored group key protocols among the
three. Harney and Muckenhirn ,  proposed a group
key management protocol by extending two-party shared key
establishing scheme into the group case. It requires O(n)
encryptions to update a group key when a user is evicted or
added if backward and forward secrecy are required.
A set of scalable hierarchical structure based group key
protocols , , , ,  have been proposed. In
general for a group with n users those protocols require the
key server to store about 2n keys and update O(logn) keys
each time re-keying is needed, and each user stores O(logn)
keys (or secret information) and performs O(logn) decryp-
tions or some type of computation per group key update.
Eltoweissy et al.  proposed a protocol based on Ex-
clusion Basis Systems, a combinatorial formulation of the
group key management problem, which allows protocol user
to trade-off between the number of keys needed to be stored
and the number of messages needed to be transmitted for
each key update with no counter collusion solution provided.
Fiat and Naor  take the information theoretic approach
and propose k−resistant protocol, i.e. coalitions of up to k
users are secure, with each user storing O(k logk logn) keys
and the server broadcasting O(k2log2k logn) messages per
Chiou et al.  proposed a secure broadcasting protocol,
which is also based on CRT, however its application of CRT
is different from our protocols. Their protocol is directly
coupled with data communication hence it requires O(n)
encryptions for each real data broadcast while our protocol
is a group key management protocol hence after key update
each real data broadcast only needs 1 encryption.
2.2Decentralized Group Key Management
Ballardie  proposed a multicast key distribution proto-
col, which can be classified as decentralized protocol. This
protocol requires certain support mechanism to be integrated
into version 3 of IGMP and it provides no forward secrecy.
Mittra  proposed another typical decentralized proto-
col: Iolus. This protocol decentralizes the group control to
each subgroup controller (Group Security Agent). Since it
lacks a general group key, the real multicast data need to
be relayed (decrypted and re-encrypted) by each subgroup
controller which impedes the performance of real data mul-
2.3 Distributed Group Key Management
Steiner et al. , Kim et al.  proposed distributed
group key protocols based on Group Diffie Hellman methods
for small dynamic peer groups. Rodeh et al.  proposed
a distributed logical key hierarchy protocol using AVL trees.
Those protocols require many rounds of messages to update
a new group key. Their contributory nature may only attract
applications involving small group of peer users. In this pa-
per we mainly focus on centralized and decentralized group
key management protocols hence we will skip the details of
distributed group key management protocols.
Each group key management protocol should have a set
of basic group operations. All the group operations work
together to reach the goal of maintaining the secrecy of each
group key. In other words, each group key should be known
to and only be known to a set of legitimate group users,
therefore the group key needs to be updated when group
membership changes. The following set of group operations
describes the common set of functionalities:
• Group Initialization: this operation is used to set up
the group when the group just starts.
• User Addition: this operation is used to update the
group when a new user is added to the group.
• User Eviction: this operation is used to update the
group when a current user is removed from the group.
• Mass Addition: this operation is used to update the
group when a set of new users are added to the group
at one time.
• Mass Eviction: this operation is used to update the
group when a set of current users are removed from
the group at one time.
There are some additional group operations, which are only
used in our protocols, that will be introduced later.
Specifically for our group key management protocols, since
they are based on the Chinese Remaider Theorem we will
briefly describe it in Fig. 1. For details and the proof of
Chinese Remaider Theorem please refer to , , .
As described in Fig. 1, Miis relatively prime to mi, there-
fore there must exist a unique multiplicative inverse modulo
mi. Then the computation of the unique solution X is well
defined. Efficient computation of the multiplicative inverse
can be carried out using Extended Euclidean Algorithm ,
In this paper our protocols are dealing with group key
management for dynamic group, and certain authentication
protocol involving two parties is assumed and will be ex-
ecuted before the key server grants group access to each
user. Since two-party authentication protocols are well stud-
ied , it is not included in the scope of this paper.
Since our group key management protocols are based on
Chinese Remainder Theorem, it means that we always need
to have a set of primes or PRPPIs to set up the congru-
ence system. Since primality test and relative primitivity
checking are well understood , , , and can be car-
ried out during protocol preparation stage, it is not included
in our protocols. For each of our protocols we assume that
the server(s) has an unlimited pool of PRPPIs. In practice,
Chinese Remainder Theorem: Suppose m1,...,mn
are pairwise relatively prime positive integers, and sup-
pose r1,...,rn are arbitrary integers. Then the system
of n congruences
X ≡ r1 (mod m1)
X ≡ r2 (mod m2)
X ≡ rn (mod mn)
has a unique solution modulo M = m1∗...∗mn, which
is given by
riMiyi mod M,
Mi = M/mi and yi = Mi−1mod mi, for 1 ≤ i ≤ n.
Figure 1: Chinese Remainder Theorem
when the pool of PRPPIs is gradually used up, it can always
generate more of PRPPIs.
In our protocols the server(s) is fully trusted, which means
that the server(s) is capable of and will be keeping the se-
cret information secret. However, the group controllers and
group users are only partially trusted, which means that they
are only maintaining the corresponding secrets when they
are playing their corresponding roles in the group. Our pro-
tocols are still secure when the group controllers and group
users leave their roles and expose the corresponding secrets.
4. CENTRALIZED GKM
In this section we will firstly discuss a set of well-known
centralized group key management protocols, with their com-
mon properties outlined; then we will present our Fast Chi-
nese Remaindering Group Key Protocol, which also belongs
to the category of centralized group key management proto-
4.1 Hierarchical Tree Based Centralized
Group Key Protocols (HTBCGK)
, , , ,  have proposed a set of hierarchical
tree based centralized group key management protocols. In
those articles the group key management center (key server)
will build a logical key tree structure.
logical key tree structure for a group with eight group users
is depicted in Fig. 2.
Based on this logical key tree structure the key server
manages the group this way: when a new user is added to (or
a current user is evicted from) the group, then the key along
the path from that user to the root will be updated; and the
key at the root node of the tree is used as the group key
for group communication encryption and decryption. Let’s
take u4as an example, if u4is newly added (or evicted), then
k4, k34, k14, and k will be updated. While different articles
proposed different methods of updating the keys along the
path to the root, such as encryption and decryption, one
way function, pseudo random function together with brutal
An example of a
Figure 2: An example of logical key tree structure
force, and so on, in general this set of group key management
protocol will require the key server and the group users to
do about O(logn) number of some type of computations to
update the group key for a group with n users.
4.2 Fast Chinese Remaindering Group Key
In this subsection, we present our FCRGK protocol which
is designed based on the Chinese Remainder Theorem. In
the FCRGK protocol we emphasize on alleviating the com-
putation and storage requirement from the user side with a
reasonable increase of the load on the server side. Especially,
with the FCRGK protocol the key server can do most of the
computation long before user is added or evicted, so that
when a user addition or user eviction occurs the key updat-
ing message can be sent out by the key server quickly with
very little computation and latency. To gain this perfor-
mance improvement on most of the user addition or eviction
events the key server needs to perform an additional group
expansion operation when the total number of group mem-
ber changes reaches certain number. The group expansion
operation is expensive in the sense that it is about the same
scale of a group initialization, but it is designed to be carried
out very infrequently. Also, the key server needs more stor-
age space to save intermediate results to carry out the pre-
emptive computation for key updating. In Fig. 3 we show a
virtual structure of our FCRGK protocol to help us describe
the protocol. In the Figure all the ks’s are picked from the
server’s PRPPI pool and as it shows a subset of those ks’s
are assigned to the corresponding users and the rest of them
are reserved for future users. The following subsections are
detailed descriptions of the FCRGK protocol.
After the initial set of group users are authorized to join
the group communication, each group user will be assigned
a symmetric secret key (ks), then the server establishes the
following congruence system:
Figure 3: The General Structure of the FCRGK Protocol
X ≡ r1 (mod ks1)
X ≡ r2 (mod ks2)
X ≡ rv (mod ksv)
X ≡ rv+1 (mod ksv+1)
X ≡ rw (mod ksw)
ri = SubBits(k ⊕ ksi), for 1 ≤ i ≤ v;
ri’s , for v + 1 ≤ i ≤ w, are randomly picked values (?= k)
The intermediate results in the previous computation are
saved into a temp array t as:
t = M1∗ y1 (mod M)
t = M2∗ y2 (mod M)
t[w] = Mw∗ yw (mod M)
t[w + 2] = t[w + 3] = 0
t[w + 1] =
riMiyi mod M
M = ks1∗ ks2∗ ... ∗ ksw
Mi = M/ksi, for 1 ≤ i ≤ w
yi = M−1
mod ksi, for 1 ≤ i ≤ w.
t[w + 2] is reserved to save values related to users evicted
t[w + 3] is reserved to save intermediate result for key
After the server computes the X value in the conguence sys-
tem, it is broadcast to all the current group users. Each
group user ui received the X value and computes the group
key k as:
k = SubBits((X mod ksi) ⊕ ksi)
Then, each user of the group now agrees on the same key k.
After the key server establish the first group key, when-
ever it have leisure computation power it can start to do the
precomputation for the next group key. To prepare for the
next group re-keying the server updates the previous con-
gruence system and use the previous intermediate results to
compute the partial result of X and save it in t[w + 3]:
X ≡ r1 (mod ks1)
X ≡ r2 (mod ks2)
X ≡ rv (mod ksv)
X ≡ rv+1 (mod ksv+1)
X ≡ rw (mod ksw)
ri = SubBits(knew⊕ ksi), for all ui ∈ U;
ri’s , for v + 1 ≤ i ≤ w, are random values (?= k) picked
ri’s , for 1 ≤ i ≤ v with ui / ∈ U, are equal to 1;
and compute the partial result of X as:
t[w + 3] =
t[i]ri mod M
With all those intermediate results saved, the server are now
ready for next group re-keying request no matter whether it
is because user addition or user eviction.
With key precomputation user addition in FCRGK is very
simple. When a new user is added to the current group, ksv
is assigned to the new user as its symmetric secret key and
the following is the computation of the new X value:
t[w + 1] = (t[w + 1] − rv∗ t[v]) mod M
rv = SubBits(knew⊕ ksv)
X = t[w + 3] + rvt[v] + t[w + 1] + t[w + 2] (mod M)
the first rv is still the previously randomly picked value;
Then, the new X is broadcast and the new group key is
computed the same way as before.
User eviction is also very simple in FCRGK. Assuming ue
is the newly evicted user then the following computation can
get the new X value:
t[w + 2] = (t[w + 2] + t[e]) mod M
X = t[w + 3] − ret[e] + t[w + 1] + t[w + 2] (mod M)
And again, the new X is broadcast and the new group key
is computed in the same way.
After group initialization since the foundation of the con-
gruence system is kept the same, the original symmetric se-
cret reserve ksv+1,...,ksw (as in Fig. 3) will gradually be
used up after many group user additions. Group expansion
operation will refresh and possibly expand the current con-
gruence system. A group expansion operation is carried out
each time when the value (w − v)/n reaches a predefined
threshold value λ. The value of λ should be determined by
group dynamics and the key server computing power. In
other words, based on the current group dynamics the time
duration needed for the key server to do a group expansion
computation is the key factor of determining the threshold
value. The longer the time is needed, the bigger the thresh-
old value should be. This way group expansion operations
can be carried out in the background so that the key man-
agement based on the current congruence system won’t be
The duty of group expansion includes kicking out all the
symmetric secret key values which have been used by group
members that have left the group, and possibly expanding
the symmetric secret reserve to make up the new size w
of the congruence system, then compute and save all the
intermediate results as in group initialization.
Mass addition and mass eviction operations are very sim-
ilar to single user addition and eviction in our protocol. The
basic steps are: a set of users are removed from (or added to)
the congruence system; the server updates the intermediate
results and computes the new X value; the users receive the
X values and compute new group key.
Mass Addition and Mass Eviction
5. DECENTRALIZED GKM
In this section we will firstly discuss the representative
decetralized group key management protocol; then we will
present our Hierarchical Chinese Remaindering Group Key
Protocol, which we classified as one of the decentralized
group key managment protocols.
Mittra proposed a group management framework , named
Iolus, which manages a large group by spliting it into sub-
groups and each of them is managed by an agent, called
Group Security Agent (GSA). GSAs have two types: the
Group Security Controller (GSC), which manages the top
level subgroup; and the Group Security Intermediaries (GSIs),
which each manages a subgroup. Fig. 4 is an example struc-
ture of Iolus.
The Iolus framework has decentralized the group manage-
ment into a set of subgroup managers, the GSAs. However,
the entire group managed by the Iolus framework lacks of
Figure 4: An example structure of Iolus
a common group key, hence the GSAs serve as relay cen-
ters. When a message is sent from one subgroup to another,
there is always some level of decryption and re-encryption
5.2 Hierarchical Chinese Remaindering
Group Key Protocol (HCRGK)
Our first protocol in this paper, the FCRGK protocol,
as a single level group key management protocol, has much
more advantage over group users’ side. It is expected to suit
well for moderate size group key management. However, the
FCRGK protocol is still only a linearly structured protocol,
which means the computations needed to be done at the
server side is still linear to the group size. Therefore, our
FCRGK protocol is not suitable for very large group key
In this section, we will describe a hierarchically structured
group key management protocol, which is suitable for very
large group key management. To construct a hierarchical
structure we need to bring in a special set of users to play
the role of group controller. To get that, a subset of those
legitimate group users, who are willing to act as a group con-
troller, have more computational power, and expect to stay
a long duration in the group, will be singled out as the set of
potential group controllers. A subset of the potential group
controller set will be picked as the current group controllers.
The rest of the potential group controllers will be reserved
for the future. The number of current group controller is de-
termined by the initial group size and the group controller’s
Each authorized group user and group controller will re-
ceive two integers (ks and ksb), respectively, from the server’s
PRPPI pool through some secure channel.
group controller will receive an additional set of integers
from the server’s PRPPI pool. A particular subset of the
above set has already been assigned as the symmetric keys
(ks’s) for a subset of the group users and the rest of the inte-
gers are reserved for future new joining group users. All the
integers from the PRPPI pool are indexed with a subscript,
as well as all the group users and group controllers. Each
group user or group controller and its ks and ksb are hav-
ing the same subscript, which is unique within the current
entire group. The reason for them to be subscripted is that
the server and the group controllers can agree on which sub-
script corresponding to which user and secret key for future
To illustrate the hierarchical structure of our HCRGK pro-
Figure 5: Hierarchical group structure with one level of Group Controllers
tocol we depicted a generalized group structure containing
one level of group controllers (Fig. 5). In the figure the
subscripts of the nodes can in any other order. The server
records who belong to which subgroup, while the subscripts
are assigned based on the arrival time of the users hence
they are not related to which group the users belong.
Since in our HCRGK protocol each subgroup in the hier-
archical structure is managed using the method very similar
to our FCRGK protocol, we will only describe the top level
management for HCRGK. Practically our HCRGK protocl
can have many levels of group controller structure. However,
to simplify our description we will illustrate the HCRGK al-
gorithm by initializing the hierarchical structure with one
level of group controllers as in Fig. 5.
After the server set up the initial hierarchical structure, it
establishes a congruence system for its direct subgroup (the
group of group controllers), then computes the X value of
the initial group key k and broadcasts it to all the group
controllers. Each group controller establishes a congruence
system based on the set of ks’s received from the server, then
computes a new X value based on the k computed from the
X value sent by the server and broadcasts the new X value
to all the users in its subgroup. Each users received the X
value and computes the group key k like in FCRGK.
After the initial group has been set up, if a new user needs
to be added to the group then it will first go through the
similar authentication process as other group users do. The
server will find a subgroup with more open slots and pick one
of the reserved PRPPIs from this subgroup (serve as ks for
the new user), and pick another PRPPI from its own pool
(serve as ksb for the new user). The corresponding group
controller will then be notified of the addition of the new user
and the ks value of the new user. The group controller will
then update the corresponding variables of the congruence
system in charging.
Now, the new group key can be established just like what
we did in group initialization. The server randomly picks a
new group key, computes the new X value, and broadcasts
it to all its children. All the group controllers will distribute
the new group key to all their children in the same procedure
as in subsection 5.2.1.
Obviously, in the case of user addition there is one other
way we can do. That is, the server encrypts the new group
key using the old group key and sends it to all the old group
users, and encrypts the new group key using the new user’s
symmetric key and sends it to the new user. However, there
is tradeoff here. If we distribute the new group key using
the congruence system then each group user will only do
one modulo and one XOR operation to get the new group
key, while the other way will save computation on the server
and group controllers but each end user will do a decryption
to get the new key. One modulo and one XOR together
is faster than a decryption. On the other hand no matter
which way we choose to distribute the new group key for
user addition we will add the new user into the hierarchical
group structure like what we did, because it will make user
eviction very easy to handle.
In our protocol group re-keying in the user eviction case
has much more advantage over other protocols, because most
of the times group re-keying after user eviction is very sim-
ilar to user addition case in our design. After a user was
evicted from the group, the key server will notify the cor-
responding group controller. The evicted user’s ks and ksb
will be marked as revealed values. However ks is still kept in
the congruence system managed by the evicted user’s parent
The reason for keeping an evicted user’s ks in the congru-
ence system is that it saves a lot computation for the corre-
sponding group controller. As long as the congruence system
base are the same then the previous intermediate results for
computing the X value can be reused, especially the group
controller doesn’t need to compute the multiplicative inverse
for each Mi again. With the congruence system maintained
as the same, re-key after user eviction will be very similar to
re-key after user addition. The key server picks a new group
key, computes the X value, and broadcasts it. Each group
controller receives the X value from the key server, extracts
the new group key, computes the X value for its congruence
system, and distributes the X value. The group users can
extract the new group key from the received X value with
one modulo and one XOR operation.
For each subgroup in our protocol, after a number of user
additions and user evictions, the reserved PRPPIs for the
congruence system will gradually be used up. At such time
the group controller can contact the server to get a new set
of integers from the server’s PRPPI pool to replace the ks’s
of evicted users in the subgroup.
During congruence system refreshing a set of revealed ks
values are changed, therefore the group controller in charge
need to re-compute all the multiplicative inverse values and
other intermediate results. However congruence system re-
freshing should not happen frequently. If it happens quite
frequently then the server should increase the ks reserve
of the subgroups. If most of the group controllers have
reached their computation limit then more subgroups should
be added to the hierarchical structure.
Congruence System Refreshing
The first step of adding a new group controller is similar
to adding a new user to the subgroup. A new added user
can take the role of the new group controller or a current
user picked from the group controller reserve can do that.
If it is a current user then it needs to be evicted from its
current location and the server will assign a new ks value.
Then this user will be added into a new subgroup (it is the
server’s direct subgroup if there is only one level of group
controllers.). In such case no group re-key is needed. After
this new group controller establishes the current position,
the server will assign a set of new ks values for this group
controller to build its own congruence system. Now, new
group users can be added to the new subgroup.
Group Controller Addition
Group controller eviction is a relatively more complicated
operation in our protocol, but it should happen infrequently
since the group controllers are picked to be the long last
group users. However, when it does happen, our protocol
has been built in such a way it will minimize its impact. A
new group controller will be picked and the ksb values of the
users in the group controller evicted subgroup will be passed
to the new group controller at once as the ks values. The
new group controller will set up the congruence system just
like in the case of group controller addition. Group re-key
will be carried out afterwards. After the new subgroup run
smoothly with the new group controller, the server can now
communicate with the users in the subgroup to replenish the
used ksb values. This way the impact of group controller
eviction is minimized.
Group Controller Eviction
Hierarchical expansion will happen when the group size
is expanded to such a scale that the server can no longer
manage all the group controllers as one subgroup efficiently.
In such case a new level of group controllers will be added
to the hierarchical structure.
Hierarchical expansion will be very similar to the group
controller eviction case. The difference is that in this case
it is like the server was evicted. However, since the server is
more likely have more computational power, the original set
of group controllers may not be handled by one new group
controller. It will need more new group controllers and the
original set of group controllers managed by the server will
be split between the new added group controllers. Similarly,
each current group controller’s ksb will be sent to the new
upper level group controllers, and the new upper level of
group controllers can set up the congruence system for their
subgroups respectively. Hierarchical expansion should be
6. COMPARISON OF GROUP KEY
In the above sections we dicussed several group key man-
agement protocols including representative previous works
and our own protocols. In the following tables we will com-
pare different aspects of those protocols, where GC stands
for group controller; n is the group size; and m is the average
size of a subgroup.
Table 1: Computation Per Group Re-keying
In Table 1 we compared the computational requirements
of those protocols. Iolus is not comparable because it has no
common group key. Even though Iolus doesn’t need to any
group re-keying computation it pays when it does the real
data transmission. Another thing need to be pointed out
is that for group re-keying the main computations in HT-
BCGK are encryption or decryption, or some one way func-
tion, while the main computations in FCRGK and HCRGK
are modulo arithmatic and XOR operations.
Table 2: Storage Requirements
Table 2 compared the Storage requirements of those pro-
tocols. It is obvious to see that the FCRGK and HCRGK
protocols have great advantages on the group user side.
Table 3 compared the Transmission requirements of those
protocols. Here we compare the number of messages needs
to be transmitted between the entities per group re-keying.
Table 3: Transmission Per Group Re-keying
Even though the upper bound of the number of messages
for HTBCGK protocol is O(logn), those messages can be
assembled together to be sent out in one message. While for
FCRGK and HCRGK protocols even though the numbers
are small, each message is large. The actual size of each
message in FCRGK and HCRGK varies.
Table 4: Multi-Group Management Capabilities
Table 4 compared the Multi-Group Management Capabil-
ities of those protocols. FCRGK and HCRGK protocols can
manage multiple groups at the same time with tiny change
that is picking different group keys for different groups and
compute each X value in the same precedure. HTBCGKs
are not directly suitable for multi-group management be-
cause there is no such direct multi-group management struc-
ture built in.
In this paper, we discussed two major categories of group
key management protocols through several representative
previous works by a variety of authors. We also proposed
our own protocols for these two categories. The advantages
of different protocols have been compared. Our protocols
have the potential to minimize re-keying message number,
group end user side re-keying computation, and overall num-
ber of key storages, with a reasonable amount of computa-
tional load increase on the servers and group controllers.
Optimized implementation of our protocols is planed to be
carried out. Average message sizes and computation require-
ments of the FCRGK and HCRGK will be collected to pro-
vide a more quantitative comparison between our protocols
and others in the near future.
 Y. Amir, Y. Kim, C. Nita-Rotaru, and G. Tsudik. On
the performance of group key agreement protocols.
ACM Transactions on Information and System
Security, 7(3), 2004.
 A. Ballardie. Scalable multicast key distribution. Rfc
 R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor,
and B. Pinkas. Multicast security: A taxonomy and
some efficient constructions. In Proceedings of the 18th
Annual Joint Conference of the IEEE Computer and
Communications Societies - INFOCOM 1999,
volume 2, 1999.
 Y. Challal and H. Seba. Group key management
protocols: A novel taxonomy. International Journal of
Information Technology, 2(1), 2005.
 G.-H. Chiou and W.-T. Chen. Secure broadcasting
using the secure lock. IEEE Transactions on Software
Engineering, 15(8):929–934, 1989.
 M. Eltoweissy, M. H. Heydari, L. Morales, and I. H.
Sudborough. Combinatorial optimization of group key
management. Journal of Network and Systems
Management, 12(1), 2004.
 A. Fiat and M. Naor. Broadcast encryption. In
Proceedings of Advances in Cryptology - Crypto ’93,
 P. Garrett. The Mathematics of Coding Theory:
Information, Compression, Error Correction, and
Finite Fields. Pearson Prentice Hall, 2004.
 H. Harney and C. Muckenhirn. Group key
management protocol (gkmp) architecture. Rfc 2094,
 H. Harney and C. Muckenhirn. Group key
management protocol (gkmp) specification. Rfc 2093,
 Y. Kim, A. Perrig, and G. Tsudik. Tree-based group
key agreement. ACM Transactions on Information and
System Security, 7(1):60–96, 2004.
 S. Mittra. Iolus: A framework for scalable secure
multicasting. In Proceedings of the ACM SIGCOMM
 M. J. Moyer, J. R. Rao, and P. Rohatgi. A survey of
security issues in multicast communications. IEEE
Network, 13(6):12–23, 1999.
 A. Perrig, D. Song, and J. D. Tygar. Elk, a new
protocol for efficient large-group key distribution. In
Proceedings of IEEE Symposium on Security and
 S. Rafaeli and D. Hutchison. A survey of key
management for secure group communication. ACM
Computing Surveys, 35(3):309–329, 2003.
 O. Rodeh, K. P. Birman, and D. Dolev. Using avl trees
for fault tolerant group key management. International
Journal of Information Security, 1(2), 2002.
 A. T. Sherman and D. A. McGrew. Key establishment
in large dynamic groups using one-way function trees.
IEEE Transactions on Software Engineering, 29(5),
 R. E. Smith. Authentication: From Passwords to
Public Keys. Addison-Wesley, 2001.
 W. Stallings. Cryptography and Network Security:
Principles and Practices. Prentice Hall, third edition
 M. Steiner, G. Tsudik, and M. Waidner. Key
agreement in dynamic peer groups. IEEE Transactions
on Parallel and Distributed Systems, 11(8), 2000.
 D. R. Stinson. Cryptography: Theory and Practice.
Chapman & Hall/CRC, 2002.
 D. Wallner, E. Harder, and R. Agee. Key management
for multicast: Issues and architectures. Rfc 2627, 1999.
 C. K. Wong, M. Gouda, and S. S. Lam. Secure group
communications using key graphs. IEEE/ACM
Transactions on Networking, 8(1):16–30, 2000.