All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
I am pleased to inform you that your work has now been accepted for publication in PeerJ Computer Science.
Please be advised that you cannot add or remove authors or references post-acceptance, regardless of the reviewers' request(s).
Thank you for submitting your work to this journal. I look forward to your continued contributions on behalf of the Editors of PeerJ Computer Science.
With kind regards,
no comment
no comment
no comment
The paper is well-structured, the methodology is clear, and the experiments effectively demonstrate the advantages of the model. Moreover, the authors have satisfactorily resolved all of my concerns. Therefore, I suggest this
article for publication in its current form.
The reviewers have provided valuable feedback. Please respond to them in detail
no comment
no comment
no comment
The manuscript titled Delegated Multi-party Private Set Intersections from Extendable Output Functions presents a novel protocol for delegated multi-party private set intersections using extendable output functions. The proposed approach shows potential in enhancing the efficiency of private set operations while maintaining privacy. This study contains some interesting findings and makes contributions, and has promising practical applications in the future. However, the paper requires some improvements before it can be considered for publication. The following review provides detailed comments and suggestions for revisions.
1. The non-colluding server assumption is central to the protocol's security. However, its practical challenges and implications are not fully explored. A more in-depth discussion of potential attack vectors and mitigation strategies would be valuable.
2. The transition from the related work section to the proposed protocol is not seamless. For example, after discussing previous protocols, it should be more explicitly stated how the limitations of those protocols led to the design of the new protocol. This could involve highlighting specific shortcomings of existing works and then showing how the proposed protocol addresses those issues.
3. In some parts, the same idea is repeated without adding significant new content. For instance, in the description of the protocol's security features, the same points are made in different paragraphs without further elaboration. This could be condensed to make the paper more concise.
4. In Chapter 2 "RELATED WORK", there is a lack of citations related to multi-party PSI work. This makes the paper insufficiently comprehensive in presenting the research background and existing technological progress, and to some extent weakens the overall integrity and scientific nature of the paper. Additionally, the related work is overly verbose and lacks hierarchical and logical organization. Consider summarizing the key points more concisely and emphasizing the novelty of the work in contrast to the existing literature more prominently.
5. Ensure consistency in the use of terminology throughout the paper. Decide on a preferred term and use it consistently to avoid confusion. For example, the terms "client" and "party" are sometimes used interchangeably. Decide on a preferred term and use it consistently. For example, if "client" is chosen, then use it throughout the paper instead of switching between "client" and "party".
6. While the performance comparison with Feather is presented, a more detailed breakdown of the computational and communication costs at each stage of the protocol is lacking. For example, how much time is spent on XOR operations versus hash function computations? This detailed analysis could help identify bottlenecks and guide future optimizations.
7. The effect of varying parameters other than the number of clients and set size is not thoroughly investigated. For instance, the choice of hash function and the number of hash functions (h) can significantly impact both security and performance. A more comprehensive study of how different hash function choices and values of h affect the protocol would be beneficial.
8. The discussion on the trade-off between performance and information leakage when changing the number of hash functions (h) could be more systematically integrated into the overall logic. Currently, it seems a bit disconnected from the main arguments regarding the protocol design and evaluation.
Minor comments:
1. In Equation 1, the notation could be made more explicit. For example, the meaning of the subscripts and the range of the variables could be clarified to avoid any potential confusion.
2. The use of abbreviations is inconsistent. Some abbreviations, like XOF and MPSI, are defined, but others, such as PRF (Pseudo-Random Function), are used without prior explanation. It would be better to either define all abbreviations when first introduced or use the full terms throughout the paper for clarity.
3. There are a few minor typographical errors in the paper. For example, in some places, there are extra spaces between words or missing commas, which could be corrected for a more polished presentation.
4. In the reference list, some of the journal names are abbreviated inconsistently. Standardize the abbreviations to follow the commonly accepted practices in the field.
5. The visual representation of the proposed scheme could be enhanced by using more explicit legends. This would enable readers to quickly and accurately understand the various components and their functions within the scheme, thereby facilitating a more efficient comprehension of the overall concept and its implications.
The paper is clear and unambiguous. It is well written in good English. However, there are some minor issues/typos that need to be fixed.
At the end of line 24 instead of data it should be date.
In line 57 “… the protocol allows …” it is not completely clear whether this refers to Feather or the proposed protocol, so it should be clarified.
In line 89 “… and bitsets …” the and should be removed, while further in the same line “…, key agreement protocols …” should be “…, and key agreement protocols …”.
In line 208, “As mentioned in Section , …” there is no section specified.
In line 303, “… encoded Bloom filters (see Section ).” No section is specified.
In line 353 “akelWe evaluate …” should be “We evaluate …”
The paper provides a very good background/context and an excellent overview of related work with appropriate and relevant references. However, there is a minor issue that needs to be fixed.
In line 416, it should be “Burkhart, M. and Fontas X. D.”, i.e. F should be capitalised in Fontas.
The articles is well structured and organised with figures and tables excellently presented. However, the data used to produce Figures 2 and 3 are not provided, so the accuracy of the Figures is not possible to assess.
The paper is clearly self-contained and with results in accordance with the paper aims.
Although the paper provides clear definitions and proofs, there is minor omissions that should be fixed. In figure 1 there is reference to Equation 1 but it is not made clear what the value of d is in this case.
The paper presents original primary research that is clearly within the aims and scope of the journal.
The research is well motivated, and although the aim of it is clear, there are no specific research questions provided. It would be useful if the author make clearer what the specific goals/requirements are for the designed protocol.
The research has been rigorously conducted at a high technical standard.
The methods used are well described with sufficient detail provided to allow for replication of the results.
Although the novelty of the proposed protocol is clear, its significance and impact can be articulated more clearly. In particular, when considering the performance of the protocol it will be important to also provide details about the communication costs involved. Evaluating performance in the presence of latency and bandwidth limitations is an interesting approach but should be complemented by the numbers involving the actual message sizes. In addition to this, the discussion on the validity of the non-colluding server setting is good but would have been better to expand the discussion to also consider issues like the information leakage of the proposed protocol, i.e. cardinality of intersection and query party set, and the distribution of set elements in the case of using multiple hash functions, and how it relates to the Feather protocol that is identified as the closest to the proposed one.
The full data used for the production of Figures 2 and 3 have not been provided, so it is difficult to judge whether the presented results are statistically sound. That said it is very good that implementation code is provided, although it looks like there are several issues that need to be addressed before it’s fully useful (i.e. load of TODO comments). It is also excellent that repeated runs have been used to produce controlled performance data.
The conclusions are reasonable and well supported by the evidence provided. However, it would have been better if the information leaked by the proposed protocol was equally emphasised to its performance.
No further comments.
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.