# A Hybrid-Cryptography Engine for Securing Intra-Vehicle Communications
## 4 Crypto-Engine Implementation in the EMERGE Project
### Experiment 2: ECTAKS Encryption/Decryption  
Figures 6 and 7 report the latency introduced (in seconds) when the Crypto-Engine is asked to encrypt or decrypt via ECTAKS a randomly generated payload with a size in the range between 1 Byte and 10 KiB. Every point in the graphs has been obtained as the average value over 1000 runs.  
The RPI platform (Figure 6) shows an encryption time between 6 and 6.4 ms and a decryption time between 4.3 and 4.8 ms. Both primitives show a latency with a linear growth, although the decryption is noticeably faster. This behavior is expected, since ECTAKS decryption requires a smaller number of basic operations.  
The NUC (Figure 7) shows a better performance, with an encryption time between 0.73 and 0.87 ms and a decryption time between 0.59 and 0.73 ms. Here, the NUC shows 6 to 8 times better results (expected, thanks to the faster CPU and RAM). However, the NUC shows some interesting behaviors:  
* There is a noticeable instability for payloads smaller than 1 KiB;
* In the encryption, there are latency spikes separated by \(\sim 1.5\) KiB during the encryption;
* The growth of the decryption time increases, reducing the gap with the encryption performance on large payloads.  
Figure 5: Execution time (\(y\)-axis, in seconds) for _Key component generation_ versus number of nodes \(N\) (\(x\)-axis) in a full-mesh ANT.  
Figure 6: Crypto-Engine encryption/decryption performance on Raspberry PI model 3B+: time (\(y\)-axis, in seconds) versus payload size (\(x\)-axis, in bytes).  
Those behaviors can be motivated by the superposition of effects of caching, page faults, and dynamic memory allocation (i.e., _heap_) effects triggered when de-allocating memory (e.g., _consolidation_ and _binning_ of free chunks of heaps).  
**Experiment 3: ECTAKS Signature Generation/Verification**  
Figure 8 shows the results for ECTAKS cryptographic signature generation and verification on payloads with sizes from 1 byte to 10 KiB for the RPI. The results show that signature generation takes from 45 us to 50 us with a very limited dependency on payload size. A similar scenario was observed for the signature verification, which is noticeably faster that the generation and takes as long as from 5 to 10 us. This is expected, since the verification does not require the hash computation (i.e., in this case SHA-256).  
The NUC platform exhibits better performances (Figure 9), although with some instability on payloads smaller than 512 bytes. The signature generation time, at worst, is smaller than 20 us and starts to stabilize to around 6.5 us for payloads larger than 512 bytes. Once such a threshold is reached, the effect of the growing payload size is negligible. The signature verification on the NUC is very fast, with sub-microsecond time and negligible effect by the payload size.  
Figure 8: Crypto-Engine signature generation/verification performance on Raspberry PI model 3B+: time (\(y\)-axis, in seconds) versus payload size (\(x\)-axis, in bytes)  
Figure 7: Crypto-Engine encryption/decryption performance on Intel NUC 11 TNHi3: time (\(y\)-axis, in seconds) versus payload size (\(x\)-axis, in bytes)