New Subclass Framework and Concrete Examples of Strongly Asymmetric Public Key Agreement

Round 1

Reviewer 1 Report

There's presented an interesting new method.

The introduction is a bit long and includes many details that are more appropriate for other sections.
On the other hand, the conclusion is too tiny.

The paper can be accepted because introduces a novel, interesting solution in my opinion but the structure of the paper should be revised before publication.

Author Response

Dear reviewer 1

 

We express appreciation to you giving us the fruitful comment.

According to your comment, we revised the article as following:

 

—————————————————————————————————————

Comment:

The introduction is a bit long and includes many details that are more appropriate for other sections.

On the other hand, the conclusion is too tiny.

 

=> As you mentioned, the introduction was a long and it made reader difficult to understand the center of this study clearly. We limited ourselves just to mention research background and research concept, goals derived from the background in Introduction section. The research methods part (previous version of Section 1.3 - 1.5) is now independent section (Section 2). Moreover, we showed abstract of each section at Section 2.5 (line 224) to clear the path to our main idea.

 

Best regards,

Koki Jimbo

Satoshi Iriyama

Massimo Regoli

 

2021, 26 May

 

Reviewer 2 Report

The authors declare that the paper presents a new subclass of SAPKA (Strongly Asymmetric Public Key Agreement) and examples of concrete algorithms, in which the responsibility of maintaining security is significantly more associated with the secret parameters of Bob than those of Alice. Why do the authors consider it an advantage of the proposed class of algorithms? The authors try to justify this in the paper, but I find it unconvincing (see comments below).

General remarks and comments:

1. Defining frameworks for cryptographic algorithms is used in cryptography but requires a lot of attention and precision. This is due to the fact that the defined framework should allow not only to design specific cryptographic algorithms, but also to prove their security. The authors show to design appropriate subclasses of Strongly Asymmetric Public Key Agreement schemes, but it is not known how to prove their security. In other words, there is a lack of frameworks for security models and techniques for reducing the obtained Asymmetric Public Key Agreement schemes to difficult computational problems.
2. The paper is very extensive and touches upon many topics. This makes it difficult to understand and an alyze presented ideas, especially these related to security of protocols, agreeing the keys and their practical value. I propose to definitely shorten the article and limit yourself to those topics only that are at the heart of the pronated subclass framework (including both protocols, security models and reductions).
3. The attacks on key agreement schemes discussed in this paper focus only on the recovering the secret key of Alice or Bob from the public keys. However, none of the schemes have been designed for resistance to Man-in-the-Middle (MITM) attack. In the case of the classic DH protocol the solution of this problem was obtained thanks to public key certificates. The paper does not provide information on how to protect the proposed schemes against MITM attacks.
4. The paper is not very practical. Disregarding the lack of the inability to define a general framework for assessing the security of key agreement schemes and solving the MITM problem, too many public keys can be a problem.

Each user can act simultaneously as Bob and Alice. Hence, each user (let's assume there are N users in total) has two public keys for the Bob role (in the case of the SEDH scheme, each public key contains d * d public subkeys), and for the needs of acting as Alice in relation to each other users,  N-1 additional public keys are necessary (in the case of SEDH, each key contains d * d public subkeys). This means that in a group of N users, it is necessary to manage a total of N (N-1) public keys.

If it is necessary to issue a certificate for each key to protect against MITM attack, the key management becomes much more complex than with symmetric keys. Additionally, considering the various validity periods of Bob and Alice's certificates, the problem of key management would be very complex indeed.

5. The proposed key handshaking schemes generate only static keys. In practice, it would be desirable to generate ephemeral keys for each execution of concrete SAPKA scheme.

Some detailed comments:

page 9, Definition 3: I propose to consistently indicate the equation (13);

Line 210: “the quintuple (x1, x2, x3, x4, N1) is Bob's secret key”, but the key x2 for concrete examples of SAPKA in Section 2 is equal to identity map.

Author Response

Dear reviewer 2

 

We express appreciation to you giving us the fruitful comments.

According to your comments, we revised the article as following:

 

—————————————————————————————————————

Comment 1:

Defining frameworks for cryptographic algorithms is used in cryptography but requires a lot of attention and precision. This is due to the fact that the defined framework should allow not only to design specific cryptographic algorithms, but also to prove their security. The authors show to design appropriate subclasses of Strongly Asymmetric Public Key Agreement schemes, but it is not known how to prove their security. In other words, there is a lack of frameworks for security models and techniques for reducing the obtained Asymmetric Public Key Agreement schemes to difficult computational problems.

 

=> As you mentioned, it is a difficult problem how to prove the security of PKA frameworks because the security is depend on how parameters are chosen, in other words, the security of frameworks are totally depend on the algorithms which frameworks including. Thus, the same is true for Strongly Asymmetric Public Key Agreement framework and the security of it is also varied depending on chosen parameters. This topic, we consider should be worked and resolved too. Moreover one of our future works, which is determining ’The sufficient conditions for the SAPKA_{A<B} class’ is strongly related to this topic, so we added this description at the Conclusion section (line 604).

 

By the way, our main forcus is not ’To prove security of SAPKA framework’ but ‘Show parameter setting to reduce Alice’s computational complexity while maintaining security’ in this paper. The prior topic is obviously difficult to achieve but the later one is achievable enough from considering the framework directly. This is because the fact that asymmetry or symmetry of algorithms can be easily determined from definition 7 (page 24) and results are different between asymmetric ones and symmetric ones (Necessary Condition 1 at Section 4,2 page 26). The Necessary condition 2 and Corollary 2 (page 27) are introduced also directly from the property of SAPKA framework.

 

We thought we should emphasise our focus is different from general cryptographic analysis, so we added some descriptions about our study aim from line 106 and we separated the Method section (previous version of section 1.3 - 1.5) from Introduction section to clear our aim.

 

Results from this point of view can be an answer to the problem we mentioned in Section 1.1, so advantages for our study can be explained.

 

—————————————————————————————————————

Comment 2:

The paper is very extensive and touches upon many topics. This makes it difficult to understand and an alyze presented ideas, especially these related to security of protocols, agreeing the keys and their practical value. I propose to definitely shorten the article and limit yourself to those topics only that are at the heart of the pronated subclass framework (including both protocols, security models and reductions).

 

=> As you mentioned, path to our main idea (Introducing SAPKA_{A<B} class and some necessary conditions for it) was unclear. We thought this was because:

1. our main focus was not clear to understand

2. role of each section was not clear

About the first point, we hope revision for your comment 1 (from line 106) is sufficient. About the second point, we describe each role of section precisely at section 2.5 (from line 226) to clear the path to our main results . To shorten the article is a great idea to increase readability but we judged any part of this article should not be omitted and judged showing clearly what we aiming to do and what methods we take for our goal are the best strategy for us.

—————————————————————————————————————

Comment 3:

The attacks on key agreement schemes discussed in this paper focus only on the recovering the secret key of Alice or Bob from the public keys. However, none of the schemes have been designed for resistance to Man-in-the-Middle (MITM) attack. In the case of the classic DH protocol the solution of this problem was obtained thanks to public key certificates. The paper does not provide information on how to protect the proposed schemes against MITM attacks.

Comment 4:

The paper is not very practical. Disregarding the lack of the inability to define a general framework for assessing the security of key agreement schemes and solving the MITM problem, too many public keys can be a problem.

 

=>As you pointed out, discussing MITM attack against public key based algorithms is very important especially when we consider practical uses. Here in this article, we didn’t discuss about MITM attack because we thought showing some advantages to consider asymmetric type algorithms was the top priority (we considered resiliency against MITM is the next step). No discussion about MITM doesn’t mean that algorithms of SAPKA are resilient for MITM attack (obviously many keys of SAPKA algorithms might be a problem) and we should have mentioned it. In the sequel paper, we will discuss how to protect algorithms in SAPKA from general MITM attack utilising such as public key certificates, how to manage many public keys of SAPKA and finally, discuss about practical use of SAPKA algorithms. We added these as our future works at the section of Conclusions (Section 7.1) with extra citations [23-25].

 

—————————————————————————————————————

Comment 5:

The proposed key handshaking schemes generate only static keys. In practice, it would be desirable to generate ephemeral keys for each execution of concrete SAPKA scheme.

 

=> Generating ephemeral keys of SAPKA scheme especially randomness of public keys and the SSK will also be discuss in our sequel paper. We added it as our future works at the section of Conclusions (Section 7.1).

 

—————————————————————————————————————

Detailed comment 1:

page 9, Definition 3: I propose to consistently indicate the equation (13).

 

=> We corrected the definition to indicate (13) instead of (5).

 

—————————————————————————————————————

Detailed comment 2:

Line 210: “the quintuple (x1, x2, x3, x4, N1) is Bob's secret key”, but the key x2 for concrete examples of SAPKA in Section 2 is equal to identity map.

 

=> SAPKA is defined just as x1, x2, x3, x4 to be arbitrary map S -> S and N1 be an invertible map S -> S. Thus, there is no problem for some of maps to be identity (Of course some of (x1, x2, x3, x4, N1) can lead us to construct a weak PKA algorithm, see section 2.3 or the beginning of section 5 of revised version).

 

Best regards,

Koki Jimbo

Satoshi Iriyama

Massimo Regoli

 

2021, 26 May

 

Reviewer 3 Report

The authors should clarify in their conclusions the last four points defined as "urgently considered".
It is not clear that they are new problems, problems that have been obtained from the study presented or problems to be solved in the immediate future.  

Author Response

Dear reviewer 3

 

We express appreciation to you giving us the fruitful comment.

According to your comment, we revised the article as following:

 

—————————————————————————————————————

Comment:

The authors should clarify in their conclusions the last four points defined as "urgently considered".

It is not clear that they are new problems, problems that have been obtained from the study presented or problems to be solved in the immediate future. 

 

=> As you mentioned, previous version of Conclusion section was unclear in terms of where mentioned problems come from. We separated Conclusion section into summarisation of presented study part (beginning of section 7) and our future works part (section 7.1). In the future works part, new problems obtained from presented study and problems not discussed in this paper but must be investigated for practical use of presented algorithms and frameworks are described.

 

Best regards,

Koki Jimbo

Satoshi Iriyama

Massimo Regoli

 

2021, 26 May

Round 2

Reviewer 2 Report

I accept the authors' responses and the improvements introduced into the article, especially those that relate to the aim of the article. However, my doubts about the security model remain.

On the one hand, the authors declare that 'this study is not focus on how to construct secure PKA algorithms against any types of theoretical attacks', but on the other hand in one of their replies to my comment is written that the aim of the paper is 'to show parameter setting to reduce Alice's computational complexity while maintaining security'. This is a very valid goal, only again the question has to be asked: how do the authors understand the concept of 'security' that cannot be lost/decreased while reducing Alice's computational complexity?

From the complexity analysis point of view and Alice's computational complexity reduction, the article is correct and rather well justifies the construction of the introduced SAPKA subclasses.  I hope that the problems of the lack of formal definition of security models for the key agreement protocols presented in the article, what I pointed out earlier, will be the subject of further articles by the authors. Additionally, these problems may be of interest to cryptologists and form the basis for the development of secure SAPKA protocols and its subclasses.