Decentralized Inner-Product Encryption with Constant-Size Ciphertext
Round 1
Reviewer 1 Report
This paper proposes a decentralized IPE with constant-size ciphertext. The discussion seems correct but there are some unclear aspects as follows.
At line 46, the authors say "slightly modify the definition of DIPE." But, difference between the original definition and the modified one is unclear. Hence, the authors should clearly state the difference in Section 2.3.2.
At line 51, the authors say "In Chapter 3, we review..."; however, in the manuscript, there is no chapter which reviews the previous works. The authors should add a chapter in order to help readers to understand a strategy of construction and in order to be self-contained. This chapter may be in appendix.
At line 104, the output "a partial key of private key associated..." is unclear. In the key generation algorithm of the concrete scheme, the output is not "partial private key" but "secret (private) key". What does "partial" means at line 104. The authors should explain it clearly.
The sentence at lines from 114 to 116 is strange. For example, from the sentence, the setup algorithm "is generated by" a public parameter. The authors should check the sentence and correct it.
In Section 2.3.1, the authors explain that there are three roles (entities); sender, receiver, authorities. On the other hand, in Table 1, there is another word, "user", in the description of GID. The authors should explain what the "user" is and how many users in the system. In KeyGen of the concrete scheme, keys are generated for users (GID). If the user means sender/receiver, each authority should prepare key for each sender/receiver in the system, but it seems unrealistic.
At line 167, \alpha_j is undetermined before, and hence, the conjunction ",where" is strange. Moreover, in order to satisfy \alpha_j = \sum_i \alpha_{j,i}, authority A_i should know all \alpha_{j,i} which are private/secret value of other authorities.
At line 172, why is "will" required.
In Section 3, the discussion (proof) for the correctness of the proposed scheme (namely, the plaintext is recovered by the decryption from the ciphertext) is helpful for readers.
At line 226, the authors should explain that <X,Y^*> in the equation "t=..." should not be zero.
Similarly, at line 231, the authors should explain why "<X,Y^*> \ne 0" is satisfied.
At line 237, "D_{,n}" should be "D_{1,n}."
In Definition 3, there is no restriction "of the same length" described at line 242. The authors should check it and modify the definition or the sentence at line 242. (but, before discussing the length, the authors should give a definition of message space)
In Table 4, the comparison of confidentiality is unfair. its goal "sIND" should be explicitly explained in the table. Moreover, the authors should explain a reason why only "CPA" is considered in the research (for all schemes) and "CCA" is not considered. If there is a conversion from CPA to CCA and it can be applied only to the scheme of [12] (not to the proposed scheme), it should be a disadvantage of the proposed scheme.
Author Response
We deeply appreciate the reviewer for the valuable comments and encouragement. We have revised our manuscript according to the reviewers' comments, where the revised parts are colored red. We have also prepared a response file to the reviewers' comments. The response to Reviewer 1's comments are shown in Section 1 of the response file (p. 1 - p. 3). Besides, in page 5 to page 20 of the response file, we have attached a file to show the difference before and after revision, where the original texts and revised texts are colored with red and blue.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
The paper is well-written and the proposed approach sounds promising.
The topic is very relevant especially with the trend of distributed system paradigms.
The proposed approach has been implemented and evaluated formally.
Author Response
We deeply appreciate the reviewer for the valuable comments and encouragement. We have revised our manuscript according to the reviewers' comments, where the revised parts are colored red. We have also prepared a response file to the reviewers' comments. The response to Reviewer 2's comments are shown in Section 2 of the response file (p. 4). Besides, in page 5 to page 20 of the response file, we have attached a file to show the difference before and after revision, where the original texts and revised texts are colored with red and blue.
Author Response File: Author Response.pdf
Reviewer 3 Report
The authors described decentralized inner product encryption using constant size ciphertext. The authors analyzed the security and compare their approach with the existing one.
However, I have the following concerns:
1- The introduction doesn't show the importance of the identity-based encryption in current technology (IoT). The topic is a bit outdated and not so many research work are being carried out. This perhaps the weakest point in the study
2- In the implementation, Python is not the suitable candidate to show the efficiency (time and memory). The authors are advised to implement the algorithm using a real programming language (e.g. C) not a scripting language.
3- The paper is not well structured. E.g. Tables 3 and 4 have some detached text.
Author Response
We deeply appreciate the reviewer for the valuable comments and encouragement. We have revised our manuscript according to the reviewers' comments, where the revised parts are colored red. We have also prepared a response file to the reviewers' comments. The response to Reviewer 1's comments are shown in Section 3 of the response file (p. 4). Besides, in page 5 to page 20 of the response file, we have attached a file to show the difference before and after revision, where the original texts and revised texts are colored with red and blue.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
I think the paper is revised well to answer my questions.
Author Response
The authors appreciate the reviewer for the valuable comments and encouragement. The attached please find our response to the reviewers' comments and the change tracking document.
Author Response File: Author Response.pdf
Reviewer 3 Report
The authors didn't consider the points raised in the previous review. Instead, the authors put those points as future improvements. Could you please provide the reasons for putting those points as a future improvements?
Author Response
The authors appreciate the reviewer for the valuable comments and encouragement. The attached please find our response to the reviewers' comments and the change tracking document.
Author Response File: Author Response.pdf
Round 3
Reviewer 3 Report
Doing a research that attracts audiences is very important both for the journal and authors. I agree that your aim is not to promote IPE, but I see it is important to mention key applications of IPE. Also, the authors need to compare their contributions compared with their recent paper published in the same journal (Practical Inner Product Encryption with Constant
Private Key, Dec. 2020)
Author Response
We appreciate the reviewer for the valuable comments and encouragement.
We have revised our manuscript according to the reviewer's comment, where the revised parts are colored red in our manuscript. The response to the reviewer's comments are shown in the attached file.
Author Response File: Author Response.pdf
