# Secure and Scalable Internet of Things Model Using Post-Quantum MACsec
## 5 Experimental Environment and Results
### Results  
Table 4 displays the time taken for PQC key generation, encryption, and decryption across different security levels. At first glance, it is found that the CPU performance significantly impacts the time required for PQC key generation. In the context of key generation with a security level above 128, the NTRU algorithm demonstrated superior performance compared to RSA. However, in terms of encryption and decryption processes, RSA exhibited superior performance. Nevertheless, the time delay that occurred during NTRU encryption and decryption processes was negligible in comparison to the overall communication performance. In the SSI-PQM process, the NTRU-based public key encryption was utilized once in Step #1 for the transmission of the pre-master secret. Consequently, the time delay experienced during NTRU encryption and decryption did not affect the overall communication between the servers and IoT devices. From these evaluation results, we identified that PQC-TLS corresponding to security levels 80 and 128 is the most suitable with respect to the performance of the IoT device. The performance of NTRUs significantly surpassed that of RSA, which can be attributed to faster generation of public key pairs for communications that require a security level above 160. These results lead to improvements ranging from at least 161% to as much as 8255%. As the security level increases, the time required for generating RSA public keys rises exponentially. An RSA public key is based on the product of two large prime numbers, and the difficulty of finding large primes increases exponentially with their size. To generate these primes, random numbers must be created in the desired range. This process requires significant computational effort due to the scarcity and increased length of larger prime numbers, which increases the challenge of their discovery. In contrast, key generation in \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline \multirow{3}{*}{**Security Level (bits)**} & **Minimum Latency** & \multicolumn{2}{c}{**1** Key**} & \multicolumn{2}{c}{**2** En-**} & \multicolumn{2}{c}{**3** De-**} \\  & **for TLS** & **Generation (IoT)** & **(Server)** & **(IoT)** & **(IoT)** & \\ \cline{2-7}  & **NTRUs** & **RSA** & **NTRUs** & **RSA** & **NTRUs** & **RSA** & **NTRUs** & **RSA** \\ \hline
80 & 123.4110 & 2.437 & 105.2439 & 2.3780 & 0.6336 & 0.0001 & 17.5335 & 0.0589 \\
112 & 273.1801 & 58.4968 & 251.3992 & 58.1634 & 0.8043 & 0.0002 & 20.9766 & 0.3332 \\
128 & 319.3766 & 245.786 & 293.9652 & 244.7936 & 0.7778 & 0.0004 & 24.6336 & 0.9920 \\
160 & 409.9317 & 658.7048 & 381.2517 & 656.5520 & 0.9558 & 0.0006 & 27.7242 & 2.1522 \\
192 & 612.2242 & 8214.6037 & 571.8158 & 8202.1173 & 1.0726 & 0.0017 & 39.3358 & 12.4847 \\
256 & 978.7406 & 80,798.9095 & 916.3855 & 80,710.4963 & 1.2568 & 0.0070 & 61.0983 & 88.4062 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Comparison of the time (second) spent on public key generation, encryption, and decryption using the NTRU algorithm in PQC. \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Security Level (bits)** & **Example Values** & **RSA Key Size (bits)** & **Notes** \\ \hline
80 & \(N=251\), \(p=3\), \(q=2048\) & 1024 & Constrained environments \\
112 & \(N=401\), \(p=3\), \(q=2048\) & 2048 & Balanced security and \\  & & & performance \\
128 & \(N=439\), \(p=3\), \(q=2048\) & 3072 & Standard security level \\
160 & \(N=487\), \(p=3\), \(q=2048\) & 4096 & Higher security \\
192 & \(N=593\), \(p=3\), \(q=2048\) & 7680 & Enhanced security \\
256 & \(N=743\), \(p=3\), \(q=2048\) & 15,360 & Maximum security \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Key size comparison between NTRUs and RSA: NTRU Key Size = N \(\log_{2}(q)\). NTRUs involves generating random polynomials and performing arithmetic in modular polynomial rings. NTRUs are based on solving the shortest vector problem (SVP) in a lattice and specific polynomial equations, which remain computationally efficient even with longer key lengths.