# Lightweight Conversion from Arithmetic to Boolean Masking for Embedded IoT Processor
## 2 Background
### The A2B Algorithm Based on the Ripple-Carry Adder
#### 2.3.2 [PERSON]'s A2B Algorithm
\begin{table}
\begin{tabular}{c c} \hline \hline
**Line** & **A** \\ \hline
2 & \((x_{a\cdot k}^{n-1}||0_{0}^{a\cdot k-1})-(R_{a\cdot k}^{n-1}||0_{0}^{a\cdot k-1})\) \\  & \(-(r||...||r||0_{0}^{a\cdot k-1})-\sum_{l=a+1}^{n-1}(\alpha\cdot 2^{l\cdot k})\) \\ \hline
3 & \((x_{a\cdot k}^{n-1}||0_{0}^{a\cdot k-1})-(R_{a+1\cdot k}^{n-1}||0_{0}^{(a+1)\cdot k -1})\) \\  & \(-(r||...||r||0_{0}^{a\cdot k-1})-\sum_{l=a+1}^{n-1}(\alpha\cdot 2^{l\cdot k})\) \\ \hline
4,5 & **Lemma 1** \\ \hline
6 & **Lemma 2** \\  & \(\begin{cases}\text{when }c=0,\\ (x_{a\cdot k}^{n-1}||0_{0}^{a\cdot k-1})-(R_{(a+1)\cdot k}^{n-1}||0_{0}^{(a+1) \cdot k-1})\\ -(r||...||r||0_{0}^{a\cdot k-1})-\sum_{l=a+2}^{n-1}(\alpha\cdot 2^{l\cdot k})\end{cases}\) \\  & \(\begin{cases}\text{when }c=1,\\ ((x_{a\cdot k}^{n-1}+2^{(a+1)\cdot k})||0_{0}^{a\cdot k-1})-(R_{(a+1)\cdot k}^ {n-1}||0_{0}^{(a+1)\cdot k-1})\\ -(r||...||r||0_{0}^{(a+1)\cdot k-1})-\sum_{l=a+2}^{n-1}(\alpha\cdot 2^{l \cdot k})\end{cases}\) \\ \hline
7 & \((x_{(a+1)\cdot k}^{n-1}||0_{0}^{(a+1)\cdot k-1})-(R_{(a+1)\cdot k}^{n-1}||0_{0} ^{(a+1)\cdot k-1})\) \\  & \(-(r||...||r||0_{0}^{(a+1)\cdot k-1})-\sum_{l=a+2}^{n-1}(\alpha\cdot 2^{l \cdot k})\) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: The Inductive Step. In Algorithm 9, the clearing process at Line 7 as one AND. The results of the simulation show the number of clocks required to execute on the AVR (generic device -v4/8-bit), MSP430 (generic MSP430 device/16-bit) and ARM (Cortex-A17/32-bit) offered by the IAR Embedded Workbench. The parameters \(k\) and \(n\) of the masking conversion are 8-bit and 32-bit, respectively. The compiler optimization option is not used, because it could create vulnerabilities to side-channel attacks due to unintended optimization. As can be inferred from the number of operators, the numbers of clocks in the pre-computation phase in our simulation and that of [17] are less than half of that in [PERSON]'s algorithm. On the other hand, the results of the conversion phase vary greatly depending on the microcontroller. The reason [PERSON]'s algorithm is relatively fast on the 8-bit-based microcontroller (AVR simulator) is that the 8-bit operators are major parts of the whole operation, whereas the reason our algorithm produced comparable results on the 32-bit-based microcontroller (ARM simulator) is that the main part of ours is mostly composed of 32-bit operations, such as Lines 6, 7 in Algorithm 9. In addition, there are several parts of our algorithm for which it is easy to apply optimization during actual implementation. For example, in a loop unrolling technique, our algorithm can be coded as **for**\(i\)s to constants, and avoid duplicate operations by using temporary variables. Concretely, in the case of \(k=8\) and \(n=4\), we can code Line 3 of Algorithm 9 like \(A+R\&0\)xff, \(A+R\&0\)xff00; and Line 7 can also be coded as \(A\&0\)xffffff00, \(A\&0\)xffff0000. In terms of performance, our results are better than [22] and similar to [17]. However, in terms of side-channel security, [17] has potential vulnerabilities of the binary classification referred to [28]. That is, our proposals provide excellent performance like [17] and stronger secure management of the carry bit like [22]. Due to recent advances in technology, low-priced devices have achieved great improvements, and as a result 32-bit-based microprocessors have gained widespread use. The proposed algorithms are confirmed to have great advantages not only in terms of memory, but also in terms of the execution time and security in a practical environment.