Hybrid Architecture for Protected Data Communication Inside the Private Cloud
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsThe article presents an ambitious hybrid architecture, but its main weakness is that it tries to solve too many problems at once without fully validating the security implications of each layer. While the authors introduce a custom ARX cipher (KREA v2) and a modified multi‑bit LSB steganography scheme, neither component undergoes the depth of cryptanalysis or modern steganalysis evaluation needed to justify deploying non‑standard primitives in a security‑critical environment. The cipher’s modifications such as altered rotation constants, CRC‑based whitening, and deterministic nonce derivation are motivated by application context but lack rigorous proofs or resistance analysis beyond statistical randomness tests, which are not meaningful indicators of cryptographic strength. Similarly, the MLSB method is evaluated only against outdated chi‑square and RS attacks, ignoring state‑of‑the‑art CNN‑based steganalysis that dominates the field. The end to end MinIO integration is a practical contribution, but the system’s overall security rests on components that have not been subjected to adversarial scrutiny, making the architecture very experimental.
Author Response
We thank the reviewers for the precision and substance of their critiques. Please find the detailed responses in the attached file.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
Comments and Suggestions for AuthorsThank you very much for the invitation from the editor. This paper proposes a hybrid architecture for private cloud environments, combining improved ARX block cipher (KREA v2) and multi bit randomization steganography (MLSB), and implementing end-to-end verification on MinIO object storage. The author has completed a complete experimental loop from encryption to storage and extraction, and provided detailed NIST testing and avalanche effect analysis, but I believe the work is currently in the 'Major Revision' stage. The main innovation of the paper lies in the fine-tuning of SPECK algorithm parameters and the introduction of context bound whitening steps, but the core contribution is more focused on the combination of existing modules and the migration of application scenarios. I noticed that there are obvious fairness issues in the experimental section, and the XOR watermark layer in the steganography section actually increases the risk of RS detection at certain high embedding rates, which requires deeper explanation in terms of logical consistency.
(1) I noticed in section 4.2.1 that you changed the rotation constant of SPECK from (8,3) to (7,2), considering the byte alignment property of the hidden pixel payload. But what I am more concerned about is whether this modification is supported by sufficient mathematical proof, because in the MILP analysis in section 5.7, you also admitted that after 4 rounds, you can only provide the upper limit of the solver rather than proving the optimal value. I suggest you clarify why (7,2) is superior to (8,3) in handling steganographic entropy, or provide more direct theoretical evidence rather than just empirical NIST test results.
(2) Regarding the steganalysis analysis of MLSB, I found that Table 17 shows that XOR watermarking significantly improved the RS detection score at 75% and 100% embedding rates, even skyrocketing from 0.0034 to 0.3333. This means that the watermark layer you designed has had a counterproductive effect in some cases. I suggest that you delve into the root cause of this phenomenon in the discussion section (Section 7) and explore how to avoid the leakage of this specific statistical pattern through adaptive watermark mechanisms.
(3) I noticed that all of your experiments are based on three synthesized images generated by the program (gradients, textures, and blends). The statistical features of composite images are often too regular and cannot fully represent the complex noise environment in reality. I strongly recommend that you introduce standard natural image datasets (such as BOSSBase or COCO) for supplementary experiments to enhance the credibility of steganographic security analysis.
(4) This article discusses privacy protection and security risks in private cloud environments, which are crucial in today's technological development. Please review additional recent related work to enhance the timeliness of the manuscript.
(5) In the Shannon entropy test in section 5.4, you used special plaintext types such as all zeros and all ones. Although the results show an entropy value close to 8.0, I suggest that you add simulation tests with specific statistical features such as video stream header data and XML configuration files, as these are the most common payloads for communication between private cloud services and better reflect input independence in real-world scenarios.
Author Response
We thank the reviewers for the precision and substance of their critiques. Please find the detailed responses in the attached file.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
Comments and Suggestions for AuthorsThe report clearly indicates that the authors have put in the effort to address all the comments that were raised earlier in the first round of reviews. Thanks.
Reviewer 2 Report
Comments and Suggestions for Authorsaccept
