Performance Evaluation of Lightweight Cryptographic Algorithms for End-to-End Secure IoT Data Transmission over 5G Standalone

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

1. There is a significant discrepancy in the reported performance metrics. The Abstract and Figure 9 report a decryption time of 456 μs, while other sections of the manuscript (and typical validation sections) refer to 270 μs (0.27ms), shown in Figure 6. Such contradictions in core data suggest a lack of rigorous data verification.
2. The study compares encryption performed on a Raspberry Pi 4B with decryption performed on a Multi-access Edge Computing (MEC) server. Attributing the lower decryption time to the algorithm's efficiency is a logical error; the performance gain is likely due to the vastly superior processing power of the MEC server compared to the IoT node. Benchmarking must be performed on identical hardware to be valid.
3. The manuscript claims a total power consumption of 0.40 watts. This is physically impossible for the hardware stack described, which includes a Raspberry Pi 4B (typically idling at 2.5W–3W) and a Quectel FG50V 5G module. Furthermore, the methodology for measuring this power consumption is entirely missing from the experimental setup.
4. The paper benchmarks Elliptic Curve Cryptography (ECC) directly against symmetric stream ciphers like RC4 and ChaCha20 for bulk sensor data encryption. ECC is an asymmetric protocol intended for key exchange or digital signatures, not for encrypting raw JSON sensor packets. Comparing its latency to symmetric ciphers is technically inappropriate.
5. The authors motivate their work by stating that simulations fail to capture "real 5G features" like GTP-U tunneling overhead. This is factually incorrect; standard network simulators such as NS-3 provide high-fidelity models of the 5G protocol stack, including GTP-U headers and tunneling overhead.
6. The manuscript introduces non-standard terms like "Opaque Flow Effect" and "optimistic elucidations" to describe perceived research gaps. Using a web dashboard to "solve" a cryptographic "transparency" issue is not a valid scientific contribution and mischaracterizes the nature of end-to-end security.
7. Theorem 2 and its subsequent "Proof" are largely descriptive and lack rigorous mathematical derivation. Asserting that a function is secure because it is "non-affine" or has a "flattened Walsh spectrum" without providing the actual calculated bounds for the proposed quadratic function f(k) = k2 + 3k + 7 is insufficient for a cryptographic proposal.
8. Algorithm 1 lists a "Device count M" as a requirement, yet this variable is never utilized in the algorithm's steps. Such oversights in algorithm pseudocode raise concerns about the actual implementation used during testing.
9. For any modified cryptographic algorithm (RC4-NL), standard statistical testing is mandatory. The paper fails to include results from recognized suites such as NIST SP 800-22 or Dieharder, which are essential to prove that the modifications did not introduce new biases or reduce the keystream period.

Author Response

Dear Editor and Reviewers,

We sincerely thank the Editor and the reviewers for their time, effort, and insightful comments, which have greatly helped improve the quality of our manuscript.  We submit the revised version of our paper to the Journal where all the major changes are highlighted in RED color text. We have carefully addressed all the comments and provided detailed, point-by-point responses below:

Rev#1

Comments and Suggestions for Authors

1. There is a significant discrepancy in the reported performance metrics. The Abstract and Figure 9 report a decryption time of 456 μs, while other sections of the manuscript (and typical validation sections) refer to 270 μs (0.27ms), shown in Figure 6. Such contradictions in core data suggest a lack of rigorous data verification.

Thank you for your valuable comment. The value of 270 μs (0.27 ms) shown in Figure 6 (page 17) corresponds to the instantaneous decryption time measured for a single packet during real-time execution in the 5G IoT testbed, as output on the MEC server. But, the value of 456 μs reported in abstract in page 1, Figure 10 in page 20, and Table 2 in Page 33 represents the average decryption time computed over multiple transmissions.

2.The study compares encryption performed on a Raspberry Pi 4B with decryption performed on a Multi-access Edge Computing (MEC) server. Attributing the lower decryption time to the algorithm's efficiency is a logical error; the performance gain is likely due to the vastly superior processing power of the MEC server compared to the IoT node. Benchmarking must be performed on identical hardware to be valid.

Thank you for your valuable comment. The contribution is not towards 'Decryption algorithm is faster” .End-to-end latency is reduced by offloading computationally intensive decryption to MEC. The study does not aim to compare encryption and decryption performance under identical hardware conditions. The proposed framework is designed to evaluate a realistic 5G IoT deployment scenario where resource-constrained IoT devices perform lightweight encryption, while computationally intensive decryption is offloaded to a Multi-accessEdge Computing (MEC) server to minimize end-to-end latency.

3.The manuscript claims a total power consumption of 0.40 watts. This is physically impossible for the hardware stack described, which includes a Raspberry Pi 4B (typically idling at 2.5W–3W) and a Quectel FG50V 5G module. Furthermore, the methodology for measuring this power consumption is entirely missing from the experimental setup.

Thank you for your valuable comment. The reported 0.40 W corresponds to the incremental power overhead of the proposed algorithm measured relative to the idle baseline of the system. The initially reported value of 0.40 W does not represent total system power consumption. Instead, it corresponds to the incremental power overhead of the proposed edge-processing module, measured relative to the baseline power consumption of the Raspberry Pi 4B-based setup (without cryptographic processing) is approximately 2.8W, which is consistent with typical operating conditions. All measurements were conducted on identical hardware under controlled conditions to ensure consistency and fairness. Attached is the usb voltmeter-ammeter measurement device used to measure the readings.

4.The paper benchmarks Elliptic Curve Cryptography (ECC) directly against symmetric stream ciphers like RC4 and ChaCha20 for bulk sensor data encryption. ECC is an asymmetric protocol intended for key exchange or digital signatures, not for encrypting raw JSON sensor packets. Comparing its latency to symmetric ciphers is technically inappropriate.

Thank you for your valuable comment.The manuscript is revised to remove such comparisons in section 4.3 from Figure 9 to Figure 15 Page No 20-24, and in section 4.5Figure 19 to 30, Page No 26 to Page No 32.

5.The authors motivate their work by stating that simulations fail to capture "real 5G features" like GTP-U tunneling overhead. This is factually incorrect; standard network simulators such as NS-3 provide high-fidelity models of the 5G protocol stack, including GTP-U headers and tunneling overhead.

Thank you for your valuable comment. The Inclusion of standard statistical test suites (NIST SP) is included in section 4.4 (page no 24) with Figure 16, Figure 17 and Figure 18.

6.The manuscript introduces non-standard terms like "Opaque FlowEffect" and "optimistic elucidations" to describe perceived research gaps. Using a web dashboard to "solve" a cryptographic "transparency" issue is not a valid scientific contribution and mischaracterizes the nature of end-to-end security.

Thank you for the valuable suggestion.

The proposed web-based dashboard is not intended as a cryptographic solution, nor does it claim to enhance cryptographic security properties such as confidentiality or integrity.Instead, its role is to provide evaluation of performance across the 5G IoT pipeline.

7.Theorem 2 and its subsequent "Proof" are largely descriptive and lack rigorous mathematical derivation. Asserting that a function is secure because it is "non-affine" or has a "flattened Walsh spectrum" without providing the actual calculated bounds for the proposed quadratic function f(k) = k2 + 3k + 7 is insufficient for a cryptographic proposal.

Thank you for your valuable comment. Theorem 2 is corrected to meet cryptographic publication standards in section 3.2 Page no 13.

8.Algorithm 1 lists a "Device count M" as a requirement, yet this variable is never utilized in the algorithm's steps. Such oversights in algorithm pseudocode raise concerns about the actual implementation used during testing.

Thank you for your valuable comment.The revised manuscript, the unused parameter is removed from Algorithm 1 in Page 10 and carefully reviewed the pseudocode to ensure consistency between the algorithm description and the actual implementation used during experiments.

9.For any modified cryptographic algorithm (RC4-NL), standard statistical testing is mandatory. The paper fails to include results from recognized suites such as NIST SP 800-22 or Dieharder, which are essential to prove that the modifications did not introduce new biases or reduce the keystream period.

Thank you for your valuable comment. The Inclusion of standard statistical test suites (NIST SP) is included in section 4.4 (page no 24) with Figure 16, Figure 17 and Figure 18. 

 

Reviewer 2 Report

Comments and Suggestions for Authors

Dear authors, 

congratulations on your paper regarding the performance evaluation of cryptographic algorithms for end-to-end secure IoT data transmission. Your work is well structured and gives an insight on this matter, while evaluating the different algorithms used.

In order to improve your paper I would suggest:

-for the hardware setup section please include a circuit scheme specifying the components and their connection

-from where did you get your environmental data? here is a picture of a room, but you have a soil moisture probe

-which are the parameters that affect the readings of the sensors or the data transmission

-make Figures 12 and 13 bigger

-specify more clearly in the conclusions which are the modification of the RC4-NL made by you

-maybe a table with a comparison between the cryptographic algorithms should help to better understand the fact that your algorithm is better

 

Author Response

Dear Editor and Reviewers,

We sincerely thank the Editor and the reviewers for their time, effort, and insightful comments, which have greatly helped improve the quality of our manuscript.  We submit the revised version of our paper to the Journal where all the major changes are highlighted in RED color text. We have carefully addressed all the comments and provided detailed, point-by-point responses below:

Rev#2

for the hardware setup section please include a circuit scheme specifying the components and their connection

Thank you for the valuable comment. A detailed circuit scheme of the hardware setup is included in manuscript with Figure 3b to illustrate the component-level connections, with the corresponding description in the Hardware Setup section 4.1 Page No 14 to clearly explain the sensor interfacing and GPIO connections.

-from where did you get your environmental data? here is a picture of a room, but you have a soil moisture probe

Thank you for the valuable comment. The environmental data is obtained from real-time IoT sensing setup deployed using the Raspberry Pi 4 Model B. The sensor node acquires actual soil moisture readings from a physical soil environment along with temperature and humidity measurements. The figure presented in the manuscript is a representational room-level experimental setup, used for illustration of the system architecture and component placement.

-which are the parameters that affect the readings of the sensors or the data transmission

Thank you for the valuable comment. The Sensor readings are influenced by environmental conditions and sensor characteristics, while data transmission performance is affected by network conditions such as signal strength, interference, and scheduling delays.

-make Figures 12 and 13 bigger

Thank you for the valuable suggestion. As per the comment, the size of the Figures 12 and 13 are increased.

-specify more clearly in the conclusions which are the modification of the RC4-NL made by you

Thank you for the valuable comment. The modification of the RC4-NL is explained in the conclusion section 6,Page No 36.

-maybe a table with a comparison between the cryptographic algorithms should help to better understand the fact that your algorithm is better.

Thank you for the valuable suggestion. As per the given suggestion, Table 4 is provided for comparing the cryptographic algorithms in section 4.5, Page No 34.

Reviewer 3 Report

Comments and Suggestions for Authors

The article presents a comprehensive experimental study on lightweight cryptographic algorithms within a real-world 5G-enabled IoT environment, addressing a significant gap in prior literature that relies heavily on simulation-based evaluations. The authors propose a fully integrated end-to-end 5G IoT testbed and introduce a modified stream cipher, RC4-NL, aimed at improving the security weaknesses of standard RC4 while maintaining computational efficiency.

The article uses real-world 5G standalone testbed, which makes the results more reliable than simulation-based studies. It presents a complete end-to-end system, from data collection to visualization, ensuring practical relevance. The paper also provides a comprehensive comparison of multiple cryptographic algorithms under identical conditions. Its introduction of the RC4-NL algorithm shows innovation in improving efficiency and security trade-offs. The inclusion of both experimental results and theoretical analysis strengthens the credibility of the work.

On the other hand I see several major problems and weaknesses, which should be addressed:

1. Limited Security Evaluation

The paper focuses more on performance than rigorous security validation, with only partial theoretical analysis and no comprehensive cryptanalysis. The authors should include formal security proofs or empirical testing (e.g., NIST randomness tests, attack simulations) to strengthen the security claims.

2. Use of RC4-Based Design

Building on RC4, which is widely considered insecure, limits the novelty and practical adoption of the proposed RC4-NL algorithm. The authors should better justify this choice or compare their approach more deeply with modern standardized algorithms like Ascon.

3. Lack of Authentication and Integrity Mechanisms

The system ensures confidentiality but does not address authentication or data integrity, leaving it vulnerable to active attacks. The authors should integrate authenticated encryption (AEAD) or key exchange mechanisms to provide complete security guarantees.

4. Limited Scalability Evaluation

The experiments are conducted with a single device and controlled conditions, which does not reflect large-scale IoT deployments. The authors should extend the evaluation to multiple devices and higher traffic scenarios to demonstrate scalability.

5. Overemphasis on Latency Metrics

The study prioritizes latency and efficiency while underexploring the trade-off with security robustness. The authors should provide a more balanced discussion comparing performance gains with actual security strength.

6. Insufficient Comparison with State-of-the-Art

Although several algorithms are tested, the comparison lacks deeper analysis against current state-of-the-art lightweight cryptographic standards. The authors should include more critical discussion on why their approach is preferable beyond raw performance metrics.

7. Writing and Presentation Issues

The paper contains repetitive phrasing, grammatical inconsistencies, and overly long explanations that reduce clarity. The authors should revise the manuscript for conciseness, improve language quality, and streamline technical descriptions.

Comments on the Quality of English Language

The quality of English is generally understandable but requires improvement for clarity and readability. Several sentences are overly long, repetitive, or grammatically inconsistent, which can make some sections difficult to follow. The authors should revise the manuscript for conciseness, correct grammatical errors, and improve overall flow to ensure the research is communicated more effectively.

Author Response

Dear Editor and Reviewers,

We sincerely thank the Editor and the reviewers for their time, effort, and insightful comments, which have greatly helped improve the quality of our manuscript.  We submit the revised version of our paper to the Journal where all the major changes are highlighted in RED color text. We have carefully addressed all the comments and provided detailed, point-by-point responses below:

REV#3

1. Limited Security Evaluation

The paper focuses more on performance than rigorous security validation, with only partial theoretical analysis and no comprehensive cryptanalysis. The authors should include formal security proofs or empirical testing (e.g., NIST randomness tests, attack simulations) to strengthen the security claims.

Thank you for your valuable comment. The standard statistical test suites (NIST SP) are included in section 4.4 (page no 25) with Figure 16, Figure 17 and Figure 18. 

2. Use of RC4-Based Design

Building on RC4, which is widely considered insecure, limits the novelty and practical adoption of the proposed RC4-NL algorithm. The authors should better justify this choice or compare their approach more deeply with modern standardized algorithms like Ascon.

Thank you for this valuable comment. The manuscript is revised to clarify the motivation for including RC4. The practical adoption of the proposed RC4-NL algorithm is explained in Page No 11 in section 3.2.

3. Lack of Authentication and Integrity Mechanisms

The system ensures confidentiality but does not address authentication or data integrity, leaving it vulnerable to active attacks. The authors should integrate authenticated encryption (AEAD) or key exchange mechanisms to provide complete security guarantees.

Thank you for this valuable comment. In the present work, the main objective is to evaluate cryptographic algorithms under real 5G IoT. The integration of authenticated encryption schemes such as Ascon and ChaCha20-Poly1305, along with Elliptic Curve Cryptography-based key exchange will be considered in future work to provide confidentiality, integrity, and protection against active attacks.

4. Limited Scalability Evaluation

The experiments are conducted with a single device and controlled conditions, which does not reflect large-scale IoT deployments. The authors should extend the evaluation to multiple devices and higher traffic scenarios to demonstrate scalability.

Thank you for this important suggestion. The current evaluation is conducted using a single IoT device under controlled conditions. To address scalability, the Future Scope section in page no 36 is extended to include multi-device and high-traffic evaluation scenarios.

5. Overemphasis on Latency Metrics

The study prioritizes latency and efficiency while underexploring the trade-off with security robustness. The authors should provide a more balanced discussion comparing performance gains with actual security strength.

Thank you for the valuable comment. As per the comment, cryptographic security analysis metrics including Avalanche Effect, Entropy and correlation are added in section 4.5 along with corresponding graphical evaluations in Figures 28,29 and 30 in Page No 31 to Page No 32.

6. Insufficient Comparison with State-of-the-Art

Although several algorithms are tested, the comparison lacks deeper analysis against current state-of-the-art lightweight cryptographic standards. The authors should include more critical discussion on why their approach is preferable beyond raw performance metrics.

Thank you for your valuable comment. The manuscript is revised to include additional system-level performance indicators, namely throughput, energy consumption, and scalability index to provide a more comprehensive and critical evaluation beyond latency and basic performance metrics in Table 3 in section 4.5 Page No 33.

7. Writing and Presentation Issues

The paper contains repetitive phrasing, grammatical inconsistencies, and overly long explanations that reduce clarity. The authors should revise the manuscript for conciseness, improve language quality, and streamline technical descriptions.

Thank you for the valuable comment. The manuscript is thoroughly revised to improve clarity, conciseness, and overall language quality.

Comments on the Quality of English Language

The quality of English is generally understandable but requires improvement for clarity and readability. Several sentences are overly long, repetitive, or grammatically inconsistent, which can make some sections difficult to follow. The authors should revise the manuscript for conciseness, correct grammatical errors, and improve overall flow to ensure the research is communicated more effectively.

Thank you for the valuable feedback. The manuscript is carefully revised to improve language clarity, grammatical accuracy, and overall readability.

 

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

recommend accepting this paper because the authors have successfully transformed a performance-heavy study into a scientifically rigorous cryptographic evaluation. By integrating the NIST Statistical Test Suite and formal metrics like the Avalanche Effect, they have provided the empirical validation necessary to justify the proposed RC4-NL algorithm. Furthermore, the expanded analysis of system-level metrics—such as energy consumption and throughput—ensures the research is directly applicable to the practical constraints of 5G Standalone IoT environments.