## 4 Discussion of the Results  
Our experimental setup included an Intel Core i5-7600K processor (3.80 GHz) with 4 CPUs and two core exclusive L1 caches of 32 KB (one for data and other for instructions), a L2 cache of 256 KB and, finally, a L3 cache of 6 MB shared among all cores whose line size is 64 bytes. It has CentOS 7.6 installed while the Virtual Machines in our experiments have CentOS 7.6 minimal and both have one virtual core. The hypervisor WAs KVM. This information is summarized in Table 1 The target of our experiments was the 1.0.1f OpenSSL release, which includes the T-Table implementation of AES. In the previous section, we present attacks that work for different lengths of AES keys (128 or 256 bits). These attacks assume the knowledge of unused cache lines to discard possible key values and that the ciphertexts are known by the attacker. We performed the experiments in two different scenarios (virtualized and non-virtualized environments) considering different techniques to retrieve information about the cache utilization (_Prime+Probe_, _Prime+Abort_, _Flush+Reload_ and _Flush+Flush_) and different key lengths. Table 2 shows the mean number of encryptions that had to be monitored to obtain the full key in non-virtualized environments (the victim and the attacker processes run in the same OS). Similarly, Table 3 shows the results for virtualized environments (the victim runs in one VM and the attacker in a different one sharing the same host). When applying the _Prime+Abort_ technique, we wanted to monitor four different lines. We needed to define four transactional regions to distinguish between them, which also means we used more resources. Note that we do not include the results for the _Prime+Abort_ technique in virtualized environments. The TSX instructions were virtualized, thus it should be possible to perform _Prime+Abort_ in a cross-VM scenario. However, with our experimental setup consisting on an attacker preparing the cache, triggering an encryption and waiting for the result, we got too many aborts. Since all of them have similar causes, distinguishing between the aborts that were due to the encryption and the ones that were noise was difficult. For this reason, and since we considered that our point was already proved, we did not evaluate the data collected with the _Prime+Abort_ technique in the cross-VM scenario. For a fair comparison between the access and our non-access approach, we also retrieved the key for the access approach considering the key of 128 bits. Table 4 shows the results for both approaches and the percentage of improvement regarding the number of traces required to successfully retrieve the secret key. In all cases, the number of samples was reduced significantly. We noticed that, when monitoring more than one line at a time, each table provided a different amount of information. This fact can be observed in Figure 5, where we represent a color map for each byte of the key candidates array for that byte. Dark colors represent fewer discarded values (correct key values) while light colors represent most discarded values. With a uniform distribution of the input plaintexts, the minimum score was more remarkable as we increased the number of encryptions. The figure shows that there is a pattern for each byte associated with the same table. We retrieved a different number of useful samples for each table. This was due to the prefetcher and our uniform access pattern that seemed to trigger it. This meant that more encryptions were required to get the full key. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Access** & **Non-Access** & **Improvement** \\ \hline _Flush+Reload_ & 100,000 & 3000 & 97\% \\ _Flush+Flush_ & 250,000 & 16,000 & 94\% \\ _Prime+Probe_ & 190,000 & 14,000 & 93\% \\ _Prime+Abort_ & 110,000 & 3500 & 97\% \\ _Flush+Reload_(V) & 400,000 & 10,000 & 98\% \\ _Flush+Flush_(V) & 1,120,000 & 40,000 & 96\% \\ _Prime+Probe_(V) & 1,250,000 & 45,000 & 96\% \\ \hline \hline \end{tabular}
\end{table}