Research on Encryption and Decryption Technology of Microservice Communication Based on Block Cipher

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

1.  How does the proposed framework ensure that concurrent threads maintain ciphertext integrity and prevent partial write conflicts during the data fusion phase?

2. Have the authors measured how performance scales beyond two threads or across multiple containers? What is the theoretical or observed parallel efficiency?

3. How are cryptographic keys distributed, reused, or synchronized among threads? Is there a centralized key manager or per-thread key generation policy?

4. Have the authors performed entropy, avalanche, or differential analysis to empirically validate that parallelization does not reduce cryptographic diffusion?

5. The paper infers that larger ciphertext sizes imply stronger security. Could the authors justify this assumption or provide a more accurate metric, such as Shannon entropy or key space complexity?

6. Did the authors evaluate energy efficiency, CPU utilization, or memory footprint under sustained multi-threaded loads?

7. How can this framework integrate into existing microservice security stacks (e.g., mutual TLS or service mesh encryption layers)? What is the practical deployment model?

8. If a thread or container fails mid-encryption, how does the framework handle state rollback or partial encryption artifacts?

9. How is plaintext segmentation determined (equal split vs. dynamic scheduling)? Could an adaptive scheduler further optimize throughput?

10. Why were ChaCha20 or AES-GCM excluded, given their relevance to cloud systems? Would the authors consider testing authenticated encryption performance in future work?

Author Response

Thank you very much for the reviewer 's comments. We have responded and modified.

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

1. In Section 4.6, the authors state that larger ciphertexts suggest stronger security, implying SM4 is more secure. This is incorrect; ciphertext size due to padding or operation mode affects efficiency, not strength. True strength depends on key size, design, and attack resistance.
2. The authors describe the "Parallel Dense Chain Multithreading Collaborative Processing Framework" in general terms in Section 3.2. However, they do not provide important technical details, such as thread pooling, context switching, and synchronization methods.
3. The parallel approach appears to be a simple use of threads to process split data chunks. The authors do not clearly explain why this approach is new, especially in relation to existing container capabilities.
4. The experiments rely on randomly generated bit streams. While this approach is acceptable for testing throughput, it does not accurately reflect real-world microservice payloads, such as JSON, XML, or Protobuf. These formats have specific structures that can influence processing, especially if serialization and deserialization are part of the "communication" aspect mentioned.
5. In the introduction, the cloud/IoT data volume was discussed, and in Section 2.5, Containerization and Microservices are addressed. It is suggested to refer from the paper: "Privacy-Preserving Decision Tree Classification Using Homomorphic Encryption in IoT Big Data Scenarios." The paper discusses "Machine Learning as a Service" (MLaaS) in IoT and cloud environments, with a focus on privacy. It aligns with the manuscript's goal of securing microservice communication and extends "cloud security" to include privacy-preserving methods beyond encryption speed, considering the broader microservice context.
6. The results are presented in straightforward comparisons without confidence intervals or statistical significance tests. This makes it hard to evaluate the reliability of the "50% reduction" claim.
7. The authors need to remove the statement in Section 4.6 that equates ciphertext size with security. Instead, they should discuss the actual security features of SM4, such as its 128-bit block size and resistance to attacks, in comparison to the weaker DES and the stronger AES.
8. Section 3.2 needs much more technical information. The authors should include pseudocode or a flow diagram that clearly illustrates how threads are managed, how data is divided (is it simply chunked?), and how they prevent race conditions.

Author Response

Thank you very much for your comments. We have responded and modified.

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I don't any further questions to the authors.