# A Secure and Efficient Group Key Management Scheme for Clusters of String Inverters
## 6 Discussion
### On Contributory Group Key Generation  
In our approach the KDS selects a given KDC instance, which generates and distributes the new group key. In an alternative contributory approach, all KDC instances contribute to the generation of the group key with their own share [15].  
Generating the group key in a contributory fashion is not suitable for our case because group members have to obtain the group key within a tight deadline, which is in the order of a minute. The issue with generating the group key in a contributory fashion is that, whatever operation we consider--join, leave or key refresh--the overall communication overhead grows linearly with the group size and thus is in the order of O(N) [15]. Due to the presence of a deadline, a contributory approach may not be feasible in a large group so limiting the scalability of the group itself.  
Alternative contributory approaches are those tree-based (e.g., distributed one-way function tree and Diffie-Hellman logical key hierarchy) where the overhead results to be logarithmic in the group size, i.e., in the order of O(\(\log N\)) [15]. However, better performance comes at the cost of increased complexity of the key management scheme. This is especially true in our application scenario where group members may be intermittently available due to reduced sun exposure. Therefore, for the sake of simplicity, we did not consider tree-based contributory approaches and we did not mention them any further.  
We now analyzed the complexity of the scheme we proposed, in terms of overall communication overhead, and compared it with the complexity of a contributory approach. Table 6 summarizes the results.  
First, whatever the operation we considered, in the scheme we proposed the communication (and computation) overhead of involved group inverters but the KDC was always constant, i.e., O(1).  
In the case of a join operation, the KDC unicasts the current group key to all joining inverters. It follows that the communication overhead of the KDC increased linearly with the number of joining inverters. If we indicate with \(n_{j}=|JS|\) the cardinality of the set of joining inverters, then the communication overhead of the KDS is in the order O(\(n_{j}\)). Therefore, the overall communication overhead is O(\(n_{j}\)) + O(1) = O(\(n_{j}\)). As mentioned above, in a contributory approach the overall communication overhead increased linearly with the total number \(N\) of group members. In general, O(N) >> O(\(n_{j}\)), up to even one order of magnitude.  
In the case of a leave operation, the KDC first generated a new group key and then securely distributed it to each non-evicted group member. So, the KDC had a communication overhead that increased linearly with the number of inverters that remained in the group. We called them the remaining inverters. Let LS be the set of leaving inverters, \(n_{l}\) the cardinality of that set, \(RS=G\backslash LS\) the set of remaining inverters and \(n_{r}\) its cardinality with \(n_{r}=|RS|=|G\backslash LS|=N\) - \(n_{l}\). It follows that the communication overhead of the KDS is in the order of O(\(n_{r}\)). Thus, the overall communication overhead is O(\(n_{r}\)) + O(1) = O(\(n_{r}\)). In the case of a contributory approach, the total communication  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & **Our Approach** & **Contributory Approach** \\ \hline Join & O(n\({}_{j}\)) & O(N) \\ Leave & O(n\({}_{r}\)) & O(N) \\ Key Refresh & O(1) & O(N) \\ \hline \hline \end{tabular}
\end{table}
Table 6: Overall communication overhead where \(n_{j}\) is the number of joining inverters, and \(n_{r}\) is the number of non-evicted group inverters.  
overhead linearly increased with the group size and, for this reason, it was equivalent to our approach, i.e., O(N) = O(\(n_{r}\)).  
Finally, in the case of the refresh operation, the total communication overhead corresponded to the communication overhead of the KDC only. The overhead amounted to a single multicast message, hence was constant, i.e., O(1).