# Memory Efficient Implementation of Modular Multiplication for 32-bit ARM Cortex-M4
## 2 Background
### Multi-Precision Multiplication
The one-way carry-catcher method for integrated doubling and MAC operations introduces further optimizations of memory access. ### Evaluation of SIKE

Table 3 compares the execution time and ROM of the SIKE round 2 protocols with other works. A 32-bit ARM Cortex-M4 processor is evaluated with the STM32F4 Discovery board. The board supports 1 MB of Flash and 192 KB of RAM. For the fair benchmark test of SIKE, the well-known pqm4 library is uploaded to the board and the actual system clock cycles are obtained. This is a well-known benchmark framework for post-quantum cryptography. Previous works by [PERSON] et al. mainly focused on the speed optimization [14], while the proposed implementation targets the minimum code size. The previous SIKEp434 implementation achieved \(252\times 10^{6}\) clock cycles, while the proposed SIKEp434 implementation achieved \(469\times 10^{6}\) clock cycles. The execution timing is translated into throughput. As we evaluated the performance at 168 MHz, the full key exchange of SIKEp434 is performed within 2.79 s on low-end microcontrollers, which is \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Approach** & **Code Size** & **256** & **512** & **768** & **1536** & **3072** \\ \hline
**Public Key Cryptography** & & **ECC** & **SIKE** & **SIKE** & **RSA** & **RSA** \\ \hline \multicolumn{6}{c}{**Multi-Precision Multiplication**} \\ \hline [PERSON] \({}^{\dagger}\)[9] & 1284 & 631 & – & – & – & – \\ Santis and Sigl\({}^{\dagger}\)[10] & 1264 & 546 & – & – & – & – \\ Fujii and Aranha \({}^{\dagger}\)[11] & 622 & 239 & – & – & – & – \\ Haase and Labrique [12] & 452 & 212 & – & – & – & – \\ [PERSON] et al. [13] & – & – & – & 4,319 & – & – \\ [PERSON] et al. [14] & 452 & 196 & – & – & – & – \\ [PERSON] et al. (SIKE) [14] & 3,396 & – & – & 1556 & – & – \\ This work & 260 & 608 & 1816 & 3696 & 13,369 & 50,857 \\ \hline \multicolumn{6}{c}{**Multi-precision squaring**} \\ \hline [PERSON] \({}^{\dagger}\)[9] & 1168 & 563 & – & – & – & – \\ [PERSON] and [PERSON]\({}^{\dagger}\)[10] & 882 & 362 & – & – & – & – \\ [PERSON] and [PERSON] \({}^{\dagger}\)[11] & 562 & 218 & – & – & – & – \\ [PERSON] and [PERSON] [12] & 324 & 141 & – & – & – & – \\ [PERSON] et al. [14] & 320 & 136 & – & – & – & – \\ [PERSON] et al. (SIKE) [14] & 2372 & – & – & 1054 & – & – \\ This work & 324 & 493 & 1285 & 2397 & 7654 & 26,806 \\ \hline \hline \end{tabular} \({}^{\dagger}\) Including fast reduction.

\end{table} 
Table 2: The comparison results of the code size (bytes) and execution time (clock cycles) of different multi-precision multiplication implementations and multi-precision squaring implementations for operands ranging from 256 to 3072 bits. reasonably fast. By considering the speed and size trade-off, the performance of the SIKEp434 protocol is 46% (\(252\times 10^{6}\) cc vs. \(469\times 10^{6}\) cc) slower than that achieved in the previous work, but we reduced the code size by 13% in this case (33,528 bytes vs. 29,176 bytes). The enhancement of execution timing is similar for SIKEp751, but the difference in code size between the speed version and the size version in greater. The previous SIKEp751 implementation requires 44,688 bytes, while the proposed SIKEp751 implementation requires 28,816 bytes. We also first implemented the SIKEp610 protocols on ARM Cortex-M4 processors, and the execution timing and code size achieved reasonable results. The other strength of scalable implementation is definitely scalability. The SIKE implementations share the majority of operations except special parameters and finite field operations. All SIKE implementations, including SIKEp434, SIKEp503, SIKEp610, and SIKEp751 with scalable multiplication and squaring may require around 40 KB. However, all SIKE implementations with speed optimized multiplication and squaring may require around 100 KB. The system requirements in terms of speed (i.e., throughput), resources (i.e., code size), and energy consumption are determined by the architectural choices for a given application.