Designing a Scalable and Area-Efficient Hardware Accelerator Supporting Multiple PQC Schemes
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsIn this work, a scalable hardware accelerator for supporting post-quantum cryptographic (PQC) schemes is proposed. The authors propose a single design to simultaneously accelerate multiple PQCs. In my opinion, this work is very well done and very valuable to researchers (and industry practitioners) involved in making computing infrastructure quantum resistant. Some minor comments are as follows:
1. Since this work uses many abbreviations and variables, it would be easier for the reader to follow if the authors introduce a Nomenclature and Abbreviations Section in the manuscript.
2. Please check and include any parameter settings/data for the proposed design - or for the requirements during design developemnt using the design compiler. Additional data could be included in the Appendix. This will help other researchers/engineers reproduce the work.
3. Please include details on the disadvantages/drawbacks/weaknesses/risk of the proposed hardware accelerator. Include your ideas on improving this methodology in future research works.
Author Response
Please see the attachment.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
Comments and Suggestions for AuthorsIf judging the scope of the proposed article then it becomes obvious that it is original since it reports new results achieved for a common implementation of all four PQC finalists ( lines 170-171) , i.e. Kyber, Dilithium, FALCON, and SPHINCS+.
The arguments stated on lines 173-180 are consistent, counting several advantages of implementing such an architecture. However, the article is poorly written because:
1. It is hard to identify both the technical novelty and contribution of the authors with respect to the previous literature. My next remark is also consequence of this one.
2. Even though the first part of this article claims that an architecture supporting all four finalists is reported, a general perspective over the entire design is not disclosed, therefore making the article more difficult to understand. For instance any reader would be interested to find a systematic perspective, i.e. a general block with inputs and outputs , clock input (if necessary), dedicated ports for control signals (or triggers). We only have a so called high-level design given in Figure 3.
3. Based on the information disclosed by the authors, this architecture is not implementing the four finalists simultaneously (meaning that the same architecture could be used for any of these 4 algorithms), making it a switchable architecture (as it is the case of some multistandard wireless transceivers). Therefore, we need control signals to choose which algorithm is to be implemented or set at a certain moment. If so then we need a clearer systematic perspective specifying all triggers , ports and input-output signals. From this perspective this design is NOT complete.
4. The article seems to be a compilation of other solutions reported in literature for optimizing different parameters such as speed, area, throughput and so on. In this regard we can't talk about a clear technical novelty for the proposed design.
5. From my perspective, the article is not ready for being published in a journal because it misses other critical aspects when it comes to cybersecurity:
5.1 the article provides no clue about what happens when implementing all 4 finalists on embedded systems which are devices with constrained resources (i.e. microcontrollers, as currently used by Automotive Industry for ECUs).
5.2 Supposing the case of implementing this idea with switchable architecture, we need statistical data regarding the power consumption for each finalist so that we can identify whether the proposed design leaks valuable information about the system to the attacker. And we still have power glitch, clock glitch, electromagnetic glitch, etc.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 3 Report
Comments and Suggestions for AuthorsThe study's main scientific question is: How can a single hardware accelerator be designed to efficiently support multiple Post-Quantum Cryptosystem schemes, addressing lightweight devices' computational demands and resource constraints while achieving high area efficiency and throughput improvements?
Post-quantum cryptography is currently a hot issue, especially given the threats posed by the development of quantum computers. The proposal of a single universal accelerator for multiple post-quantum cryptography schemes is not only innovative but also has the potential to significantly impact the field by addressing the fundamental problem of efficiency.
Nevertheless, it is worth remembering that any change in the cryptographic implementation may introduce new vulnerabilities. Therefore, it is essential to carefully assess the proposed solution's safety and verify it regularly.
The research is well-focused and offers an innovative approach to supporting multiple post-quantum cryptography schemes with a single accelerator. The authors prepared an appropriate literature review and presented their research in a scientific context. The paper is well written and organised. I suggest considering placing figures and tables on the entire page to improve their readability.
Author Response
Please see the attachment
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
Comments and Suggestions for AuthorsFirst of all, I thank you for this reply and also for the changes processed to the initial article. All changes are welcome. However,
1. Please have a look at a real processor with security features that, to my knowledge, is already integrated into some cars. I don't know which cars and it is also sensitive information so we only stick to its structure given in the datasheet.
https://www.infineon.com/cms/en/product/microcontroller/32-bit-traveo-t2g-arm-cortex-microcontroller/
As it can be noticed in the case of TRAVEO™ T2G 32-bit Automotive MCU, i.e. Block diagram in section 2, there is a single cryptochip implementing AES, SHA and so on. There is no separate accelerator. Indeed, this represents an entire chip, not a SW solution. From this perspective your phrase "Since our design is implemented in physical isolation from the host while providing only fixed interfaces, we believe our accelerator may have the potential to offer security comparable to TrustZone. " is not clear because what intrigues me is what you mean by Host and , in this regard, I think the physical and / or remporal distance between Host and accelerator may be relevant in some cybersecurity cases. In adition, I sense a contradiction between your phrase "which cryptographic operations are isolated from processor as a separate accelerator can provide a safer environment as newly discussed insection 7.2" and the article Crypto-Genome Signature for Securing Hardware Accelerators(https://ieeexplore.ieee.org/document/10039955) which raises questions over the importance of securing accelerators as well.
What I understood from your comment is that , ok, it is a generic article on cryptography and not on cybersecurity which is taken into account as future work. In such a case, which is understandable, please update your article in good agreement with another review: DCryp-Unit: Crypto Hardware Accelerator Unit Design for Elliptic Curve Point Multiplication (IEEE Access, 2024).
According to this article, throughput-to-area ratio is considered a good measure to compare the performances of crypto accelerators and, indeed, is seen as a FOM in Table.1 Therefore, no matter how many algorithms are implemented by your proposed architecture I do believe that a fair comparison with other articles or solutions, you should use this FOM. This would give confidence to the readers and also would set a preliminary FOM so that other researchers would have a starting point for their research and comparison. Please update the list of references consequently!
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 3
Reviewer 2 Report
Comments and Suggestions for AuthorsThe authors did the best to update the article so it answers to all my comments hence I believe the proposed article has a better form now.
