A Low-Complexity Edward-Curve Point Multiplication Architecture

Round 1

Reviewer 1 Report

This is a very good paper with an interesting selection of topics. The mathematic work is strong and very well versed. Also, the quality of design is compared against earlier techniques which is a decent practice overall. The results show that the design is more efficient as
 compared to the state-of-the-art.

Throughout the paper, it is better to improve the writing, by writing small and composed sentences instead of large sentences which lose their sense. Another thing that is noticed is that a single sentence is referenced against multiple references. Also, the most relevant reference should be cited after the specific sentence. I have the following comments that authors should take into consideration for the first round:

1- Make the figures more clear
2- Discuss more and recent types of low-complexity (area) architecture 
3- Add/compare your work with new and relevant references, from the journal Electronics 

Author Response

The file is attached. 

Author Response File: Author Response.pdf

Reviewer 2 Report

The article addresses ECC, i.e. the improvement of Edward-curve point multiplication architecture in particular. My comments are given below:

1. There are minor style errors:

- "referred to to [14]"

- "1.1. Related work for BEC implementations on FPGAs [15–20]" (references are never inserted into the title)

- "datapath of the crypto processor." (always cryptoprocessor)

- "Recently, the most efficient area optimized architecture is presented" -> reported/proposed sounds better

- "the solution in [20]"-> this solution (avoid repetition!)

- "The use of a bit-serial FF multiplier, as used in" -> use is mentioned twice (avoid repetition)

- "such as RFID cards [21], and digital management systems [22]" -> comma not necessary

- "which require further improvements to throughput while considering the low-complexity (area) and power consumption of the entire architecture" -> in fact, we talk about a trade-off between these 3 parameters (throughput, area, power consumption)

- "and to reduce clock cycles" -> "to" could miss 

- "are initially introduced in [9]. According to the work in [9]," -> repetition!

- "processor.IET (line 430)" -> space needed

- "The Hessian form of an elliptic curve..." (line 435) -> Volume 2162 (!)

- "IEEE Access, 2016, 6(1)" (line 472) -> 2018 (not 2016!)

- "2016, 40, 12" (line 462) -> 1 (not 12)

- ",T4." -> comma should go to the previous line (228)

- "This article has presented a" -> proposes/reports (present sounds better)

etc...

2. For reference [24], a more recent date should be mentioned, maybe that reference is no longer available at this time, the authors are invited to check the validity of this reference and if it is still available now

3. I have found a previous article of the same authors entitled "Hardware design and implementation of ECC based crypto processor for low-area-applications on FPGA" (International Conference on Open Source Systems & Technologies (ICOSST), 2017). I noticed similar research style for both articles, yet the previous one reached 2 ISI citations so it is likely to have low impact in this case too.

4. I think that 4 self-citations is a little bit exaggerated. For instance, the very first reference of this article, published by Kumar, has 0 self citations. You may have a look below:

https://digital-library.theiet.org/content/journals/10.1049/iet-com.2020.0255 

5. Let's study the first introductory section:

" The internet-of-things (IoT) concerns to a global network, where billions of heterogeneous devices are required to connect with an unsecured internet. The connected devices share information (or) data with each other. Since most of the devices in an IoT framework have constrained resources,
data are usually stored in the cloud. Therefore, the users can continuously upload and download data from anywhere using the internet [1]. It arises security concerns as data owners have no control over the data management in a cloud-computing environment. Consequently, the importance of data security and the availability of limited resources for the successful deployment of IoT devices provoke us to explore recent low-complexity cryptographic schemes that can satisfy the memory and power
requirements of the existing IoT applications [2]."

We have 9 lines and only 2 references, not necessary the most interesting. This is not so convincing to the reader. Instead, I have several references, not necessary new, but quite assertive and even well cited in literature. Please have a look below:

Security Requirements for the Internet of Things: A Systematic Approach (MDPI, 2020)
The Internet of Things: a security point of view (Internet Research, Emerald Insight, 2016)
Towards an Analysis of Security Issues, Challenges, and Open Problems in the Internet of Things (IEEE World Congress on Services, 2015)
Challenges to Securing the Internet of Things (IEEE International Carnahan Conference on Security Technology (ICCST), 2016)
A roadmap for security challenges in the Internet of Things (Digital Communications and Networks, 2018)
IoT Ecosystem: A Survey on Devices, Gateways, Operating Systems,
Middleware and Communication (International Journal of Wireless Information Networks, 2020)
Detecting IoT Devices and How They Put Large Heterogeneous Networks at Security Risk (MDPI, 2019)

6. The Abstract of the proposed article gives and demonstrates less valuable info compared with another new article published by Sensors (MDPI), whose abstract is given below:

"With the swift evolution of wireless technologies, the demand for the Internet of Things (IoT) security is rising immensely. Elliptic curve cryptography (ECC) provides an attractive solution to fulfill this demand. In recent years, Edwards curves have gained widespread acceptance in digital signatures and ECC due to their faster group operations and higher resistance against side-channel attacks (SCAs) than that of the Weierstrass form of elliptic curves. In this paper, we propose a high-speed, low-area, simple power analysis (SPA)-resistant field-programmable gate array (FPGA) implementation of ECC processor with unified point addition on a twisted Edwards curve, namely Edwards25519. Efficient hardware architectures for modular multiplication, modular inversion, unified point addition, and elliptic curve point multiplication (ECPM) are proposed. To reduce the computational complexity of ECPM, the ECPM scheme is designed in projective coordinates instead of affine coordinates. The proposed ECC processor performs 256-bit point multiplication over a prime field in 198,715 clock cycles and takes 1.9 ms with a throughput of 134.5 kbps, occupying only 6543 slices on Xilinx Virtex-7 FPGA platform. It supports high-speed public-key generation using fewer hardware resources without compromising the security level, which is a challenging requirement for IoT security." (Design and Implementation of High-Performance ECC Processor with Unified Point Addition on Twisted Edwards Curve, MDPI, 2020)

7. The article proposes a particular figure of merit. Not only that other similar formulas are not mentioned (if existing) but I sense that this formula is not consistent. For instance, the title mentions "Low-complexity", the proposed formula relates throughput and area but no interest is granted to power consumption. And this is how it happens to achieve 266 mW power consumption (quite high!) with a low-complexity architecture. Normally, a low-complexity architecture would decrease the power consunption, not the opposite. It is an obvious contradiction that could make it unattractive for IoT application (where many devices have power consumption constraints). And this is the reason why the Introduction should be written in such a manner that readers could identify which design constraints are the inputs of this design so that they could assess the circuit performances (if implemented). From this perspective, the Introduction is not so clear.

8. The article lacks relevant info about simulations (waveforms, chip area, etc) and experiment (pictures of the setup, real measurements, etc), therefore decreasing the confidence level.

Based on all these comments, I do believe that the proposed article would be more appropriate for a conference.

Author Response

The file is attached. 

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

Compared with the first version, the proposed article proves significant changes and improvements. However, there are several issues left for discussion:

1. Abstract has been improved but the very first phrase sounds strange: "The massive utilization of Internet-of-Things (IoT) is posing some serious security challenges, and therefore, the Elliptic curve cryptography is frequently employed.". Massive + some serious!? How massive and serious are they? It is not the sort of introductory phrase I expect. A more neutral phrase would be "The continuous/growing development of IoT raises new/continous security challenged we need to face, the ECC being a solution in this regard." I encountered so many times this writing style that normally I would reject such article simply because the writing style is not refined. This is a journal, not a tutorial or conference. If written as a tutorial, it could address an IEEE magazine. For instance, I notice several words that sound vague, i.e. massive, serious, major, all three within the same Abstract. They should be avoided (now and in future).

2. What I consider to be a serious error is that the Abstract sounds like an Introduction. Normally, the first 3 phrases should be moved into Introduction, hence it may start with " This article provides/proposes/reports...".

3. I notice that Fig. 4 has been improved, yet two arrows still have an issue over there (1->3, 37->49).

4. I sense a huge space on line 333, i.e. " in subsection 5.3.    Therefore,"

5. There is a strange constrast between "we have", "our solution utilizes 1.9 times higher slices", "our work requires" and "As shown in Table 4, the proposed architecture". Normally, "we" has no place in the scientific style , instead we mention a solution that is reported/proposed so we have to emphasize its capability versus other previous implementations. In addition, there is plenty of comparison between the performances claimed for the proposed architecture and others reported in literature, coming after Table 5. I don't feel it as necessary as long as we have a table already, containing numbers. This is what I meant when mentioning the research style, it is not appropriate to compare our own work with every other solution just to emphasize the unprecedented performances we achieved. 

Based on these remarks, I believe the article still has enough room for changes and improvements. And even though I do not agree with the missing pictures of real time measurements or chip area shown by simulators, I have to increase my overall recommendation because the article looks fine at a first sight. 

Author Response

The file is attached.

Author Response File: Author Response.pdf

Round 3

Reviewer 2 Report

The article has been improved, yet there are other minor issues:

line 2: " due to" -> "thanks to" should replace "due to" (which is normally associated to negative cause)

line 333: "the term slices refer" -> I think "refers" should be used instead of "refer"

line 334: The term, 10^6 in equation -> I think comma is not needed

line 339: "implementation results" sounds strange, maybe "The performances achieved on XILINX ... FPGA device are shown in Table 4."

Lines 340 - 345 : the entire paragraph with table description could be synthesized in one phrase only, otherwise it leaves the feeling that the content is enlarged artificially. It is obvious that the parameters have this significance since hundreds of identical tables are given in literature, there is no different parameter introduced/used in this report.
 
Lines 353-355: the phrase is too long, it can be minimized by simply saying that a fair comparison with state-of-the-art solutions requires/imposes the use of identical implementation device (FPGA) and ECC model.

Line 410: "on vertex-4 device" -> I think it's Virtex

Figure 4: 
-> "If m!=233" attached to the arrow connecting the states 62 and 36 is so closed to State 49 that it becomes unclear to which state is attached;
-> "Start =0" and "Start =1" surpass the graphic, normally text and any graphic elements should be distinct and visible independently;
-> font size is different compared with Figure 3, normally the same font size should be applied to all figures.

Abstract sounds better but it still has some room left to offer some numbers to illustrate the real performances (Virtex devices, number of slices, power consumption, time, new metric proposed/used etc).

Author Response

Please see the attachment.

Author Response File: Author Response.pdf