Research on Secure Communication on In-Vehicle Ethernet Based on Post-Quantum Algorithm NTRUEncrypt

Round 1

Reviewer 1 Report

This paper illustrates the advantages of implementing the Post-Quantum Algorithm NTRUEncrypt on the in-vehicle communication. The results look promising, the reviewer has the following comments:

1. In the abstract part: “the execution speed of session 21 key negotiation using NTRUEncrypt is 66.06 times of that using ECDH, and 1530.98 times of that 22 using RSA at the 128-bit security level.” If my understanding is correct, does it need to be the other way around? To show the faster speed of the NTRUEncrypt method.
2. When testing the execution load, does the NTRUEncrypt task is the only task that running on the TC397? In the real world, the throughput of the MCU is usually more than 80% across all the cores. It would be great if the testing cases can cover this scenario.
3. For testing the performance of different algorithms, looks like the NTRUEncrypt algorithm is superior on all dimensions. So is there any drawback of this algorithm that preventing this method to be implemented in the automotive industry?

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

The authors have proposed a NTRUEncrypt enhanced session key negotiation in the in-vehicle Ethernet context. Specifically, the time consumption and memory occupation of the NTRUEncrypt, Elliptic Curve Diffie-Hellman (ECDH) and Rivest-Shamir-Adleman (RSA) algorithms, which are used for session key negotiation, are measured and compared. The topic is interesting and very timely. 

I like to see few additions in the paper. 

1. One is regarding the key size. It is nice to add a table with respective key size of NTRU and other available techniques. 
2. Secondly, energy consumption of the devices as compared to other lightweight variants. 
3. Can this scheme use multiple NTRU public keys for the same private key? Is it secure to apply such scheme? and what major changes it requires in the proposed set-up. 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

In this paper, authors introduce the implementation of NTRUEncrypt algorithm and compared its performance with ECDH and RSA algorithms without any novel idea. Generally, reviewer thinks that this manuscript is not good enough to be published at the current state. Reviewer has several concerns as follows:

1. There are several post-quantum algorithms that entered round 3 of NIST. Authors should explain the advantages of NTRU algorithm that make it become a promising candidate to be used in the in-vehicle communication.
2. The simulation result in Figure 6 shows that with 128-bit key length, the key negotiation time of NTRUEncrypt algorithm is about 66 times faster than that of ECDH algorithm. However, the description in this paper, e.g., lines 22-23, 323-325, makes reader thinks that NTRUEncrypt algorithm requires much more time than that of ECDH and RSA algorithms. Reviewer suggests that writing language and style must be improved.
3. Quality of Figures 5 and 6 should be improved. In Figures 5 and 6, key generation time and key negotiation time of NTRUEncrypt/ECDH are almost overlapped with the horizontal axis.
4. The balance between the processing time and memory occupation should be included. For example, authors can add an additional parameter such as Memory-Time ratio to compare the efficiency of different algorithms.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 3 Report

Authors did not address my concerns.

- As commented in the previous round, authors should use another tools to show the key generation time and key negotiation time of NTRUEncrypt/ECDH more clearly. In addition, Figure 4 is not clear enough and should be updated.

- Authors mentioned that memory occupation is not a crucial impact factor. What is the reason that authors emphasized memory occupation comparison in this paper. It would be better to add a parameter to show the balance between processing time and resource usage.

- For assumptions 1 and 2, authors should either prove the correctness of these assumptions or provide references for evidence.

- Reviewer cannot find the "CPU Cycles" parameter in the Reference 15 as authors provided in Table 2 and Table 3. 

- An extensive editing of English language and style is required.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 3

Reviewer 3 Report

I think authors addressed my concerns. There are some minor things should be fixed:

1) The arrangement error of the title of Figure 4.

2) The title of the first row in Table 2 should be split into rows.

3) There should be a space between a number and its unit, for example 50ms => 50 ms.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf