# New Subclass Framework and Concrete Examples of Strongly Asymmetric Public Key Agreement
## 7 Conclusions  
In this study, we have estimated the breaking complexity and computational complexity of two SAPKA class algorithms. One of these potentially possesses the property \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Security (\(n\))** & (\(m\)) & (\(d\)) & **DH (ms)** & **SEDH (ms)** \\ \hline
1024 & 256 & 2 & 2.727202 & 1.896316327 \\ \hline
2048 & 512 & 2 & 15.514816 & 6.451664815 \\ \hline
3072 & 384 & 4 & 51.776748 & 16.480546 \\ \hline
4096 & 1024 & 2 & 111.332034 & 32.10356 \\ \hline
5120 & 640 & 4 & 202.806142 & 57.475974 \\ \hline
6144 & 768 & 4 & 335.208752 & 94.12185 \\ \hline
7168 & 896 & 4 & 535.273036 & 144.93926 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Comparison of calculation times (ms) for [PERSON] with [PERSON]. Figure 4: Comparison of calculation times (ms) for [PERSON] and [PERSON] according to \(d\) (m = 128). Figure 5: Comparison of calculation times (ms) for [PERSON] with [PERSON]. whereby the security is less dependent on the secret key space of [PERSON] than that of [PERSON]. This property allows [PERSON] to calculate her SSK with less complexity than [PERSON] in the algorithm. Moreover, we generalized these algorithms and constructed SAPKA subclasses according to the security/efficiency properties. We constructed several subclass algorithms in which the above property holds. We expect that algorithms in this class will aid in constructing secure communication infrastructures, even with a small capability of devices for one side ([PERSON]'s computational asymmetry). The necessary conditions for this class and inclusion relations with other SAPKA subclasses were also investigated. In the following Future Work section, we provide several unclear points, which include new problems obtained from this study (indicated by \(\bullet\)) and problems not discussed in this paper but that must be investigated for practical use of presented algorithms and frameworks (indicated by \(\circ\)). Future Works
* Is it true that \(SAPKA_{f_{g},A<B}\cup SAPKA_{f_{g},A=B}=SAPKA_{f_{g}}\)? (Remark 5)
* Is it true that if the relations (52) and (53) hold for \(C\in SAPKA_{f_{g}}\), C is a member of the \(SAPKA_{f_{g},A<B}\) class? That is, are (52) and (53) also sufficient conditions for the \(SAPKA_{f_{g},A<B}\) class? As mentioned in Section 2.2, this paper does not provide how to construct secure PKA algorithms resilient to any types of theoretical attacks. However, if sufficient conditions for the \(SAPKA_{f_{g},A<B}\) class are found, algorithms that cannot be broken at least within polynomial time can be easily constructed because those are protected thanks to non-easily mapable \(f_{g}\) (page 23). Of course, conditions might differ depending on required security level, but considering the sufficient conditions surely helps us provide how to construct secure PKA algorithms. * Does \(\mathcal{S}\) need to be selected as a multiplicative semi-group/group? For example, the algorithms in Section 3.3 are effective even in vector space, which forms an additive group (Remark 1). We should investigate how we can construct PKA algorithms on algebraic structures other than multiplicative semi-groups and then compare the breaking and computational complexities with the original one. * We should attempt to describe algorithms such as LWE-based or NTRU-type algorithms with the SAPKA parameters and verify whether these algorithms belong to the \(SAPKA_{f_{g},A<B}\) class. Otherwise, would it be possible to modify these to belong to the \(SAPKA_{f_{g},A<B}\) class? * It is well known that key agreement algorithms are vulnerable against man-in-the-middle (MITM) attack. Obviously, also algorithms in SAPKA are also not exceptional without any measures. Moreover, the number of public keys especially for Bob is larger than symmetric type algorithms, so they way to manage public keys for SAPKA algorithms must be discussed more. Adaptability with techniques such as digital signature [21; 22] and public key certifications [23] must be well discussed.