# Study About the Performance of Ascon in Arduino Devices
## 4 Security Analysis
### Security Bound for Ascon  
Until now, most security analysis bounds have treated Ascon as a variant of a duplex construction to establish security. A comprehensive study to establish a tight security bound on Ascon can be found in [41]. The approach of treating Ascon as any variant of a sponge construction is not the most accurate, since it benefits from double-key initialization and double-key finalization that make Ascon a much more robust algorithm than standard sponge constructions. In order to understand the security improvement offered by Ascon, we will now present the known bounds for the standard sponge constructions and the bounds available for Ascon in [41]. It is well known that sponge constructions (including keyed variants such as MonkeyDuplex) have \(2^{c/2}\) security bits, where \(c\) is the capacity of the sponge. Moreover, a common security bound in the analysis of any duplex AEAD scheme is given by theexpression \(D\cdot t/2^{c}\), where \(D\) is the data complexity, which is the total number of initializing and duplexing calls to the permutation, and \(t\) is the time complexity, which is the total number of calls to the permutation. A condition that is satisfied in most existing security analyses of Ascon and other sponge constructs is that \(D\cdot t\ll 2^{c}\), where in some cases, the \(D\) is replaced by \(q_{D}\), which is the number of decryption queries performed by an attacker. In [41], a strict safety limit is established, which depends on the key \(k\), the capacity \(c\), the state \(b\) and the tag \(\tau\) sizes. The security bound is  
\[\frac{t}{2^{\min\{k,c\}}}+\frac{D}{2^{\min\{\tau,c\}}}+\frac{D\cdot t}{2^{b}}. \tag{8}\]  
Comparing this bound with previous work, it is clear that Ascon exceeds the security level of generic duplex constraints. Finally, considering the requirements established by the NIST LwC competition, where \(D\leqslant 2^{53}\), \(t\leqslant 2^{112}\), \(k\geqslant 128\), and \(t\geqslant 64\) must be satisfied, the authors conclude that an adequate security level can be achieved in Ascon by defining the capacity as \(c=128\) bits (for the \(b\) state of 320 bits) and the tag as \(t=64\) bits. These changes would result in the rate \(r\) to be at least 192 bits, which would be an improvement in efficiency without compromising the security of the algorithm and the permutation. In addition, it can be stated that the best key-recovery attacks are carried out with the AEAD variants of Ascon with an initialization of 7 rounds, out of the 12 established in [42], while one of the best attacks on the hash variants of Ascon is a pre-image attack that only considers 4 rounds [43]. The most sophisticated attacks of this type combine power analysis attacks with ML techniques (see [28,44]). [PERSON] et al. consider in [45] the mixed-integer linear programming (MILP) model studied in [43] and they reformulate the same problem in terms of the Boolean satisfiability (SAT), achieving a significant acceleration in time, reducing the memory complexity and removing the heuristic. In addition, in the same paper, the authors study lower bounds for the probability of the permutations of Ascon. In [46], the authors present a comprehensive analysis of the security of Ascon when considering the reference and a protected implementation and implemented on a 32-bit microcontroller. [PERSON] and [PERSON] show their results using CPA and DL tools, giving a practical estimation of the effort required to recover the full key in the authenticated encryption process. According to the authors, an attacker can recover the full key from the reference implementation with 8000 traces and CPA or with 1000 traces and DL. An ensemble of deep neural networks are used in [47] (and previously in [47]) to attack two different Ascon implementations. The authors employed five multilayer perceptrons or convolutional neural networks to find with, less than 3000 traces, the secret key for a protected implementation of Ascon.