## 9 Evaluations  
In order to compare the execution time of our different protocols, we implemented each protocol on TelosB motes. In what follows, we describe the settings of our testbed. We also provide and discuss the results of the overhead of each protocol. We did not compare our protocols with other existing protocols because implementations are very heterogeneous. Implementation on sensor nodes is very hardware-dependent; optimization can be done for certain functions depending on the capacities and the design of the hardware. Thus comparing different implementations on different motes is not really conclusive, as is shown in [30, 31, 32, 33]. The same applies for comparison by simulation, which is even less conclusive because simulation does not give an idea about how complex the operations are. TelosB motes have an 8 MHz microcontroller with 10 KB of RAM, 48 KB of ROM and a CC2420 radio using the IEEE 802.15.4 standard. In our evaluation, we use public key Elliptic Curve Cryptography (ECC), with parameters secp160r1 given by the Standards for Efficient Cryptography Group. Our implementation of ECC on TelosB is based on the TinyECC library [34]. More precisely, we use Elliptic Curve Integrated Encryption Scheme (ECIES), the public key encryption system proposedby [PERSON] in 2001, and the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme [35]. For all symmetric encryptions, we use an optimized implementation of AES [36] with a 128-bit key proposed by [37] in CTR mode. In order to explain why we choose AES with CTR mode and the 128-bit key \(k\), we recall the mechanism of this scheme: let us consider a message \(m\) composed of \(p\) blocks \(m_{1}||m_{2}||\ldots||m_{p}\), and an initial counter value \(IV\) randomly chosen. The cipher of the block \(m_{i}\) is \(c_{i}=\{IV+i\}_{k}\oplus m_{i}\), where \(\oplus\) denotes the bitwise XOR operator. If one knows \(IV\) and the key \(k\), then one can easily recover from \(c_{i}\) the message \(m_{i}=\{IV+i\}_{k}\oplus c_{i}\). When the size of the last block \(m_{p}\) is smaller than 128 bits, it is usual to pad it with \(0\)s to reach 128 bits in order to let both operands have the same length to perform the bitwise XOR. In this case, the size of the transmitted encrypted packets is always a multiple of 128 bits. However, in the CTR mode, we can just cut the \(\{IV+p\}_{k}\) message to the size of \(m_{p}\). Hence we can transmit encrypted messages with exactly the same size as the original message, and therefore save some execution time. During the experiments, we considered topologies without intermediate nodes, since these nodes would only forward the packets without doing any modification on the packets. The cost of these communications is therefore dependent on the network density, topology and traffic load. In this paper, we only consider a minimal topology containing only the nodes involved in the cryptographic operations. This means that for all protocols we tested them with a topology of 3 nodes, except for \(DJS\) where only \(2\) nodes were needed for the execution. This does not affect the feasibility of our protocols for more hops, because adding more intermediate nodes does not add more cryptographic operations--intermediate nodes will only forward the message to the next hop according the routing protocol. In addition, nodes do not have other traffic to exchange during the execution of the protocols. Of course, additional overhead should be considered because of the routing process and exchanged messages, but this is very dependent on the routing and MAC layers used during the evaluation. For this reason, we preferred to include only overhead induced by the cryptographic operations and not the overhead induced by the network protocols. In the Table 3, we provide the real execution time for all our protocols. For the sake of completeness and to make the paper self-sufficient, we also included the results of \(DJS\) and \(IJS\). These results are the averages of \(100\) experiments.