## 9 Evaluations
We added in the table the standard deviation of these averages. \begin{table}
\begin{tabular}{c c c c} \hline
**Protocol Name** & **Execution Time on the Testbed (ms)** & **Standard Deviation (ms)** & **Message Size (\(Bytes\))** \\ \hline \(DJS\) & 10,112.62 & 78.09 & 66 \\ \(IJS\) & 10,180.81 & 111.94 & 116 \\ \hline \(MKE_{S}\) & 6828.48 & 5.96 & 119 \\ \(MKE_{S}-light\) & 3649.74 & 6.10 & 71 \\ \(MKE_{T}-a\) & 6831.18 & 6.76 & 119 \\ \(MKE_{T}-b\) & 6950.10 & 5.77 & 159 \\ \(MKE_{T}-c\) & 7324.88 & 7.77 & 177 \\ \(MKE_{T}-d\) & 7447.32 & 8.61 & 217 \\ \hline \end{tabular}
\end{table} 
Table 3: Total execution time and total size of exchanged messages of our protocols using a 160-bit ECIES key and a 128-bit AES-CTR key. Moreover, the differences in our protocols come from the usage of cryptographic primitives. All protocols using asymmetric encryption (\(DJS\) and \(IJS\)) require more execution time than protocols using only symmetric encryption (\(MKE_{S}\), \(MKE_{S}-light\), \(MKE_{T}-a\), \(MKE_{T}-b\), \(MKE_{T}-c\) and \(MKE_{T}-d\)). In what follows, we analyze the results:  
* Note that the two slowest protocols are the join protocols proposed in [11]. Hence, it is more efficient to establish keys after the deployment than to rejoin the network. * Protocols \(MKE_{S}\) and \(MKE_{T}-a\) have practically the same execution time. The small difference comes from the use of symmetric keys established after the deployment instead of symmetric shared keys computed before deployment. * Protocol \(MKE_{S}-light\) is the fastest protocol because the sink computes \(K_{DH}(I,R)\) and delivers it to \(I\) and \(R\) in order to save their energy. * Protocols \(MKE_{T}-c\) and \(MKE_{T}-d\) are slower than \(MKE_{S}\), \(MKE_{T}-a\) and \(MKE_{T}-b\) due to the additional messages sent from \(R\) to \(S\) containing the public key of \(R\). * The difference of execution time between \(MKE_{T}-a\) and \(MKE_{T}-b\), on one side, and \(MKE_{T}-c\) and \(MKE_{T}-d\), on the other side, is almost equal to \(130\) ms. This is due to the encryption, decryption and transmission of \(pk(I)\) added to the request message sent by node \(I\). * In Table 3, we also provide the total size in \(Bytes\) of all exchanged messages for each protocol. In the figures of protocols presented in Sections 4 and 6, the size in \(Bytes\) is also tagged at the bottom of each message. We have fixed the size of the identity of a node to \(1\)\(Byte\) and the size of a nonce to \(4\)\(Bytes\). It should be noted that the size of \(K_{DH}(I,R)\) is fixed to \(16\)\(Bytes\). Indeed, the result of computation of \(pk(I)\times sk(R)\) gives a key length of \(20\)\(Bytes\). We use the first \(16\)\(Bytes\) of the computation result for \(K_{DH}(I,R)\). * Also note that we use symmetric encryption in all protocols for key establishment of Section 6. Therefore, the size of the input message in \(Bytes\) is the same as the size of the output message. In contrast, we use both asymmetric encryption and symmetric encryption in the two join protocols of Section 4. Therefore, in order to obtain the tagged value of message size, we must add to the output encrypted message the size of the MAC, which is equal to \(20\)\(Bytes\). For example, the total size of last message in Figure 1 sent to \(I\) is \(66\)\(Bytes\), containing \(n_{I}\)(\(4\)\(Bytes\)), \(S\) (\(1\)\(Byte\)), \(K(I,S)\) (\(16\)\(Bytes\)) and a MAC (\(20\)\(Bytes\)). Notice that the standard variation values are small compared with the execution time of the protocol. These variations are essentially caused by the various interruptions of the micro-controller. Nevertheless, we can see that the highest standard deviation values are obtained for protocols using public key encryption (\(DJS\) and \(IJS\)). These complex computations take more time and for each experiment the execution time can vary a little bit more. Indeed, the public encryption starts with a random number generation and then multiplies it with the generator point of the curve.