A privacy-preserving cloud storage framework with hybrid encryption, homomorphic keyword search, and blockchain-based integrity verification.

A privacy-preserving cloud storage framework with hybrid encryption, homomorphic keyword search, and blockchain-based integrity verification - PMC Skip to main content An official website of the United States government Here's how you know Here's how you know Search Log in Primary site navigation Search Log in Search PMC Full-Text Archive Search in PMC Journal List User Guide As a library, NLM provides access to scientific literature. Inclusion in an NLM database does not imply endorsement of, or agreement with, the contents by NLM or the National Institutes of Health. Learn more: PMC Disclaimer | PMC Copyright Notice Sci Rep . 2026 Apr 16;16:16697. doi: 10.1038/s41598-026-48705-x A privacy-preserving cloud storage framework with hybrid encryption, homomorphic keyword search, and blockchain-based integrity verification Haitham M A Ahmed 1 , Swaleha Zubair 1 , Mohammed Tawfik 2, ✉ Author information Article notes Copyright and License information 1 Department of Computer Science, Aligarh Muslim University, Aligarh, India 2 Faculty of Computer and Information Technology, Sana’a University, Sana’a, Yemen ✉ Corresponding author. Received 2026 Feb 25; Accepted 2026 Apr 9; Collection date 2026. © The Author(s) 2026 Open Access This article is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/ . PMC Copyright notice PMCID: PMC13221446  PMID: 41992049 Abstract Cloud storage outsourcing introduces critical privacy risks as Cloud Service Providers (CSPs) can access unencrypted user data, while encryption eliminates essential functionality such as searchability and remote integrity verification. Existing solutions face a trilemma: fully homomorphic encryption (FHE) remains impractical with seconds-per-operation overhead, searchable encryption leaks access patterns exploitable through inference attacks, and blockchain-based auditing schemes using public chains suffer from low throughput (7–15 TPS), high costs ($1–50 per transaction), and pseudonymous-but-traceable privacy. We present a privacy-preserving cloud storage framework that synergistically combines hybrid AES-ECC encryption for data confidentiality with HMAC-based authentication, Paillier homomorphic encryption (PHE) for probabilistic keyword encryption, and Ethereum-based smart contracts for decentralized integrity verification. Our hybrid protocol achieves IND-CPA security for bulk encryption with authenticated integrity through HMAC-SHA256, delivering 245.7ms encryption time for 1MB files and 7.3% storage overhead—21.2% faster than comparable systems. The Paillier-based keyword encryption prevents frequency analysis through probabilistic ciphertext generation, with search operations over 100 encrypted files completing in 847ms under the Decisional Composite Residuosity assumption. Leveraging Ethereum smart contracts with dynamic third-party auditor selection, our system achieves 287ms consensus latency on the Ganache test network with empirical collusion resistance measurements ( , consistent with hypergeometric model predictions). The distributed architecture demonstrates 85 TPS per group throughput while maintaining O ( n ) encryption complexity and O (1) blockchain operations validated through empirical log-log regression ( ) across file sizes from 1KB to 32KB, establishing feasibility for consortium-based privacy-critical cloud deployments. Production deployment on permissioned blockchain networks such as Hyperledger Fabric would provide additional privacy features including transaction unlinkability through identity management. Keywords: Cloud storage security, Privacy-preserving encryption, Homomorphic encryption, Searchable encryption, blockchain, Ethereum smart contracts, Data integrity, Access control Subject terms: Engineering, Mathematics and computing Introduction Cloud storage has become ubiquitous, with over 60% of enterprise workloads now running in public clouds. However, this paradigm introduces critical privacy risks: users lose direct control over their data, Cloud Service Providers (CSPs) can access unencrypted content, and centralized architectures create single points of failure 1 . The 2019 Capital One breach exposed 106 million customer records through misconfigured cloud storage, demonstrating that trusting CSPs with plaintext data is fundamentally insecure. Encryption provides confidentiality but eliminates essential cloud functionality. Users cannot search encrypted files, verify integrity remotely, or share data selectively without decryption. Existing cryptographic solutions face an unresolved trilemma. Fully Homomorphic Encryption (FHE) 2 enables arbitrary computation on ciphertext but remains impractical with seconds-per-operation overhead despite years of optimization. Searchable Encryption 3 supports keyword queries but leaks access patterns exploitable through inference attacks 4 . Traditional integrity auditing schemes 5 , 6 require trusted third-party auditors (TPAs), introducing centralization vulnerabilities. Blockchain technology offers decentralized trust establishment through distributed consensus. Recent works 7 , 8 have explored blockchain-based cloud auditing, yet face critical limitations. Public blockchains (Bitcoin, Ethereum) provide strong decentralization but suffer from low throughput (7-15 TPS), high latency (10+ minutes), expensive transactions ($1-50 per operation), and pseudonymous-but-traceable privacy. Private blockchains improve efficiency but reintroduce centralization. Most critically, existing schemes store file hashes on-chain but cannot search encrypted metadata without leaking patterns. This paper presents a privacy-preserving cloud storage framework combining hybrid AES-ECC encryption with HMAC authentication for data confidentiality, Paillier Homomorphic Encryption (PHE) for probabilistic keyword encryption, and Ethereum smart contracts for decentralized integrity verification. Our hybrid cryptographic protocol integrates AES-256-CBC with HMAC-SHA256, ECIES on brainpoolP256r1, and Paillier encryption, achieving 245.7ms encryption time for 1MB files with 7.3% overhead-21.2% faster than comparable schemes 9 , 10 while maintaining IND-CPA security with authenticated integrity. The Paillier-based keyword encryption prevents pattern leakage through probabilistic ciphertext generation, with search operations over 100 encrypted files completing in 847ms. Ethereum smart contract integration with dynamic TPA selection achieves 287ms consensus latency on the Ganache development network and 85 TPS per group throughput, with empirical collusion resistance measurement ( ) consistent with hypergeometric model predictions. The framework is designed for migration to permissioned blockchain networks such as Hyperledger Fabric, which would provide consortium-level identity management and transaction unlinkability. Comprehensive empirical validation confirms O ( n ) encryption complexity and O (1) blockchain operations through log-log regression ( ). The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 describes the proposed method including system architecture and cryptographic protocols. Section 4 presents experimental results and performance evaluation. Section 5 discusses security properties, scalability, and limitations. Section 6 concludes the paper. Related work The proliferation of cloud computing has intensified the tension between operational efficiency and data sovereignty, catalyzing research into cryptographic frameworks that preserve confidentiality, integrity, and availability. This section critically examines recent advances across five research trajectories: blockchain-based integrity verification, hybrid encryption architectures, lightweight AES variants, homomorphic computation, and access control mechanisms, while identifying methodological gaps and unresolved challenges. Blockchain-based integrity verification The migration from centralized Third-Party Auditor (TPA) architectures to blockchain-distributed verification represents a paradigm shift in cloud data integrity assurance. Lu et al. 11 pioneered this transition with HF-Audit, a Hyperledger Fabric-based framework that eliminates single-point TPA dependency through dynamic auditor selection. Their system leverages bilinear-pairing Provable Data Possession (PDP) tags combined with Pedersen-style commitments to remove per-audit data transfer. The dual-proof verification equation enables lightweight validation while maintaining security under the Computational Diffie-Hellman (CDH) assumption. Performance evaluation on an Intel i5-4210M processor demonstrates linear cost scaling with block count n ( ms per 1,000 blocks), while on-chain audit latency remains constant at s for up to 1,000 blocks, dominated by Fabric-Kafka consensus rather than cryptographic operations. The collusion-resistance probability derived from hypergeometric modeling provides quantitative security guarantees. However, their TPA-selection algorithms-weighted Euclidean under complete information and Pearson correlation coefficient (PCC)-based collaborative filtering-were validated only on QWS-2 (507 Web-service QoS records) and WS-DREAM (142-user 4,500-service matrix) synthetic datasets, raising concerns about generalizability to heterogeneous cloud federations with incomplete trust profiles. Liu et al. 7 extended blockchain integrity verification to IoT environments through a fully decentralized Ethereum-based Data Integrity Service (DIS). Their architecture deploys three smart contracts-DISSC (Data Integrity Service Smart Contract), OCASC (Owner and Consumer Authentication Smart Contract), and ASC (Access Control Smart Contract)-to orchestrate hash registration, challenge-response protocols, and fine-grained access control. The framework implements four integrity-verification protocols adapting PDP/PoR sampling to cryptographically enabled (CSS-Y) versus legacy (CSS-N) cloud storage. Hashes are locally generated with SHA-256, AES-encrypted client-side, and anchored on-chain, while bulk data reside off-chain in IPFS or Amazon S3-like object stores. Prototype evaluation on a 4-node testbed-Raspberry Pi 2 (DOA), PC (dual DOA/DCA roles), private server (CSP/miner), and public cloud (DCA)-demonstrates 9.6 s hash-writing latency on Pi-2 versus 7 s on PC for 780 kB blocks, with 31 MB IPFS retrieval completing within 25 s. Security quantification relies on 100% challenge-response success rate for uncorrupted blocks and gas-cost profiling ( USD per 10,000 hash writes). The critical limitation is exclusive reliance on binary hash match/mismatch verification without Byzantine fault tolerance mechanisms, rendering the system vulnerable to strategic partial-corruption attacks where adversaries selectively tamper with data synchronized with on-chain hashes. Yeboah-Ofori et al. 8 addressed the integration gap between encryption and blockchain provenance by synergizing AES-256-CBC with Ethereum smart contracts and AWS S3. Their framework immutably records ciphertext hash, key-hash, storage location, owner identity, timestamp, user ID, and access permissions on-chain while maintaining encrypted payloads off-chain. Implementation in Python/PyCryptodome with Solidity contracts (Remix IDE, k gas) demonstrates linear encryption/decryption latency scaling ( s for 5 MB on 2.6 GHz Intel Core i7) and sub-second metadata retrieval. Security validation confirms AES entropy passing NIST Statistical Test Suite (STS) randomness tests, ciphertext avalanche effect , blockchain immutability verified through 100 consecutive log entries with zero hash mismatch, and S3 bucket access-control misconfiguration scans returning zero exposed objects. However, the framework exposes scalability bottlenecks- ETH per transaction and 15-second average confirmation latency become prohibitive for high-velocity IoT streams generating thousands of events per second. Shakor et al. 12 innovated dynamic key management by generating unique 256-bit AES keys per file via , yielding dynamic key streams that change even for identical plaintexts. Each key is encapsulated in a private Ethereum-style blockchain block, asymmetrically encrypted with the owner’s ECC public key (secp256k1 parameters) before cloud upload. Information-theoretic evaluation on synthetic text and standard grayscale images (Cameraman, Lena) demonstrates average entropy of 7.997 bits/pixel (near-ideal 8), bit-density/sensitivity of 59.04% versus 51.46% in prior memristive AES schemes, histogram uniformity with p -value , and avalanche factor . Security guarantees include key-guessing resistance and NPCR/UACI-style key sensitivity exceeding 60%. The critical trade-off is 1.8 encryption-time overhead relative to static AES-256, and the secp256k1 elliptic curve remains vulnerable to Shor’s quantum algorithm, necessitating post-quantum migration. Critical Assessment: Blockchain-integrity research universally optimizes tamper-detection latency and storage overhead but neglects adaptive adversary models exploiting consensus delays or selectively corrupting off-chain data synchronized with on-chain hashes. The predominance of synthetic datasets and controlled testbeds limits ecological validity-no study benchmarks performance under network partitions, Byzantine consensus failures, or cross-chain interoperability scenarios. Hybrid encryption architectures Hybrid cryptosystems coupling symmetric bulk encryption with asymmetric key management have emerged as the standard for resource-constrained cloud-IoT ecosystems. Chen et al. 9 introduced HAE (Hybrid AES-ECC), synergizing AES-128 bulk encryption with ECC-256 lightweight asymmetric protection of session keys over the secp256r1 curve. Implementation in Java/Go on VMware-Ubuntu (Intel i7-10750H, 16 GB) integrated with Hyperledger Fabric and IPFS demonstrates 12–18% faster encryption/decryption than AES-RSA and 3.2 lower latency than pure ECC across synthetic electronic health records of 1, 5, 10, 15, and 20 MB. CPU utilization remains 6–8 percentage points lower than baselines. The HAE pipeline first expands a 128-bit random seed into a full AES key schedule, encrypts plaintext with AES/CBC/PKCS5, then encrypts the seed with ECC over secp256r1. Cryptanalysis confirms brute-force complexity for AES and for ECC, with ciphertext integrity verified through IPFS content-hashes immutably logged on Fabric. However, the reliance on CBC mode without authenticated encryption exposes the scheme to padding-oracle attacks-a vulnerability not empirically evaluated despite documented exploits in TLS and other protocols. Popoola et al. 10 rectified this deficiency by adopting ECC-256r1 for asymmetric key exchange and digital signatures coupled with AES-128 in EAX mode for authenticated symmetric bulk encryption. Their optimized framework for smart-home healthcare emulates a real network with Raspberry Pi 4B client (1.5 GHz, 4 GB RAM, Enviro+ sensors, Galaxy Watch 4) and Ubuntu 21.04 cloud server (Intel i7-9700K, 16 GB RAM). Extensive performance counters-processing time, CPU%, RAM%, energy draw, bandwidth, transaction latency-were gathered using Python 3.7/3.8, PyCryptodome, iFogSim, Linux perf-tools, and Wireshark across two duty-cycle regimes and four cipher-suite configurations. The ECC-256r1+AES-EAX instantiation yields optimal trade-offs: 0.006 s end-to-end encryption/decryption, 21.33 bit.ms security-efficiency ratio, 25.6% faster client-side processing, 44% lower server energy (95.4 W vs. 170.96 W for RSA-2048), 50% reduced client bandwidth, and -bit post-quantum security margin, while scaling robustly to 80 IoT devices with latency increase. Security guarantees are formally verified via IND-CCA2 game-based proofs, with empirical confirmation of MITM, replay, and Sybil attack resistance. Comparative evaluation demonstrates ECC schemes outperform RSA-2048 in memory footprint ( client), CPU load ( server), and energy efficiency ( server). The critical limitation is insufficient post-quantum security ( bits) under Shor’s algorithm, which the authors acknowledge but do not mitigate through lattice-based alternatives. Kumar and Bhatt 13 introduced a nature-inspired optimization dimension via Moth Search Algorithm (MSA) for ECC key generation coupled with DNA-encoding-based substitution. The MSA leverages Lévy-flight and phototaxis operators to search the integer interval for scalars maximizing a fitness function encoding ECC security and computational cost, preventing “eternity” failures during private-key selection. Plaintext is converted to 16-bit Unicode, hex, binary, and finally quaternary DNA strings (A=00, T=01, G=10, C=11) amplified with a 16-entry “ATGC key-combination” lookup table before curve-point mapping and ECC public-key encryption. Java experiments on synthetic text files (20 kB to 99 MB) demonstrate average encryption throughput of 172.34 Mb/s in 83.15 s and decryption throughput of 166.49 Mb/s in 86.08 s, outperforming AES, 3-DES, DES, and Blowfish by factors of 6–9 while using only 256-bit ECC keys (equivalent to 3,072-bit RSA). Security validation confirms resistance to DoS, impersonation, replay, known-plaintext, and chosen-ciphertext attacks owing to dual ECC-DNA secret dependency. However, formal security analysis relies on informal attack games rather than reduction-based proofs to standard cryptographic assumptions (e.g., ECDLP, CDH), weakening confidence in worst-case guarantees. The absence of standardized benchmarks further precludes direct comparison with competing schemes. Ghayvat et al. 14 extended hybrid architectures to blockchain-based healthcare clouds via CP-BDHCA, fusing ECC session-key establishment (HCA-ECC) with RSA+AES-CBC hybrid authentication (HCA-RSAE). Experiments on a 10-node blockchain (Ubuntu 20.04+XAMPP) synthesizing 30,000-patient/1,000-clinician profiling dataset and 100,000-case SEER benchmark demonstrate ECC session establishment in 310 ms under DoS and 300 ms under DDoS-outperforming AI4SAFE, TEE, Secret, and IIoTEED by accuracy gain. Two-step authentication achieves 1,405 ms average transaction-signing delay (vs. 1,489–1,612 ms in prior art) and 7.02 s verifying cost. Theoretical security analysis confirms ECC modular exponentiation (0.019 s), SHA-256 hashing (0.00032 s), and AES symmetric encryption (0.0056 s) dominate runtime, with the 6-message protocol withstanding replay, man-in-the-middle, and privilege-escalation threats. Patient-centric personalized segmentation exposes only role-relevant EHR fragments to doctors, pharmacists, and insurers. However, the exclusive focus on response time and transaction cost neglects cryptographic agility-the framework cannot dynamically upgrade algorithms as quantum threats materialize. Synthesis: Hybrid schemes demonstrate convergence on ECC-256 for key exchange and AES-128/256 for bulk encryption, yet metric homogeneity obscures critical trade-offs. Throughput (Mb/s), latency (ms), and energy (W or J) dominate evaluation, while side-channel resistance, post-quantum hardness, and formal verification coverage remain underexplored. The transition from CBC to authenticated modes (EAX, GCM) is inconsistent across studies. Beyond algebraic cryptographic primitives, emerging graph-theoretic approaches such as multi-layered encryption frameworks leveraging intuitionistic fuzzy graph properties—including domination number, vertex strength categorization, and chromatic number—have demonstrated alternative pathways to constructing complex, multi-step encryption schemes with enhanced resistance to unauthorized decryption 15 . Lightweight AES variants for IoT Resource scarcity in IoT endpoints has motivated lightweight AES modifications balancing security with computational frugality. Awasthi et al. 16 introduced a dynamic AES variant replacing the static S-box with a Xoodoo-generated dynamic S-box and substituting MixColumns with an ARX (Add-Rotate-XOR) diffusion layer to reduce energy and computational overhead. A blockchain-based key-management layer immutably stores 256-bit keys derived on-the-fly by XORing Xoodoo hashes of the file and last block, eliminating trusted third parties. Experiments on synthetic 128-, 256-, 512-, 1,024-, and 2,048-bit plaintext blocks processed on resource-constrained ARM Cortex-M4 demonstrate 0.30–0.80 ms encryption versus 0.50–1.00 ms for standard AES, yielding 36% faster encryption and 35% faster decryption at 128 bits, with energy savings growing as block size increases. Performance quantification includes encryption/decryption latency (ms/block), throughput (Mbps), CPU cycles, and energy ( J/block). Security validation via avalanche effect, strict avalanche criterion (SAC), and key-sensitivity tests shows bit-change and zero key collision, while the blockchain layer achieves 100% tamper-detection against key-integrity attacks. However, the absence of differential/linear cryptanalysis resistance proofs limits confidence in resilience against advanced cryptographic attacks, and encryption performance is benchmarked independently of blockchain overhead, obscuring end-to-end latency. Wang and Chen 17 adopted an orthogonal approach by replacing AES’s standard 4 4 MDS matrix in the MixColumns step with an 8 8 involutory Hadamard matrix over , lifting the diffusion branch number from 5 to 9 while preserving the original 10-round, 128-bit-key structure. The modified matrix is derived from a maximum-distance-separable (16, 8, 9) code with proven involutory property to halve decryption circuitry. Implementation on an 8-bit/16-bit MCU (20 MHz, 32 kB Flash) cycle-accurate simulator demonstrates the modified algorithm adds only 40 clock cycles ( latency) to the confusion stage, totaling 7,434 cycles per encryption versus 7,334 for standard AES, while maintaining identical byte-substitution, row-shift, and key-addition stages. Security is quantified via increased branch number (9 vs. 5) and analytical resistance to differential/linear cryptanalysis, though no third-party cryptanalysis or formal reduction to hard mathematical problems (e.g., learning-with-errors for post-quantum resilience) is provided. Both byte/cycle throughput and resistance metrics are reported, but the use of random 16-byte plaintext blocks rather than standardized cryptographic benchmarks (e.g., NIST Lightweight Cryptography finalists) hinders comparative evaluation. Peddi 18 contributed comparative performance evaluation of DES, AES, and 3DES tailored for resource-constrained mobile cloud environments. Implementation in Java on three Android handsets exercised each algorithm with five file sizes (1 kB to 30 kB) while encryption-decryption latency was sampled over 1,000–30,000 rounds to ensure statistical stability. No public dataset was used-synthetically generated binary files of controlled size served as workload. Results quantify average round-trip latency as DES –20k cycles, AES –48k cycles, and 3DES –200k cycles, establishing DES as highest throughput but AES as optimal security-efficiency trade-off ( faster than 3DES with comparable security). Evaluation strictly employs execution-time metrics (encryption+decryption latency per round, total CPU cycles, throughput in bytes.s ) rather than cryptographic security metrics. The exclusive focus on computational efficiency without profiling energy consumption, memory footprint, or cache-timing side-channel leakage limits practical deployment guidance for battery-constrained devices. Critical assessment: Lightweight AES research exhibits methodological bifurcation-algorithmic modifications prioritize throughput and diffusion metrics without standardized cryptanalysis, while empirical comparisons neglect algorithmic innovations. The field lacks unified benchmarking protocols encompassing execution time, energy, side-channel resistance, and formal security proofs under consistent threat models. Homomorphic encryption for privacy-preserving computation Homomorphic encryption enables computation on encrypted data, positioning it as a cornerstone of privacy-preserving cloud analytics. Hong et al. 19 introduced an ECC-based HE scheme supporting additive and multiplicative homomorphisms over encrypted integers, leveraging ECC for reduced computational and communication overhead. The methodology maps plaintext integers to elliptic curve points, encrypts them using ECC public keys, and performs homomorphic operations (addition, subtraction, multiplication, division) on ciphertexts in public cloud. To handle floating-point data, a mapping scheme converts them into integers before encryption and recovers them post-computation. The study employs real-world GPS crustal deformation data from 61 base stations in Fujian Province, China, including high-frequency GPS data from 13 stations during the 2012 Sumatra M8.6 earthquake. Comparative benchmarks using computation time and communication cost as evaluation metrics demonstrate ECC significantly outperforms RSA and Paillier in energy and communication consumption for data sizes ranging from 32 to 1,024 bytes. The encryption scheme is validated through practical application to GPS seismic deformation calculations, confirming feasibility, correctness, and efficiency. However, restriction to integer arithmetic and manual conversion of floating-point data via the mapping scheme introduce precision degradation not quantified in results. Kanna and Vasudevan 20 proposed Fully Homomorphic–ECC (FH-ECC) integrating ECC-based asymmetric encryption with homomorphic operations to reduce computational overhead while embedding fine-grained role-based access-control policy (695 rules) enforcing read/write restrictions for university roles (HOD, staff, students). The methodology follows a four-stage pipeline-access-policy verification, ECC encryption with 4-bit randomness and quadratic key elements, homomorphic evaluation (addition and multiplication on ciphertexts), and ECC+FH decryption-implemented in multi-cloud architecture (private cloud for profiles, public cloud for encrypted data). Experiments compare FH-ECC against MORE, PORE, and E-MORE schemes on synthetic university datasets (enrollment, marks, attendance, study materials) using key sizes 32–1,024 bits. Quantitative results show FH-ECC consistently lowers execution time ( –0.06 s), encryption time ( –100 ms), and decryption time ( –80 ms) across all key sizes, outperforming baselines by 30–60%. However, the conflation of “fully homomorphic” with operations limited to addition and multiplication-true FHE requires arbitrary-depth circuits with bootstrapping-misrepresents scheme capabilities. The absence of ciphertext noise-growth analysis and bootstrapping cost profiling undermines claims of practicality for multi-tenant cloud deployments. Gaitond et al. 21 advanced the state-of-the-art with BIOCF (Blockchain-Integrated Optimized Cryptographic Framework), fusing Paillier homomorphic encryption with a novel hybrid Greylag-Goose/Crayfish (GGO-CO) optimizer for key generation, split, and distribution via Shamir secret-sharing over consortium blockchain. Smart-contract-based attribute policies enforce fine-grained access control while on-chain SHA-256 hashes guarantee data integrity. Experiments on the 45,211-record UCI/Kaggle Bank Marketing dataset (80% train/20% test) simulate 10–30 MB cloud files using Python 3.10 implementations. BIOCF encrypts in 1.23–2.65 s, decrypts in 1.60–2.81 s, and generates keys in 0.68–2.10 s, achieving lowest latency (1.23–1.79 s) and highest throughput ( kb/s at 250 TPS) among six baselines (ECC, ChaCha20-Poly1305, ABE, AES, HES) while consuming only 48.5–64% CPU. Five-fold cross-validated regression yields MAPE 4.85%, MAE 0.12, RMSE 0.16, and for encryption-time prediction, confirming statistically significant superiority ( ) over all comparators. This represents a paradigm shift by treating encryption latency as a predictive machine-learning problem rather than fixed cryptographic overhead. However, exclusive focus on additive HE (Paillier) precludes multiplicative-depth-intensive applications (e.g., neural network inference), and CPU consumption on cloud-grade infrastructure questions feasibility for edge deployments. Xiao et al. 22 bridged the gap by hybridizing Partial Homomorphic Encryption (Paillier) for edge aggregation with Torus-based Fully Homomorphic Encryption (TFHE) for cloud-side anomaly detection. Their framework adapts an enhanced Isolation Forest algorithm for homomorphic evaluation by quantizing real-valued features and transforming tree-traversal logic into matrix operations compatible with TFHE’s Boolean gate operations. Extensive experiments on three benchmark datasets-Annthyroid, ForestCover, and Shuttle-demonstrate competitive detection performance with plaintext models, attaining accuracies of 0.8823, 0.9811, and 0.9563, and ROC-AUC scores of 0.8059, 0.8510, and 0.9592, respectively. Compared to existing encrypted detection schemes (BGV-FCM and CKKS-KNN), the model significantly improves ROC-AUC by up to 55.2% and reduces inference time by over 50%, despite 2.5 runtime increase relative to plaintext models. Evaluation metrics include accuracy, ROC-AUC, and per-sample inference time, with encryption efficiency assessed through ciphertext operation overhead and bootstrapping cost under TFHE. The reliance on quantized integer features and matrix-operation transformations constrains applicability to continuous-valued, high-dimensional data. Murthy and Kavitha 23 introduced a double-encryption framework for AWS-hosted medical multimedia data, integrating AES with user-generated random 256-bit keys for a second encryption layer. The methodology converts original data into image format, encrypts using AES, uploads to AWS, and applies second encryption with self-generated keys before transmission. Leveraging partial homomorphic encryption principles, the system allows operations on encrypted data without decryption. Testing on five model medical images of varying formats demonstrates successful encryption/decryption cycles, file format obfuscation, and AWS upload confirmation, indicating high security robustness. However, the absence of quantitative security metrics (e.g., IND-CPA/CCA2 proofs, key-recovery complexity) and reliance on five images limit generalizability. Hammami et al. 24 introduced Cloud-PPDM, coupling a novel Dist-CLOSE frequent closed itemset miner with lightweight symmetric-key homomorphic encryption and elliptic-curve aggregate signatures (EC-AS). The HE layer supports ciphertext additions only, while EC-AS guarantees end-to-end integrity and freshness without pairwise key exchange. Experiments on Amazon EC2 (High-CPU Medium, 1.7 GB RAM, 5 CU) compare Cloud-PPDM with commutative-crypto protocol on four public UCI KDD sets-dense Mushroom (8,124 trans, 127 items), Connect (67,557 trans, 129 items), C73D10K (10,000 trans, 2,178 items), and sparse T40I10D100K (100,000 trans, 1,000 items)-under 3-, 4-, and 5-site horizontal partitions and min-sup ranges 0.5%–90%. Wall-clock runtime is the prime metric; Cloud-PPDM consistently finishes 25–40% faster (e.g., 2,218 s vs. 3,494 s on Mushroom, 60% min-sup, 3 sites) while preserving lossless mining accuracy, cutting communication to O ( n ) ciphertexts and keeping master-side decryption and verification cost below 5% of total execution. Security evaluation confirms IND-CPA confidentiality, additive homomorphism correctness, and existential unforgeability of EC-AS under random oracle model, with no precision/recall degradation. However, restriction to additive homomorphism and lack of differential privacy guarantees expose potential linkage attacks via frequency analysis of encrypted itemsets. Synthesis: HE research bifurcates into theoretical constructs prioritizing operational expressiveness over practical latency, and systems-oriented implementations sacrificing generality for deployability. A critical gap is the absence of standardized HE benchmarks analogous to NIST’s post-quantum cryptography competition-studies employ disparate datasets, precluding cross-study performance comparison. Ciphertext-size inflation, bootstrapping frequency, and key-rotation overhead are inconsistently reported, obscuring total cost of ownership. Notably, the paradigm of treating cryptographic system parameters as optimization targets amenable to machine learning—as demonstrated by Gaitond et al. 21 for encryption latency prediction—mirrors the broader cross-domain trend of deploying data-driven models to optimize complex multi-parameter systems, from chemical process engineering 25 to energy system management 26 , suggesting that ML-assisted cryptographic parameter tuning represents a promising but underexplored research direction. Access control, authentication, and traitor tracing Fine-grained access control mechanisms addressing insider threats and key revocation have evolved toward cryptographic enforcement. Zhu et al. 27 introduced Partially-ordered Hierarchical Encryption (PHE), embedding RBAC-style role hierarchies into t -resilient broadcast encryption fabric. The six-tuple suite of probabilistic algorithms (Setup, Join-Group/User, Encrypt, Decrypt, Revoke, Trace) uses Lagrange-interpolation polynomials over prime-order bilinear groups to bind each role to public and each user to unique private . Security is reduced to Decision-Diffie-Hellman and Computational-Discrete-Log assumptions. Evaluation on a 10-class, 10-user-per-class synthetic RBAC hierarchy instantiated on 6-node OpenStack Swift testbed, scaled to 1,000,000 users in 1,000 groups, uses 160-bit q and 512-bit p NIST-style parameters with 80-bit security level. Implementation leverages GMP and PBC C++ libraries. Ciphertexts are constant-size ( kB header for 10,000 users) and decryption keys are bytes regardless of hierarchy depth. Encryption/decryption latency grows sub-linearly with threshold t ( ms for ), while black-box hierarchical tracing algorithm localizes traitors in oracle queries (average s for depth-5 trees) and public revocation algorithm revokes up to t users per broadcast with only modular exponentiations. Security quantification through IND-CPA games, CDL-based privilege-attack games, and DDH-based access-attack games proves negligible advantage for any t -limited collusion. Performance metrics include ciphertext-size/user-size overload ratio ( for 1M-user scenarios) and bandwidth per email ( kB). However, evaluation on synthetic hierarchies and scaling extrapolations lack empirical validation under real-world file-syncing workloads (e.g., Dropbox, Google Drive traces). Shukla and Patel 28 contributed provably secure multi-factor authentication via ECC-based MAKA protocol achieving Real-or-Random (ROR) model security and Scyther-tool formal verification. Addressing user linkability, replay, DoS, and known-session-specific-temporary-information (KSSTI) attacks, their three-factor protocol (password, biometric, smart-card) guarantees user anonymity, unlinkability, perfect forward secrecy, session-key independence, and resistance to impersonation, insider, man-in-the-middle, off-line password-guessing, de-synchronization, and lost-token attacks. Registration, login, authentication, password/biometric update, and smart-card revocation phases are specified. Fuzzy extractors handle noisy biometrics, while ECCDH/ECDDLP hardness underpins security. Correctness and attack resistance are evaluated formally through six-game ROR reductions showing adversary’s advantage is negligible in group order, password dictionary size, and biometric false-positive rate, and empirically via 100 Scyther runs reporting “no attacks within bounds” on secrecy, agreement, and aliveness claims. Performance benchmarking (Java on MacOS, ECC-256, AES-128, SHA-1) gives s total runtime and 1,856-bit communication overhead, a modest increase ( s and bytes) over seven recent schemes while offering strictly stronger security feature coverage. However, reliance on fuzzy extractors introduces error-correction overhead not profiled separately, and MacOS/Java implementation neglects hardware security module (HSM) integration critical for tamper-resistant key storage. Tawfik et al. 29 pioneered quantum-resistant IoT authentication via lattice-based zero-knowledge proofs and blockchain-backed verification. Their three-fold contribution includes: (i) lightweight Module-SIS ZKP protocol trimming computational overhead by versus prior post-quantum schemes, (ii) smart-contract-driven device registry coupling chameleon hashing with on-chain trust-score dynamics to enforce non-transferability and replay resistance, and (iii) privacy layer performing additive homomorphic evaluation (BFV/CKKS) on encrypted telemetry without exposing plaintext. Prototype on Intel i7-8th-gen/16 GB desktop running Windows 11, Ganache local Ethereum, and Python 3.10 MQTT-IoT simulator uses 100 synthetic sensors (ARM-Cortex-M class) injecting 1,000 msg/s encrypted telemetry. Core algorithms include: (a) Dilithium-4 signatures for device credentials, (b) McEliece-8192128 for CCA2-secure key transport, (c) Schnorr-style ZKP modified to Module-SIS for 128-bit post-quantum hardness, and (d) chameleon-hash binding locking each proof to specific verifier and 5-minute freshness window. Quantitatively, the system achieves 350 ms end-to-end authentication (5.7% faster than best prior quantum-resistant scheme), 300 ms ZKP generation, 120 ms verification, 180 ms homomorphic encryption, and 145k gas per device registration, sustaining 100 concurrent devices with 98% GUI responsiveness and 92.8% registration success rate. Encryption performance profiled separately with BFV at 16.4 ms and CKKS at 31.3 ms on Raspberry Pi 4 confirms sub-second homomorphic throughput. The study establishes the first full-stack, quantum-safe, privacy-preserving IoT authentication primitive formally proven complete, zero-knowledge, non-transferable, and post-quantum secure under Module-SIS hardness. However, reliance on synthetic MQTT sensors and Ganache local Ethereum limits ecological validity; performance under mainnet congestion, cross-chain identity federation, or hardware-enforced trusted execution environments remains unexplored. Critical Evaluation: Access-control research demonstrates methodological maturity in formal verification (ROR models, Scyther, game-based reductions), yet a persistent gap exists between proof-of-concept prototypes and production-grade deployments. Transition from controlled testbeds to heterogeneous multi-cloud federations with regulatory compliance constraints (GDPR, HIPAA, CCPA) is conspicuously absent. Selective encryption and dynamic resource allocation Gai et al. 30 addressed privacy-performance tension in mobile-cloud big-data through Dynamic Data Encryption Strategy (D2ES), a selective time-aware framework maximizing cumulative Privacy Weight Values (PWV) under latency budgets. The core contribution is proving the underlying Maximum Data Package under Timing Constraints (MDPuTC) problem is NP-hard and providing near-optimal polynomial-time solution. Three novel algorithms orchestrate D2ES: (i) Weight Modelization (WM) upgrading encryption urgency to infinity for paired-data whose joint exposure breaches privacy, (ii) S-Table Generation (STG) ranking packages by PWV-per-encryption-time ( ), and (iii) Dynamic Encryption Determination (DED) greedily selecting packages in that order until latency slack is exhausted, guaranteeing feasibility while maximizing PWV. All encryption executed with AES-128. Across 1,200 simulated runs with parameterized settings (3–11 package types, 1–50 time-units per encryption, PWV 1–6), D2ES achieves of brute-force optimal PWV in 95% of cases and hits optimum 52.5% of the time, while reducing average computation time by 3–6 orders of magnitude relative to brute-force and dynamic-programming baselines (micro- vs. seconds on Intel Xeon E5-2687W Ubuntu VM). Evaluation metrics include: total PWV (TPWV) as primary utility score, total execution time validated against latency constraint, performance rate quantifying optimality gap, and computation-time speed-up demonstrating scalability. However, synthetic datasets and absence of real mobile-cloud traffic traces limit transferability, and binary encrypted/unencrypted decision model neglects graduated encryption levels. Research gaps and future directions The reviewed literature collectively advances cloud security through cryptographic composition, distributed trust, privacy-preserving computation, and formal verification. However, critical gaps persist that require immediate attention. Studies employ disparate evaluation metrics-encryption/decryption latency, throughput, gas cost, ROC-AUC, PWV-without standardized benchmarks, precluding meta-analysis and objective comparison analogous to NIST cryptographic competitions. Post-quantum readiness remains critically inadequate, with only Tawfik et al. 29 implementing lattice-based primitives while the predominance of ECC-256 and AES-128/256 remains vulnerable to Shor’s and Grover’s quantum algorithms, necessitating urgent migration to NIST-standardized CRYSTALS-Kyber/Dilithium. Most studies assume honest-but-curious cloud providers or static adversaries, neglecting adaptive attackers exploiting timing channels, consensus delays, or ML-based inference on encrypted traffic patterns, with differential privacy integration conspicuously absent. While individual studies target edge IoT sensors or cloud data centers, holistic edge-to-cloud pipelines balancing latency, energy, and security across the continuum remain underexplored beyond domain-specific implementations like Xiao et al. 22 for smart grids. Finally, no study formally verifies GDPR right-to-erasure, HIPAA audit trail, or CCPA data minimization compliance through cryptographic enforcement mechanisms such as verifiable deletion or immutable audit logs. The current research landscape requires longitudinal studies integrating hybrid encryption, blockchain integrity, homomorphic computation, and formal access control under standardized threat models and cross-domain benchmarks, with explicit post-quantum migration paths and regulatory compliance verification. Proposed method System architecture We propose a privacy-preserving cloud storage framework integrating hybrid cryptographic techniques with blockchain-based integrity verification. The system comprises five operational layers: (1) client layer for data preparation and key management, (2) cryptographic layer implementing AES-256 with HMAC-SHA256 authentication, ECC on brainpoolP256r1, ECDSA on SECP256k1, and Paillier homomorphic encryption, (3) distributed storage layer distributing encrypted chunks across five independent cloud nodes using hash-based assignment, (4) blockchain layer maintaining immutable file hash records via Ethereum smart contracts deployed on Ganache development network (designed for migration to permissioned networks such as Hyperledger Fabric for production deployments), and (5) metadata management layer storing encrypted file information in MySQL database. Figure 1 illustrates the complete system architecture showing data flow across all layers. Figure 1. Open in a new tab Comprehensive architecture of the privacy-preserving cloud storage framework showing the five operational layers: client and data preparation, cryptographic operations (AES-256-CBC with HMAC-SHA256, ECIES, ECDSA, Paillier HE), distributed cloud storage with hash-based routing, blockchain integrity verification via Ethereum smart contracts, and metadata management with encrypted keyword search. Performance metrics and limitations are summarized at the bottom. Threat model We adopt an honest-but-curious adversary model where cloud providers execute protocols correctly but attempt to learn information from stored data. The adversary has complete access to encrypted data, metadata, and blockchain transactions but cannot break cryptographic primitives in polynomial time. We assume AES-256 provides semantic security under chosen plaintext attacks (IND-CPA) with HMAC-SHA256 providing ciphertext authentication to mitigate padding oracle attacks, the elliptic curve discrete logarithm problem is hard on brainpoolP256r1 providing 128-bit security, ECDSA provides existential unforgeability under chosen message attacks (EUF-CMA), the decisional composite residuosity assumption holds for Paillier encryption with 2048-bit modulus, SHA-256 provides collision resistance, and the Ethereum blockchain maintains Byzantine fault tolerance with honest majority. The selection of brainpoolP256r1 for key encapsulation provides verifiably random curve parameters, while SECP256k1 is used for digital signatures to ensure compatibility with the Ethereum blockchain ecosystem. Using a single curve for both purposes would require either sacrificing Ethereum compatibility (if brainpoolP256r1 were used for signatures, requiring a custom Ethereum node configuration) or forgoing verifiably random parameters (if SECP256k1 were used for key encapsulation, inheriting its Koblitz structure which, while not known to be insecure, lacks the transparency of verifiably random generation). The dual-curve approach provides defense-in-depth: a vulnerability in one curve does not compromise all cryptographic operations. We do not protect against side-channel attacks, quantum adversaries, or compromised client environments. Hybrid cryptographic protocol Our cryptographic protocol combines multiple primitives to achieve confidentiality, integrity, authenticity, and limited homomorphic capabilities. The design follows a hybrid approach where symmetric encryption provides efficiency for bulk data while asymmetric cryptography enables secure key distribution and authentication. Key Generation During system initialization, each user generates a comprehensive cryptographic key bundle supporting all system operations. The key generation produces four distinct key pairs, each serving a specific security function within the overall architecture. The first component is an elliptic curve key pair for key encapsulation. We utilize the brainpoolP256r1 curve, which provides 128-bit security strength against known discrete logarithm attacks including Pollard’s rho algorithm. This curve was selected for its security provenance and verifiably random parameter generation, avoiding potential backdoors in curve design. The private key is selected uniformly at random from the scalar field, while the public key is computed through scalar multiplication with the generator point. The second component is an ECDSA signing key pair on the SECP256k1 curve. This curve is widely deployed in blockchain systems including Bitcoin and Ethereum, ensuring compatibility with existing infrastructure. The signing key enables generation of compact digital signatures providing authentication and non-repudiation properties. The third component is a Paillier key pair for homomorphic encryption. We use a 2048-bit modulus providing approximately 112-bit security against factorization attacks using the general number field sieve. The key generation involves selecting two large primes and computing the necessary parameters for encryption and decryption operations. This key pair enables privacy-preserving operations on encrypted keywords. The fourth component is a deterministic encryption key derived via SHA-256 from a master seed. This key enables encryption of filenames in a deterministic manner, allowing equality queries on encrypted values while preventing unauthorized access to actual filenames. Each generated key bundle receives a universally unique identifier (UUID version 4) enabling key versioning and cryptographic agility. Users can maintain multiple key bundles for different security domains or rotate keys periodically according to security policies. The complete key generation procedure is formalized in Algorithm 1. Algorithm 1. Open in a new tab Comprehensive user key generation File Encryption The file encryption protocol implements a multi-phase hybrid approach combining the efficiency of symmetric cryptography with the key management advantages of public key systems. The protocol operates in four distinct phases: symmetric file encryption, elliptic curve key encapsulation, digital signature generation, and homomorphic keyword encryption. In the first phase, a random 256-bit AES key and 128-bit initialization vector are generated using a cryptographically secure pseudorandom number generator. The file content is encrypted using AES-256 in cipher block chaining (CBC) mode. To enable correct decryption and integrity verification, the original file size is prepended to the plaintext before encryption. This design avoids ambiguity in padding removal and enables detection of truncation attacks. The encryption produces ciphertext satisfying where | F | denotes the 8-byte encoding of file size. An HMAC-SHA256 tag is computed over the entire ciphertext (including IV) to provide authenticated encryption through the encrypt-then-MAC construction, preventing padding oracle attacks that affect unauthenticated CBC mode. The second phase implements elliptic curve integrated encryption for protecting the AES key. An ephemeral private key is generated for each encryption operation, providing perfect forward secrecy - compromise of the user’s long-term private key does not compromise past session keys. The ephemeral public key is computed through scalar multiplication, and a shared secret point is derived via elliptic curve Diffie-Hellman. The shared secret coordinates undergo SHA-256 hashing to produce a uniformly random 256-bit key, which is used to encrypt the AES key. Only the x-coordinate of the ephemeral public key is stored, reducing storage overhead by approximately 50%. During decryption, the full point can be reconstructed using the elliptic curve equation. The third phase generates an ECDSA digital signature over the file hash, providing authentication and integrity verification. The signature enables any party possessing the user’s public key to verify the file’s origin and detect unauthorized modifications. The signature is computed as , and stored along with the public key and file hash in a proof structure. The fourth phase encrypts keywords extracted from file metadata using Paillier homomorphic encryption. Each keyword is hashed before encryption to normalize representation and enable consistent comparison. The Paillier encryption function where r is a random value provides additive homomorphism, theoretically enabling encrypted search operations without decryption. The complete encryption procedure is presented in Algorithm 2. Algorithm 2. Open in a new tab Hybrid file encryption with authentication The encryption satisfies semantic security under the IND-CPA assumption for AES-256, ensuring that an adversary cannot distinguish between encryptions of two chosen plaintexts with better than negligible probability. The addition of HMAC-SHA256 over the ciphertext provides ciphertext authentication, preventing chosen-ciphertext attacks including padding oracle attacks that affect unauthenticated CBC-mode encryption. Together, the encrypt-then-MAC construction achieves IND-CPA confidentiality with INT-CTXT integrity. We note that the current implementation uses as both the encryption and HMAC key; while no known practical attack exploits this for AES-256-CBC with HMAC-SHA256, standard cryptographic practice 31 recommends deriving separate sub-keys (e.g., via HKDF) for encryption and authentication to enforce key separation as a defense-in-depth measure. Implementing HKDF-based key derivation is planned as a future improvement. The key encapsulation provides forward secrecy through ephemeral keys - the shared secret derivation exploits scalar multiplication commutativity: , enabling the receiver to compute the same shared secret using their private key and the ephemeral public key. File Decryption The decryption protocol systematically reverses all encryption operations while implementing defense-in-depth through verification at multiple stages. The protocol fails securely, returning explicit failure indication if any verification step detects inconsistency or corruption. This design prevents attacks that rely on error message analysis or partial decryption results. The decryption begins by reconstructing the full ephemeral public key from the stored x-coordinate. The elliptic curve equation for brainpoolP256r1 in Weierstrass form is . Given the x-coordinate, we compute and extract y using the Tonelli-Shanks modular square root algorithm, which has complexity . The reconstructed point is verified to lie on the curve before use, using the Tonelli-Shanks algorithm 32 for computing modular square roots, which has complexity . The key decapsulation phase recomputes the shared secret point by performing scalar multiplication of the reconstructed ephemeral public key with the user’s private key. Due to the commutativity of scalar multiplication, this yields the same shared secret as computed during encryption: . The shared key derived via SHA-256 hashing decrypts the protected AES key. The protocol verifies that the recovered AES key has the correct length (32 bytes), detecting decryption failures or padding oracle attacks. Once the AES key is recovered, the protocol performs HMAC verification before any decryption. The HMAC-SHA256 tag is recomputed over the ciphertext using the recovered key and compared against the stored tag , ensuring ciphertext authenticity and integrity prior to decryption. This ordering—key decapsulation, then HMAC verification, then decryption—ensures that no plaintext is produced from unauthenticated ciphertext. File content decryption uses standard AES-256-CBC with the recovered key. The initialization vector is extracted from the first 16 bytes of the ciphertext, and the remaining bytes are decrypted. After removing PKCS#7 padding, the file size is extracted from the first 8 bytes, enabling exact recovery of the original content and preventing padding-related vulnerabilities. The final verification phase authenticates the file through ECDSA signature verification. The protocol first computes the SHA-256 hash of the recovered file content and compares it against the hash stored in the proof structure. If hashes match, the ECDSA signature is verified using the public key. Any failure in hash comparison or signature verification results in protocol abortion with explicit failure indication. The complete decryption procedure is formalized in Algorithm 3. Algorithm 3. Open in a new tab Hybrid file decryption with verification Distributed cloud storage architecture The storage layer implements a distributed architecture eliminating single points of failure through hash-based data distribution across five independent cloud storage nodes. This design achieves load balancing without centralized coordination, fault tolerance through deterministic chunk placement, and scalability through stateless node assignment. Hash-Based Distribution Mechanism The distribution mechanism maps encrypted file chunks to storage nodes using a deterministic hash function based on consistent hashing principles 33 , which provides uniform load distribution without centralized coordination.For a file with unique identifier (generated as SHA-256 hash of random bytes, truncated to 128 bits), the encrypted ciphertext C is divided into chunks based on size thresholds. Files smaller than 1 KB are stored as single chunks to minimize metadata overhead and reduce network round trips. Larger files can be divided into 1 MB chunks, though our current implementation primarily stores files as single chunks for simplicity. The chunk assignment function deterministically maps each chunk to exactly one of storage nodes using where i is the chunk index, denotes byte concatenation, and [0 : 16] extracts the first 16 bytes. SHA-256 is used rather than weaker hash functions to maintain consistency with the security-oriented design of the overall system, though collision resistance is not strictly required for load balancing purposes. This deterministic mapping provides three critical properties. First, consistency ensures that identical chunks always map to the same storage node across all protocol executions, enabling reliable retrieval without maintaining explicit chunk-to-node mapping tables. Second, load balancing is achieved under the random oracle assumption for the hash function - if file identifiers are uniformly distributed, the expected number of chunks per node converges to where k is average chunks per file, m is total files, and nodes. Third, efficiency is maintained as node selection requires only hash computation, making assignment negligible compared to network I/O costs. Each storage node maintains a simple directory structure organized by node identifier. Chunks are persisted as individual files with naming convention where i is the chunk index. This flat namespace design provides several operational advantages including simplified debugging through direct filesystem inspection, compatibility with standard backup tools, and straightforward integration with existing monitoring systems. The complete storage distribution procedure is formalized in Algorithm 4, while retrieval is shown in Algorithm 5. Algorithm 4. Open in a new tab Distributed storage assignment Algorithm 5. Open in a new tab Distributed file retrieval The retrieval complexity is O ( k ) where k is the number of chunks, as each chunk requires one network round trip. For single-chunk files (the typical case in our implementation), this reduces to O (1) storage operations plus O ( n ) network transfer time where n is the file size. Blockchain integrity verification The blockchain layer provides cryptographically verifiable integrity checking through an Ethereum smart contract maintaining immutable file hash records. This design enables decentralized verification without requiring trust in any single party, leveraging the blockchain’s consensus mechanism to ensure tamper-evidence. The FileRegistry smart contract stores mappings from file identifiers to records containing the file owner’s Ethereum address, cryptographic hash of encrypted file content, hash of metadata, registration timestamp, and status flag. After successful encryption and storage, files are registered on the blockchain by computing for the encrypted content and for metadata, converting the file ID to bytes32 format via Keccak-256, constructing an Ethereum transaction calling the registerFile function, signing with the user’s Ethereum private key, and broadcasting to the network as formalized in Algorithm 6. Algorithm 6. Open in a new tab Blockchain Registration Registration uses approximately 200,000-300,000 gas units. On Ganache test network, confirmation occurs within 100-500ms. Public Ethereum networks exhibit variable confirmation times based on gas price and network congestion. Integrity verification compares the current file hash against the blockchain record. For file C , compute and query the blockchain for the registered hash . If , return VERIFIED; otherwise return TAMPERED. Any modification to stored content produces a different hash with probability , providing cryptographic proof of tampering. The blockchain’s immutability ensures registered hashes cannot be retroactively modified. Metadata management A MySQL database stores encrypted metadata enabling efficient queries while preserving confidentiality. The schema includes: file_metadata (encrypted filenames, cryptographic material, storage paths, key version IDs), users (bcrypt-hashed credentials), and acl (access control lists). Filenames are encrypted deterministically 31 as , enabling equality queries while preventing database administrator access. Keyword search operates in two modes depending on the deployment trust model. In the client-side search mode (current implementation), the client retrieves encrypted keyword hashes from the database and performs Paillier decryption locally before matching against the query hash , with complexity where m = files and n = keywords/file. This mode ensures that the database server never observes plaintext keyword values; the probabilistic nature of Paillier encryption prevents the server from performing frequency analysis on the stored ciphertexts, as identical keywords produce distinct ciphertexts across different files due to random blinding factors. In the server-assisted search mode (future work), fully privacy-preserving search would require techniques such as deterministic encryption for equality queries or order-preserving encryption for range queries, enabling the server to perform matching on ciphertexts without decryption. Implementing server-side homomorphic comparison remains an open challenge left for future work, as it requires either switching to a deterministic encryption scheme (sacrificing IND-CPA security) or employing more expensive fully homomorphic evaluation circuits. Performance complexity Table 1 summarizes computational complexity. Table 1. Computational complexity. Operation Time Factor Encryption/decryption O ( n ) AES-256+HMAC Key encap./decap. / ECC Signature ECDSA Keyword encryption Paillier Storage Ops O ( k ) Chunks Blockchain O (1) / O ( n ) Call/Hash Search Linear Open in a new tab = number of files, k = keywords per file; the factor arises from modular exponentiation with 2048-bit Paillier modulus. Smart Contract Architecture The FileRegistry smart contract implements a persistent mapping from file identifiers to metadata records. The contract maintains state variables storing file ownership, cryptographic hashes, timestamps, and access control lists. Each file record is represented as a tuple where is the Ethereum address of the file owner, is the SHA-256 hash of encrypted file content, is the hash of metadata, t is the Unix timestamp of registration, and is a boolean indicating whether the file is active. The smart contract exposes four primary functions that implement blockchain-based access control 34 , 35 , each serving a distinct purpose in the overall security architecture. Function 1: File Registration. The registerFile function creates a permanent record associating the file identifier with its cryptographic hashes: Open in a new tab Listing 1 . File Registration Function This function accepts three parameters: a 32-byte file identifier obtained by hashing the original file ID, the SHA-256 hash of encrypted file content as a hexadecimal string, and the hash of associated metadata. The function creates a new record in the contract’s storage mapping, setting the owner field to msg.sender (the Ethereum address calling the function), storing both hash values, recording the current block timestamp, and marking the file as active. Only the file owner can register files, enforced through the msg.sender check. The function emits a FileRegistered event containing the file ID and owner address, enabling off-chain indexing and monitoring systems to track file registrations without querying the blockchain directly. Function 2: Integrity Verification. The verifyIntegrity function provides read-only hash comparison: Open in a new tab Listing 2 . Integrity Verification Function This function accepts a file identifier and a hash value to verify. It retrieves the stored file record from the blockchain, extracts the registered hash value, and performs string comparison against the provided hash. The function returns true if hashes match, indicating file integrity is preserved, or false if they differ, indicating tampering or corruption. The view modifier indicates this function performs no state modifications - it only reads existing data. This designation makes external calls to this function gas-free, as no transaction is required for read-only operations. Any party can call this function to verify file integrity without incurring blockchain transaction costs. Function 3: Access Control Grant. The grantAccess function implements decentralized access control: Open in a new tab Listing 3 . Access Control Grant Function This function allows the file owner to grant access rights to other Ethereum addresses. It accepts the file identifier and the Ethereum address to be granted access. The onlyOwner modifier restricts execution to the file owner - if called by any other address, the transaction reverts. Upon successful execution, the specified user address is added to the file’s access control list maintained in the contract’s storage. The function emits an AccessGranted event recording the file ID and newly authorized user address for audit trail purposes. Function 4: Access Control Revocation. The revokeAccess function removes previously granted permissions: Open in a new tab Listing 4 . Access Control Revocation Function This function enables the file owner to revoke access rights from users who were previously granted access. Similar to the grant function, it uses the onlyOwner modifier to ensure only the file owner can revoke permissions. The function removes the specified user address from the file’s access control list and emits an AccessRevoked event documenting the permission change. This audit trail enables tracking of all access control modifications throughout the file’s lifecycle. Registration Protocol After successful file encryption and storage across distributed nodes, the file metadata is registered on the blockchain to establish an immutable integrity baseline. The registration protocol is formalized in Algorithm 6. Algorithm 7. Open in a new tab Blockchain File Registration Protocol The registration protocol first computes SHA-256 hashes of both the encrypted file content and the serialized metadata structure. These hashes serve as cryptographic fingerprints enabling future integrity verification. The file identifier undergoes Keccak-256 hashing to convert from arbitrary-length string to Ethereum’s fixed-size bytes32 type, providing uniform distribution and collision resistance. An Ethereum transaction is constructed containing the smart contract address as the destination, the encoded function call with parameters as transaction data, and the user’s Ethereum address as the sender. Gas estimation determines the computational cost, set to 300,000 units based on empirical measurements of the registerFile function’s execution cost. The gas price is queried dynamically from the network to ensure timely transaction inclusion based on current congestion levels. The nonce prevents transaction replay attacks by ensuring each transaction from an address has a unique sequence number. Transaction signing uses ECDSA on the secp256k1 curve (Ethereum’s signature algorithm), producing a digital signature proving transaction authorization without revealing the private key. The signed transaction is broadcast to all network nodes via JSON-RPC, where it enters the transaction pool (mempool) awaiting inclusion in a block. Confirmation waiting implements a timeout mechanism preventing indefinite blocking. On Ganache local test networks, confirmation typically occurs within 100-500 milliseconds due to instant block mining. Public Ethereum networks exhibit variable confirmation times ranging from 15 seconds to several minutes depending on network congestion and gas price settings. The transaction receipt contains the final status, block number, and gas consumed, enabling verification of successful execution. Integrity Verification Protocol File integrity can be verified at any future point by comparing the current file hash against the immutable blockchain record. For file C with identifier , compute the current hash . Convert the file identifier to bytes32 format via . Query the blockchain using the getFile view function to retrieve the stored record. If the record’s owner field equals the zero address (0x0000...0000), the file was never registered - return NOT_FOUND. Otherwise, extract the stored hash from the record and compare. If , return VERIFIED indicating the file has not been modified since registration. If the hashes differ, return TAMPERED indicating detection of unauthorized modification or corruption. This verification provides cryptographic proof of file integrity. Any modification to the encrypted file content, even a single bit flip, produces a completely different SHA-256 hash with overwhelming probability (collision probability approximately ). The blockchain’s immutability ensures the registered hash cannot be retroactively modified by any party, including the file owner, cloud provider, or blockchain validators. The decentralized consensus mechanism eliminates reliance on any single trusted authority - as long as the blockchain maintains its security properties, the integrity verification remains trustworthy. The verification complexity is O ( n ) for hash computation where is the file size, plus O (1) for the blockchain query. Modern SHA-256 implementations process approximately 400-600 MB/s on typical hardware using optimized instruction sets, making verification practical even for large files. The blockchain query incurs zero gas cost due to the view modifier, requiring only network round-trip time to an Ethereum node. Implementation Implementation: Python 3.8+ ( 2,000 lines) using pycryptodome (AES-256, HMAC-SHA256), tinyec, python-phe, ecdsa, web3.py, mysql-connector-python. Uses Ganache Ethereum development network for smart contract deployment and testing; the architecture supports migration to permissioned networks such as Hyperledger Fabric for production deployments. Results Experimental setup and implementation The proposed privacy-preserving cloud storage framework was implemented and evaluated on a cluster of six computers, each equipped with an Intel Core i5 processor operating at 3.6 GHz, 16GB RAM, Microsoft Windows 11 64-bit, and 500GB hard drive. The blockchain consensus evaluation employed a 300-node overlay network (60 nodes in the leadership group and 240 nodes distributed across 8 normal groups, with 30 simulated nodes per computer operating on different ports) to evaluate dynamic TPA selection and collusion resistance at scale. The 300-node network serves as the consensus and auditing layer for TPA selection, operating independently of the 5-node distributed storage layer described in the Methods section, which handles encrypted file chunk storage and retrieval. The implementation utilized Python 3.8+ ( 2,000 lines of code) with the following cryptographic libraries: pycryptodome for AES-256 encryption and HMAC-SHA256 authentication, tinyec for ECC operations on brainpoolP256r1, python-phe for Paillier homomorphic encryption, ecdsa for digital signatures on SECP256k1, web3.py for Ethereum blockchain integration, and mysql-connector-python for database operations. The blockchain component utilized the Ganache local Ethereum development network, providing instant block mining for controlled performance evaluation. The FileRegistry smart contract was deployed and tested on this network. The architecture is designed for migration to permissioned blockchain networks such as Hyperledger Fabric for production deployments requiring consortium identity management. The distributed storage system implemented five independent storage nodes (node_0 through node_4) using hash-based chunk distribution according to the mapping function , where fid represents the file identifier and i denotes the chunk index. Database schema and metadata management Figure 2 presents the implemented database schema. The file_metadata table stores encrypted filenames using deterministic AES-256-CBC encryption, enabling equality queries while preventing unauthorized access. Cryptographic parameters including encrypted_aes_key, encrypted_point_x, ecdsa_signature, and key_id are maintained for each file entry. The schema demonstrated efficient query performance with average lookup times of 12.3ms for 10,000 file entries and 45.7ms for 100,000 entries, indicating logarithmic scaling consistent with B-tree indexing. Figure 2. Open in a new tab MySQL database schema showing three-tier architecture with users, file_metadata, and acl tables supporting encrypted metadata storage and role-based access control. Distributed storage performance Figure 3 illustrates the distributed storage architecture with actual file chunks distributed across the five nodes. Over 1,000 file uploads, the hash-based distribution achieved near-uniform load balancing with a variance of in chunk count per node, confirming the effectiveness of the SHA-256-based distribution algorithm under the random oracle assumption. Figure 3. Open in a new tab Distributed storage node organization demonstrating load balancing across five nodes with hash-based chunk distribution achieving variance in chunk distribution. Table 2 summarizes storage performance across 1,000 file operations. Multi-chunk operations demonstrated higher aggregate throughput (50.8 MB/s vs. 42.7 MB/s for single chunks) due to parallel I/O operations across nodes, validating the scalability benefits of the distributed architecture. Table 2. Storage performance metrics (n = 1000 files). Operation Mean time (ms) Throughput (MB/s) Single chunk storage 23.4 ± 3.2 42.7 Multi-chunk storage (5 chunks) 98.7 ± 12.1 50.8 Chunk retrieval 18.9 ± 2.8 52.9 File reassembly (5 chunks) 87.3 ± 9.4 57.3 Open in a new tab Blockchain integration and smart contract performance The FileRegistry smart contract was successfully deployed and evaluated on the Ganache local Ethereum development network. Figure 4 shows the blockchain state with deployed contract and transaction history. It should be noted that Ganache provides instant block mining in a single-node environment, meaning consensus latency measurements represent optimistic baselines rather than production-realistic values. Gas consumption analysis revealed the following costs: registerFile() consumed 243,187 ± 18,432 gas units, grantAccess() required 87,521 ± 6,234 gas units, and verifyIntegrity() (view function) incurred zero gas cost as expected for read-only operations. Figure 4. Open in a new tab Ganache blockchain state showing FileRegistry smart contract deployment: (top) Truffle migration console confirming deployment of the FileRegistry contract with gas consumption of 1,243,876 units; (bottom) Ganache UI displaying the deployed contract address, recent transactions including registerFile, grantAccess, and verifyIntegrity function calls, with average block confirmation time of 287.5ms. Table 3 presents detailed blockchain operation metrics. The registerFile() function demonstrated consistent performance with mean transaction time of 287.5ms on the Ganache development network, which provides instant block mining. Production deployment on permissioned networks such as Hyperledger Fabric would exhibit higher latency (1–3 seconds based on 11 ) but would provide consortium-level security features. All transactions achieved 100% success rate, confirming the reliability of the smart contract implementation. Table 3. Blockchain operation performance (n=100 transactions). Function Gas cost Time (ms) Success rate registerFile 243,187 287.5 ± 42.3 100% verifyIntegrity 0 (view) 12.3 ± 2.1 100% grantAccess 87,521 134.2 ± 18.7 100% revokeAccess 45,318 98.4 ± 12.4 100% Open in a new tab Blockchain Network Projection Analysis The Ganache development network was selected as the evaluation platform for three methodological reasons: (i) it provides deterministic, reproducible execution enabling precise isolation of smart contract computational cost from network-induced variance; (ii) gas consumption—the primary platform-invariant cost metric—remains identical across all Ethereum-compatible networks since it measures EVM instruction count rather than wall-clock time; and (iii) it enables controlled scalability testing of the 300-node TPA overlay without confounding factors from public network congestion. The measured gas costs (registerFile: 243,187; grantAccess: 87,521; revokeAccess: 45,318) represent deterministic EVM execution costs that transfer directly to any Ethereum-compatible deployment target. Figure 5 presents analytical projections of transaction latency and throughput across four deployment scenarios derived from the literature. The Ganache baseline (287ms) represents the lower bound achievable with zero network latency. Hyperledger Fabric deployments exhibit 1–3 second consensus latency dominated by Kafka/Raft ordering 11 , while private Proof-of-Authority Ethereum networks provide 3–8 second block times. Public Ethereum mainnet latency (12–30 seconds) represents the upper bound with variable gas pricing ($5–50 per transaction during congestion). Critically, our framework’s cryptographic operations (245.7ms encryption) remain the dominant per-file cost regardless of blockchain backend, as blockchain registration constitutes a one-time operation per file rather than a per-access overhead. The 85 TPS per-group throughput measured on Ganache provides a conservative upper bound; production throughput would be limited by the consensus mechanism of the chosen deployment target. Figure 5. Open in a new tab Analytical projection of blockchain performance across deployment scenarios: ( a ) transaction latency comparison showing Ganache measured baseline versus literature-derived projections for Hyperledger Fabric, private PoA Ethereum, and public Ethereum; ( b ) throughput and per-transaction cost comparison highlighting the trade-off between decentralization and operational efficiency. Sepolia Public Testnet Validation To complement the controlled Ganache evaluation and analytical projections, we deployed the FileRegistry smart contract on the Sepolia public Ethereum testnet and executed 15 transactions to validate gas cost consistency and characterize real-world confirmation latency. Figure 6 shows the Sepolia testnet wallet configuration used for the deployment experiments. Figure 6. Open in a new tab MetaMask wallet on the Sepolia public Ethereum testnet showing the account used for smart contract deployment and transaction validation experiments, with SepoliaETH and LINK test tokens. Table 4 summarizes the Sepolia validation results. The key finding is that gas consumption remains identical across Ganache and Sepolia (243,187 gas for registerFile), confirming that EVM execution cost is a platform-invariant metric. Transaction confirmation latency averaged 15.3±4.7 seconds on Sepolia—approximately 53 higher than Ganache—reflecting actual block mining intervals ( 12 seconds) and network propagation delays. The verifyIntegrity view function exhibited 1.1±0.4 second response time, dominated by RPC round-trip latency rather than computation. All 15 transactions were confirmed successfully on the first attempt (100% success rate), and gas prices ranged from 0.1 to 1.8 Gwei during the evaluation window. Table 4. Sepolia public testnet validation (n=15 transactions). Metric Ganache Sepolia Ratio registerFile latency 287.5±42.3 ms 15.3±4.7 s 53 verifyIntegrity latency 12.3±2.1 ms 1.1±0.4 s 89 Gas cost (registerFile) 243,187 243,187 1.0 Gas price range (Gwei) Fixed 0.1–1.8 Variable First-attempt success rate 100% 100% – Open in a new tab These results validate two critical claims: (i) the cryptographic protocol overhead (245.7ms encryption for 1MB files) remains the dominant per-file cost, as even the Sepolia confirmation latency ( 15 seconds) constitutes a one-time registration overhead per file rather than a per-access cost; and (ii) the smart contract logic executes correctly and with identical gas consumption on public infrastructure, confirming production readiness of the contract code. For enterprise deployments, permissioned networks such as Hyperledger Fabric would provide intermediate latency (1–3 seconds based on 11 ) with predictable transaction costs and consortium-level identity management. Cryptographic performance analysis Figure 7 presents comprehensive cryptographic performance metrics. For 1 MB test files across 100 operations, the hybrid encryption protocol achieved mean encryption time of 245.7ms with throughput of 4.07 MB/s. Decryption performance showed improvement (198.3ms mean time, 5.04 MB/s throughput) due to optimized AES-CBC implementation and cached elliptic curve parameters. Figure 7. Open in a new tab Real-time performance metrics across 100 file operations: ( a ) encryption times 245.7 ± 18.4ms, ( b ) decryption times 198.3 ± 15.2ms, ( c ) throughput 4.07 MB/s (encryption) and 5.04 MB/s (decryption), ( d ) resource utilization. Table 5 details the computational cost of individual cryptographic components. Paillier homomorphic encryption dominated encryption overhead (63.6% of sequential time) due to modular exponentiation with 2048-bit modulus. The wall-clock encryption time (245.7 ms) is less than the sum of individual operation times (294.2 ms) because Paillier keyword encryption executes in parallel with ECC key encapsulation and ECDSA signature generation using Python’s concurrent.futures thread pool; this parallelization saves approximately 48.5 ms per operation. ECC key decapsulation required 89.4 ms, including 28.9 ms for point reconstruction via Tonelli-Shanks algorithm, representing 45.1% of decryption time. Paillier keyword decryption adds 26.3 ms to the decryption pipeline for recovering plaintext keyword hashes during client-side search operations. Table 5. Cryptographic operation breakdown for 1MB files (n = 100). Operation Mean time (ms) Std dev (ms) AES-256 encryption 87.3 6.2 ECC key encapsulation 34.6 4.1 ECDSA signature generation 12.8 2.1 Paillier keyword encryption 156.3 9.7 HMAC-SHA256 computation 3.2 0.5 Sum of individual operations 294.2 – Total encryption (wall-clock) 245.7 18.4 AES-256 decryption 71.2 5.8 ECC key decapsulation 89.4 7.3 ECDSA signature verification 8.6 1.4 HMAC-SHA256 verification 2.8 0.4 Paillier keyword decryption 26.3 3.1 Point reconstruction (Tonelli–Shanks) 28.9 3.2 Total decryption 198.3 15.2 Open in a new tab Paillier keyword encryption executes in parallel with ECC key encapsulation and ECDSA signature generation on separate threads; wall-clock total is less than the sum of sequential components. Time complexity verification Figure 8 validates the theoretical complexity analysis through empirical measurements. Log-log regression across input sizes from 1KB to 32KB confirmed linear complexity for core operations: encryption (slope=0.98, =0.997), decryption (slope=1.01, =0.995), and ECDSA signature generation (slope=1.06, =0.993). Paillier homomorphic operations exhibited expected quadratic behavior (slope=1.94, =0.989) inherent to modular exponentiation with the 2048-bit Paillier modulus; the factor reflects per-keyword modular exponentiation cost where k denotes keywords per file, rather than pairwise keyword interaction. Blockchain operations demonstrated constant-time performance (slope=0.08, =0.012), as smart contract gas costs remain independent of file size. Figure 8. Open in a new tab Empirical time complexity analysis on log-log scale demonstrating: ( a ) Encryption O ( n ) with slope 0.98 ( =0.997), ( b ) Decryption O ( n ) with slope 1.01 ( = 0.995), ( c ) ECDSA signature generation O ( n ) with slope 1.06 ( = 0.993), ( d ) Paillier operations with slope 1.94 ( = 0.989), ( e ) Blockchain operations O (1) with slope 0.08 ( = 0.012), ( f ) Storage distribution O ( n ) with slope 1.02 ( = 0.994). File sizes range from 1KB to 32KB. Table 6 summarizes regression analysis results with high goodness-of-fit ( ) for all operations except blockchain registration, confirming theoretical predictions. The near-zero slope for blockchain operations validates that smart contract execution cost remains constant regardless of file size, as only hash values are stored on-chain. Table 6. Empirical time complexity classification. Operation Slope Class File encryption 0.98 0.997 O ( n ) File decryption 1.02 0.995 O ( n ) ECDSA signature generation 1.06 0.993 O ( n ) ECDSA signature verification 0.97 0.991 O ( n ) Paillier encryption 1.94 0.989 Blockchain registration 0.08 0.012 O (1) Storage distribution 1.03 0.994 O ( n ) Open in a new tab Key management and version control Figure 9 demonstrates the key generation interface with UUID-based versioning. The system successfully generated and managed 500 distinct key bundles, with serialization to JSON format requiring 2.3 ± 0.4ms per bundle and deserialization requiring 1.8 ± 0.3ms. Key file sizes averaged 3.2 KB, enabling efficient storage and transfer. Figure 9. Open in a new tab Cryptographic key generation interface showing UUID-based key versioning system. Each bundle contains four key pairs: ECC (brainpoolP256r1, 256-bit security), ECDSA (SECP256k1), Paillier (2048-bit modulus, 112-bit security), and deterministic AES-256. The key versioning system (Fig. 10 ) prevented all 1,000 attempted decryptions with mismatched keys, achieving 100% accuracy with mean detection time of 0.8ms. This early-abort mechanism reduced wasted computation by avoiding expensive cryptographic operations with incorrect keys. Figure 10. Open in a new tab Key mismatch detection mechanism preventing decryption failures. The system achieved 100% accuracy in detecting key mismatches across 1,000 test cases with mean detection time of 0.8ms. Homomorphic keyword search performance Figure 11 illustrates the homomorphic keyword search functionality with comprehensive evaluation. Across a database of 100 files with average 5 keywords per file (500 encrypted keyword hashes total), search operations completed in 847ms with 100% precision and recall. The search time is dominated by Paillier decryption (743ms, 87.7%) with hash comparison requiring only 104ms. The complexity where m =files and n =keywords per file is confirmed by the linear scaling shown in Fig. 11 c, and per-file encryption times visible in the search results (239.5–251.3ms) are consistent with the reported mean of 245.7ms. Figure 11. Open in a new tab Privacy-preserving keyword search evaluation: ( a ) search interface showing 7 matching results across 100 encrypted files with per-file encryption times consistent with reported 245.7ms mean, ( b ) search time breakdown showing Paillier decryption dominates at 87.7%, ( c ) search latency scaling linearly with file count confirming complexity, ( d ) precision and recall maintaining 100% across file counts. Blockchain-based access control Figures 12 and 13 demonstrate the blockchain-based access control mechanism. The grantAccess() and revokeAccess() functions achieved 100% success rate across 500 test transactions, with mean execution times of 134.2ms and 98.4ms respectively. The audit trail provided complete traceability with immutable records stored on-chain, enabling forensic analysis of all permission changes. Figure 12. Open in a new tab Access control transaction workflow showing smart contract-based permission management with cryptographic proof via Ethereum addresses. Figure 13. Open in a new tab Immutable audit trail retrieved from FileRegistry smart contract showing events with Unix timestamps and Ethereum addresses for complete accountability. Storage overhead analysis Figure 14 quantifies storage overhead across various file sizes. The mean overhead of 7.3% decomposed as: PKCS#7 padding (2.1%), IV storage (variable, decreasing with file size), size header (0.3% for 1MB files), and ECC point storage (4.9%). For files larger than 10MB, overhead asymptotically approached 5.2%, confirming efficient scaling properties. Figure 14. Open in a new tab Storage overhead analysis: ( a ) overhead versus file size showing convergence to asymptotic 5.2% for large files, ( b ) overhead component breakdown for 1MB files showing ECC point storage as dominant factor, ( c ) overhead distribution across 100 file operations with mean 7.3%. Comparative analysis Table 7 benchmarks the proposed framework against state-of-the-art blockchain-based cloud storage and hybrid encryption systems. Baseline systems were selected based on architectural relevance (cryptographic encryption with blockchain integrity), publication in peer-reviewed venues, and availability of quantitative performance metrics enabling direct comparison. Table 7. Performance comparison with state-of-the-art systems. System Encrypt (ms) Decrypt (ms) OH (%) Blockchain Consensus TPS Crypto Key features Ours 245.7 198.3 7.3 Ganache 287ms 85/grp AES-256+HMAC, ECC, Paillier HE keywords, Dynamic TPA Lu et al. 11 312 289 8.9 Fabric 3000ms – Bilinear, Pedersen PDP, Static TPA, CDH Liu et al. 7 – – – Ethereum 9600ms 15 SHA-256, AES Challenge-response Yeboah 8 200 180 – Ethereum 15000ms 15 AES-256-CBC Immutable logs Shakor 12 442 398 – Ethereum – – Dynamic AES, ECC Dynamic keys Chen et al. 9 285 251 – Fabric+IPFS – – AES-128, ECC-256 HAE hybrid Popoola 10 6 6 – None N/A N/A AES-EAX, ECC IND-CCA2, MITM Gaitond 21 1230 1600 – Consortium – 250 Paillier, GGO-CO Shamir sharing Open in a new tab Ganache development network with instant mining; production deployment latency would be higher. Scaled from 5MB measurements. Includes 1.8 overhead vs static AES. Encryption time only, excludes key exchange overhead; evaluated without blockchain Our system achieves 21.2% faster encryption than Lu et al.’s HF-Audit (245.7ms vs. 312ms) through ECC point compression, cached elliptic curve parameters, and parallelized Paillier operations. The 7.3% storage overhead improves upon Lu et al.’s 8.9% through PKCS#7 minimization and compressed point storage. Note that consensus latency comparisons should be interpreted cautiously: our 287ms measurement on Ganache development network represents an optimistic baseline, as production deployment on Hyperledger Fabric or public Ethereum would exhibit higher latency consistent with the values reported by Lu et al. (3000ms on Fabric) and Liu et al. (9600ms on Ethereum). Consensus performance on the Ganache development network demonstrated 287ms mean confirmation time, though this represents an optimistic lower bound due to instant block mining without network latency or competing transactions. Production deployment on permissioned networks such as Hyperledger Fabric would exhibit consensus latency in the 1–3 second range based on prior work 11 . Our 85 TPS per group throughput provides improvement over public Ethereum’s 15 TPS, validating the consortium blockchain approach for cloud storage applications while maintaining decentralization benefits through permissioned membership. Security feature analysis reveals our system uniquely combines homomorphic keyword encryption with dynamic TPA selection and authenticated encryption (AES-CBC+HMAC)-Popoola et al. provides IND-CCA2 via AES-EAX but omits blockchain integrity, while Lu et al. offers dynamic TPA without privacy-preserving keyword encryption. No compared system addresses post-quantum readiness, representing a universal research gap requiring future migration to lattice-based primitives (Kyber, Dilithium). The primary trade-off is post-quantum vulnerability shared with all ECC-based schemes. Public blockchain systems (Liu, Yeboah-Ofori, Shakor) maximize decentralization at the cost of higher latency and variable gas costs, while non-blockchain systems (Popoola) optimize performance but reintroduce centralized trust vulnerabilities. Our approach balances these extremes through smart-contract-based integrity verification, with a clear migration path to permissioned consortium networks for enterprise-grade deployments requiring identity management and transaction privacy. Discussion Security properties and validation The experimental evaluation validates the core security properties of the proposed framework. Public auditability achieved 100% success in detecting tampered data across 500 integrity challenges, demonstrating the effectiveness of blockchain-based hash verification. Traceability through the immutable blockchain ledger enabled correct identification of malicious actors in all 50 simulated attack scenarios with mean trace time of 1.2 seconds. Transaction pseudonymity is provided through Ethereum address management; production deployment on Hyperledger Fabric would enhance privacy through Identity Mixer, enabling unique pseudonyms per transaction to prevent transaction linkage in consortium networks. The cryptographic protocol successfully prevented data recovery attempts from challenge-proof pairs across 1,000 test cases, validating the computational hardness assumptions underlying the hybrid AES-ECC-Paillier construction. Collusion resistance measurements aligned with theoretical predictions from hypergeometric modeling, achieving versus the predicted for dynamic TPA selection with 10 colluding auditors among 100 candidates. While this empirical measurement is consistent with the analytical model, comprehensive validation across diverse coalition sizes and repeated trials would be needed to establish formal collusion resistance guarantees. These results confirm that the system achieves its design objectives of confidentiality, integrity, and decentralized verification under the honest-but-curious adversary model. The security analysis assumes static adversarial coalitions and honest majority among blockchain validators. Byzantine fault scenarios involving coordinated consensus manipulation remain outside the current threat model. Future work should extend security analysis to adaptive adversaries and implement zero-knowledge proof-based TPA selection to further strengthen collusion resistance. Extended Threat Analysis Under Adaptive Adversaries While the primary threat model assumes honest-but-curious adversaries with static coalitions, we extend the analysis to three classes of adaptive attacks to characterize system resilience beyond the baseline model. Timing channel analysis. Encryption time variance ( ms for 1 MB files) could theoretically leak information about keyword count, as Paillier encryption time scales with k keywords. Mitigation requires constant-time padding: all encryption operations are padded to a fixed execution time ceiling (e.g., 400 ms) through calibrated busy-wait loops, eliminating timing-based information leakage at the cost of reduced average throughput. We measured that keyword count correlates with encryption time at ( ), confirming the practical relevance of this side channel for files with highly variable keyword counts. Consensus delay exploitation. The mean 287ms confirmation window on Ganache (projecting to 1–3 seconds on Hyperledger Fabric and 12–30 seconds on public Ethereum) creates a theoretical race condition between file upload and blockchain hash anchoring. An adversary with network-level access could substitute file content before hash registration completes. A commit-reveal mitigation broadcasts an immediate hash commitment (via a lightweight pre-registration transaction), with full registration completing upon block inclusion, reducing the effective vulnerability window to sub-second network propagation latency. Byzantine failure resilience. Under the hypergeometric TPA selection model with 60-node leadership group and 10 auditors selected per verification round, Byzantine corruption degrades collusion resistance gracefully. Figure 15 presents the quantitative analysis: at 10% corruption, ; at 20%, ; at 30%, . These values remain below the threshold considered acceptable in audit protocol literature 11 , providing quantitative resilience guarantees under moderate Byzantine corruption. The collusion resistance parameter degrades linearly with corruption rate up to 25%, beyond which degradation accelerates, establishing 20% corruption as the practical security boundary for the current TPA pool size. Figure 15. Open in a new tab Collusion resistance under Byzantine corruption: ( a ) probability of selecting a majority-corrupt audit committee versus corruption rate, with 5% and 1% safety thresholds; ( b ) collusion resistance parameter degradation showing the design operating point at 15% corruption ( ) and the practical security boundary at 20% corruption ( ). Parameters: TPA candidates, selected per round. Compositional Security Argument While a full Universal Composability (UC) proof for the multi-primitive hybrid protocol is beyond the scope of this systems-oriented work and represents a substantial open problem in theoretical cryptography, we provide a modular security reduction demonstrating that the composition preserves individual primitive guarantees. Figure 16 illustrates the compositional security architecture. Figure 16. Open in a new tab Compositional security architecture: each cryptographic primitive satisfies its individual security notion under standard assumptions; the encrypt-then-MAC construction achieves IND-CCA2 via the Bellare-Namprempre framework, composed with ECIES key encapsulation under the KEM-DEM paradigm, Paillier homomorphic encryption under DCRA, and blockchain-based integrity verification under BFT consensus. Each cryptographic component satisfies its standard security notion: AES-256-CBC achieves IND-CPA security under the pseudorandom permutation assumption; HMAC-SHA256 provides INT-CTXT (ciphertext integrity) under the PRF assumption for SHA-256; ECIES on brainpoolP256r1 achieves IND-CCA2 security under the Gap Diffie-Hellman assumption; ECDSA provides EUF-CMA (existential unforgeability under chosen message attacks) under the discrete logarithm assumption on SECP256k1; and Paillier encryption achieves IND-CPA security under the Decisional Composite Residuosity Assumption (DCRA). The encrypt-then-MAC construction (AES-256-CBC followed by HMAC-SHA256) achieves IND-CPA INT-CTXT IND-CCA2 security following the Bellare-Namprempre framework 36 . The sequential composition of ECIES key encapsulation with the authenticated symmetric cipher preserves IND-CCA2 security under the KEM-DEM paradigm 37 , provided independent randomness sources are used for each primitive—a condition satisfied by our use of separate CSPRNG invocations for AES key generation, ephemeral ECC scalar selection, and Paillier random blinding factors. Constructing a formal UC ideal functionality composing all five primitives with blockchain-based verification remains an important direction for future theoretical work. Collusion Resistance Under Adversarial Conditions We provide explicit quantification of collusion resistance assumptions and failure boundaries for the dynamic TPA selection mechanism. Minimum honest auditor threshold. For the 60-node leadership group with 10 auditors selected per verification round, the hypergeometric model requires at least 51 honest auditors (85%) to maintain with 95% confidence. Below this threshold, the probability of selecting a majority-corrupt audit committee exceeds acceptable bounds. Failure probability under varying corruption. Table 8 presents failure probabilities for progressive corruption ratios, derived from the hypergeometric distribution where K denotes the number of Byzantine nodes. Table 8. Collusion resistance under byzantine corruption ( , ). Corruption (%) Corrupt nodes P (majority-corrupt) 5% 3/60 0.0001 0.012 10% 6/60 0.0013 0.028 15% 9/60 0.0089 0.049 20% 12/60 0.0234 0.083 25% 15/60 0.0512 0.127 30% 18/60 0.0891 0.184 Open in a new tab Adaptive TPA compromise. The current static selection model does not account for adversaries who progressively compromise auditors over time. Three mitigation strategies are identified for future implementation: (i) periodic auditor rotation with cryptographic commitment to selection randomness preventing adversarial prediction of future committees; (ii) reputation scoring with exponential decay penalizing auditors whose verification results diverge from majority consensus; and (iii) threshold signatures requiring k -of- n auditor agreement, ensuring that compromising fewer than k auditors provides no advantage. Formally proving the security of these mechanisms against adaptive adversaries constitutes significant future work. Performance analysis and scalability The distributed storage architecture demonstrated strong scalability characteristics with linear performance scaling as node count increased from 5 to 20. Per-operation latency remained constant at 23.4ms ± 2.1ms while aggregate throughput increased proportionally, validating the effectiveness of hash-based load balancing. The blockchain layer achieved 85 TPS per group throughput on Ganache development network with 287ms mean confirmation time, while Sepolia public testnet validation (Table 4 ) confirmed identical gas consumption with 15.3-second mean confirmation latency under realistic network conditions. As shown in the network projection analysis (Fig. 5 ), production deployment on permissioned blockchain networks such as Hyperledger Fabric would exhibit latency in the 1–3 second range based on 11 . The cryptographic protocol overhead (245.7ms) dominates per-file processing cost regardless of blockchain backend, as blockchain registration is a one-time operation per file. The cryptographic protocol achieved 245.7ms encryption time for 1MB files, outperforming comparable hybrid encryption schemes by 21.2% through three key optimizations: ECC point compression reducing storage and transmission overhead, cached elliptic curve parameters reducing repeated computation, and parallelized Paillier keyword encryption leveraging multi-core processors via thread pooling. The 7.3% storage overhead represents best-in-class efficiency for systems providing equivalent security guarantees. Performance bottlenecks were identified in Paillier homomorphic encryption, which dominated total encryption time at 63.6% due to per-keyword complexity arising from modular exponentiation with the 2048-bit Paillier modulus (where k denotes keywords per file). For files with 100+ keywords, encryption time exceeded practical thresholds. The current client-side search implementation requires Paillier decryption at the client before keyword matching, which preserves database-side privacy but does not achieve fully server-side privacy-preserving search. Future optimizations should explore: (1) deterministic encryption for non-sensitive keywords combined with Paillier for privacy-critical terms, reducing average-case complexity; (2) alternative partial homomorphic schemes (e.g., ElGamal, Lifted ElGamal) offering complexity; and (3) server-side searchable encryption protocols that enable matching without client-side decryption. Deployment considerations Transitioning from experimental development network to production deployment requires addressing several practical considerations. The Ganache-based evaluation provides deterministic performance baselines, while our Sepolia public testnet validation confirms identical gas consumption and 100% contract execution success under realistic network conditions (Table 4 ). The analytical network projection (Fig. 5 ) demonstrates that transaction latency scales predictably with consensus mechanism complexity. Production deployments would require either (a) a permissioned blockchain network such as Hyperledger Fabric with geographically distributed orderers, exhibiting latency of 1–3 seconds based on prior work but providing consortium-level identity management and endorsement policies, or (b) a private Ethereum network with Clique/Aura proof-of-authority consensus providing 3–8 second block times while maintaining multi-node validation. For cost-sensitive applications, both approaches offer predictable transaction costs versus public Ethereum’s variable gas fees ($5–50 per transaction during congestion periods). Key management represents a critical operational concern requiring robust backup and recovery procedures. The current UUID-based key versioning enables cryptographic agility but requires integration with enterprise key management systems or hardware security modules for production deployment. Future work should implement split-key recovery protocols enabling authorized key reconstruction while preventing single-point compromise. Regulatory compliance frameworks (GDPR, HIPAA, CCPA) impose requirements that partially align with the system’s capabilities. The encryption-at-rest satisfies confidentiality requirements, blockchain audit trails provide tamper-evident logging for HIPAA compliance, and role-based access control supports least-privilege principles. However, GDPR’s right-to-erasure conflicts with blockchain immutability-registered file hashes constitute persistent records. Practical solutions include off-chain hash storage with blockchain anchoring or cryptographic erasure techniques where destroying encryption keys renders data permanently inaccessible. Legal consultation is recommended before deploying in jurisdictions with strict data protection requirements. Limitations and future work Three primary limitations warrant future research: Post-Quantum Vulnerability. The ECC-based components (brainpoolP256r1, SECP256k1) remain vulnerable to Shor’s quantum algorithm. Migration to NIST-standardized post-quantum primitives (Kyber for key encapsulation, Dilithium for signatures) is essential for long-term security. Preliminary estimates suggest 20-40% performance overhead based on NIST PQC benchmarks, which is acceptable for the security benefits provided. Paillier homomorphic encryption faces similar quantum threats requiring exploration of lattice-based alternatives (BGV, BFV, CKKS), though current implementations impose 10-100 overhead necessitating algorithmic innovations. Metadata Privacy. While file content remains confidential, system metadata (file sizes, timestamps, access patterns) is observable. Advanced adversaries could infer information through traffic analysis or frequency analysis of encrypted keyword searches. Enhanced privacy requires techniques such as padding to uniform ciphertext sizes, temporal obfuscation of blockchain transactions, and searchable encryption with forward secrecy. These enhancements involve performance-privacy trade-offs requiring careful evaluation in specific deployment contexts. Scalability Optimization. The Paillier keyword encryption bottleneck limits throughput for keyword-intensive applications. The current client-side search implementation requires Paillier decryption at the client, which, while preventing server-side frequency analysis on stored ciphertexts, does not achieve fully server-side privacy-preserving search. Hybrid approaches combining deterministic encryption for non-sensitive keywords with homomorphic encryption for privacy-critical terms could reduce average-case complexity while maintaining privacy guarantees for sensitive metadata. Additionally, the five-node storage architecture provides sufficient redundancy for experimental validation but should scale to distributed content-delivery networks for enterprise deployments handling petabyte-scale data. Contributions to the state-of-the-art This work advances privacy-preserving cloud storage through three principal contributions: (1) A working integration of hybrid AES-ECC encryption with HMAC authentication and Paillier keyword encryption, combined with Ethereum smart contract-based integrity verification, validated through comprehensive implementation rather than simulation, demonstrating architectural feasibility for blockchain-based cloud storage. (2) Rigorous empirical complexity analysis across file sizes from 1KB to 32KB with log-log regression validation ( ), establishing that core operations scale as predicted by theoretical analysis. (3) Empirical collusion resistance measurement through hypergeometric modeling, providing quantitative security characterization ( ) for dynamic TPA selection versus qualitative security arguments in prior work. The comparative evaluation demonstrates 21.2% faster encryption than comparable blockchain-based systems on equivalent hardware. Blockchain consensus measurements on the Ganache development network established baseline latency of 287ms, with production deployment on permissioned networks expected to provide higher latency but enhanced security features. The 7.3% storage overhead represents efficient utilization of cryptographic primitives while maintaining IND-CPA confidentiality with HMAC-based integrity, EUF-CMA authenticity, and blockchain-enforced tamper detection. The system demonstrates feasibility for medium-scale deployments (10-100 users, <10TB data) with a clear migration path to permissioned blockchain networks for enterprise environments. Identified optimization pathways-post-quantum cryptography migration, metadata privacy enhancements, server-side homomorphic search, and multi-user concurrent access testing-provide clear directions for scaling to larger deployments and strengthening security against advanced threat models. The open challenges identified contribute to the research community’s understanding of trade-offs inherent in privacy-preserving cloud storage architectures. Conclusion This paper presented a privacy-preserving cloud storage framework integrating hybrid AES-ECC encryption with HMAC authentication, Paillier homomorphic keyword encryption, and Ethereum smart contract-based blockchain integrity verification. The system addresses the fundamental trilemma in encrypted cloud storage: balancing confidentiality, functionality, and performance. Our hybrid cryptographic protocol achieved 245.7ms encryption and 198.3ms decryption for 1MB files with 7.3% storage overhead, outperforming comparable systems by 21.2% while maintaining IND-CPA confidentiality with HMAC-based ciphertext authentication. The Paillier-based keyword encryption prevents frequency analysis through probabilistic ciphertext generation, with client-side search operations over 100 encrypted files completing in 847ms. Leveraging Ethereum smart contracts deployed on the Ganache development network, the system achieved 85 TPS per group throughput with 287ms consensus latency and empirical collusion resistance measurement ( ) consistent with hypergeometric model predictions for dynamic TPA selection. The framework is designed for migration to permissioned blockchain networks such as Hyperledger Fabric for production deployments requiring consortium identity management and transaction privacy. Comprehensive evaluation validated the theoretical complexity analysis through empirical log-log regression ( ), confirming O ( n ) scaling for encryption operations and O (1) blockchain operations across file sizes from 1KB to 32KB. The distributed storage architecture demonstrated uniform load balancing across five nodes with variance . Security validation confirmed 100% tampered-data detection across 500 integrity challenges and successful traceability in all 50 simulated attack scenarios. Three limitations warrant future work: post-quantum vulnerability requiring migration to lattice-based primitives (Kyber, Dilithium), Paillier’s complexity limiting keyword-intensive applications, and the need for server-side homomorphic search to eliminate client-side decryption during keyword queries. Despite these challenges, the system demonstrates feasibility for medium-scale deployments within blockchain-integrated cloud storage architectures. This work contributes rigorous empirical validation of hybrid cryptographic protocols with blockchain integrity verification, providing concrete performance baselines and quantified security characterization for privacy-preserving cloud storage. The identified optimization pathways offer clear directions for scaling to larger deployments and strengthening protection against advanced adversaries. Author contributions Haitham M. A. Ahmed: Conceptualization, Methodology, Software, Investigation, Data Curation, Writing – Original Draft, Visualization. Swaleha Zubair: Supervision, Validation, Writing – Review & Editing, Formal Analysis. Mohammed Tawfik: Methodology, Formal Analysis, Writing – Review & Editing, Validation, Project Administration Funding This research received no external funding. Data availability The datasets generated and analysed during the current study, along with the full implementation source code, are publicly available on GitHub at: https://github.com/kmkholm/Data-Privacy-Preserving-Cloud-Storage-Hybrid-Encryption-Blockchain. The repository includes cryptographic performance benchmarks, blockchain transaction logs, distributed storage metrics, homomorphic keyword search evaluation results, and the complete Python implementation of the proposed framework. Additional data and code not included in the repository are available from the corresponding author, Mohammed Tawfik (m.tawfik@su.edu.ye), upon reasonable request. Declarations Competing interests The authors declare no competing interests. Footnotes Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. References 1. Kamara, S. & Lauter, K. Cryptographic cloud storage. In Proc. Financial Cryptography and Data Security (FC) , vol. 6054 of LNCS , 136–149 (Springer, 2010). 2. Gentry, C. Fully homomorphic encryption using ideal lattices. In Proc. 41st ACM Symp. Theory of Computing (STOC) , 169–178 (2009). 3. Song, D. X., Wagner, D. & Perrig, A. Practical techniques for searches on encrypted data. In Proc. IEEE Symp. Security and Privacy (S&P) , 44–55 (2000). 4. Islam, M. S., Kuzu, M. & Kantarcioglu, M. Access pattern disclosure on searchable encryption: Ramification, attack and mitigation (In Proc, NDSS, 2012). [ Google Scholar ] 5. Ateniese, G. et al. Provable data possession at untrusted stores. In Proc. ACM CCS , 598–609 (2007). 6. Juels, A. & Kaliski Jr., B. S. PORs: Proofs of retrievability for large files. In Proc. ACM CCS , 584–597 (2007). 7. Liu, B., Yu, X. L., Chen, S., Xu, X. & Zhu, L. Blockchain based data integrity service framework for IoT data. In Proc. IEEE 24th Int. Conf. Web Services (ICWS) , 468–475 (2017). 8. Yeboah-Ofori, A., Sadat, S. K. & Darvishi, I. Blockchain security encryption to preserve data privacy and integrity in cloud environment. In Proc. IEEE 10th Int. Conf. FICloud , 1–9 (2023). 9. Chen, Z., Gu, J. & Yan, H. HAE: A hybrid cryptographic algorithm for blockchain medical scenario applications. Appl. Sci. 13 , 12163 (2023). [ Google Scholar ] 10. Popoola, O. et al. An optimized hybrid encryption framework for smart home healthcare. Internet of Things 27 , 101314 (2024). [ Google Scholar ] 11. Lu, N., Zhang, Y., Shi, W., Kumari, S. & Choo, K.-K.R. A secure and scalable data integrity auditing scheme based on Hyperledger Fabric. Comput. Secur. 92 , 101741 (2020). [ Google Scholar ] 12. Shakor, M. Y., Khaleel, M. I., Safran, M., Alfarhood, S. & Zhu, M. Dynamic AES encryption and blockchain key management for cloud data security. IEEE Access 12 , 26334–26343 (2024). [ Google Scholar ] 13. Kumar, P. & Bhatt, A. K. Enhancing multi-tenancy security in the cloud using hybrid ECC-based data encryption. IET Commun. 14 , 3212–3222 (2020). [ Google Scholar ] 14. Ghayvat, H. et al. CP-BDHCA: Blockchain-based confidentiality-privacy preserving big data scheme for healthcare clouds. IEEE J. Biomed. Health Inform. 26 , 1937–1948 (2022). [ DOI ] [ PubMed ] [ Google Scholar ] 15. Meenakshi, A. et al. A multi layered encryption framework using intuitionistic fuzzy graphs and graph theoretic domination for secure communication networks. Sci. Rep. 15 , 20992 (2025). [ DOI ] [ PMC free article ] [ PubMed ] [ Google Scholar ] 16. Awasthi, V., Agnihotri, A. K., Singh, V., Tiwari, S. & Kumar, S. Optimized lightweight AES for IoT security using dynamic S-Box and ARX-based diffusion. Int. J. Inf. Commun. Eng. 19 , 399–407 (2025). [ Google Scholar ] 17. Wang, H. & Chen, X. Improve the privacy of AES encryption algorithm in cloud computing. In Proc. 4th Int. Workshop IWMECS , 328–332 (2019). 18. Peddi, P. Data sharing privacy in mobile cloud using AES. Int. J. Sci. Res. Comput. Sci. Appl. Manag. Stud. 7 , 1–8 (2018). [ Google Scholar ] 19. Hong, M., Zhao, W. & Wang, P. Homomorphic encryption scheme based on ECC for privacy protection of cloud computing (In Proc, CSNT, 2016). [ Google Scholar ] 20. Kanna, G. P. & Vasudevan, V. A fully homomorphic-elliptic curve cryptography based encryption algorithm for cloud data privacy. Clust. Comput. 22 , S9561–S9569 (2019). [ Google Scholar ] 21. Gaitond, R., Biradar, G. S. & Terdal, S. Blockchain-integrated optimized cryptographic framework for securing cloud data. Knowl.-Based Syst. 324 , 113830 (2025). [ Google Scholar ] 22. Xiao, Y. et al. Privacy protection anomaly detection in smart grids based on combined PHE and TFHE. Electronics 14 , 2386 (2025). [ Google Scholar ] 23. Murthy, S. & Kavitha, C. R. Preserving data privacy in cloud using homomorphic encryption. In Proc. ICECA , 1131–1135 (2019). 24. Hammami, H., Brahmi, H., Brahmi, I. & Ben Yahia, S. Using homomorphic encryption to compute privacy preserving data mining in a cloud computing environment. In Proc. EMCIS 2017, LNBIP , vol. 299, 397–413 (2017). 25. Zhu, X. et al. Application of machine learning methods for estimating and comparing the sulfur dioxide absorption capacity of deep eutectic solvents. J. Cleaner Prod. 363 , 132465 (2022). [ Google Scholar ] 26. Yuan, H., Feng, K., Li, W. & Sun, X. Multi-objective optimization of virtual energy hub plant integrated with data center and plug-in electric vehicles. J. Cleaner Prod. 363 , 132365 (2022). [ Google Scholar ] 27. Zhu, Y., Gan, G., Guo, R. & Huang, D. PHE: An efficient traitor tracing and revocation for encrypted file syncing-and-sharing in cloud. IEEE Trans. Cloud Comput. 10.1109/TCC.2016.2573299 (2016). [ Google Scholar ] 28. Shukla, S. & Patel, S. J. A novel ECC-based provably secure multi-factor authentication protocol for cloud computing. Computing 104 , 1173–1202 (2022). [ Google Scholar ] 29. Tawfik, M., Abdelhaliem, A. H. & Fathi, I. S. Quantum-resistant privacy-preserving IoT authentication via zero-knowledge proofs and blockchain integration (Stat. Optim. Inf, Comput, 2025). [ Google Scholar ] 30. Gai, K., Qiu, M. & Zhao, H. Privacy-preserving data encryption strategy for big data in mobile cloud computing. IEEE Trans. Big Data 10.1109/TBDATA.2017.2705807 (2017). [ Google Scholar ] 31. Bellare, M., Boldyreva, A. & O’Neill, A. Deterministic and efficiently searchable encryption. In Proc. CRYPTO 2007, LNCS , vol. 4622, 535–552 (Springer, 2007). 32. Shanks, D. Five number-theoretic algorithms. In Proc. Second Manitoba Conf. Numerical Mathematics , 51–70 (1973). 33. Karger, D. et al. Consistent hashing and random trees. In Proc. 29th ACM STOC , 654–663 (1997). 34. Zhang, Y., Kasahara, S., Shen, Y., Jiang, X. & Wan, J. Smart contract-based access control for the internet of things. IEEE Internet Things J. 6 , 1594–1605 (2019). [ Google Scholar ] 35. Di Francesco Maesa, D., Mori, P. & Ricci, L. Blockchain based access control. In Proc. 17th IFIP WG 12.5 DAIS, LNCS , vol. 10320, 206–220 (Springer, 2017). 36. Bellare, M. & Namprempre, C. Authenticated encryption: Relations among notions and analysis of the generic composition paradigm. In Proc. ASIACRYPT 2000, LNCS , vol. 1976, 531–545 (Springer, 2000). 37. Shoup, V. A proposal for an ISO standard for public key encryption (version 2.1). ISO/IEC JTC1/SC27 (2001). Associated Data This section collects any data citations, data availability statements, or supplementary materials included in this article. Data Availability Statement The datasets generated and analysed during the current study, along with the full implementation source code, are publicly available on GitHub at: https://github.com/kmkholm/Data-Privacy-Preserving-Cloud-Storage-Hybrid-Encryption-Blockchain. The repository includes cryptographic performance benchmarks, blockchain transaction logs, distributed storage metrics, homomorphic keyword search evaluation results, and the complete Python implementation of the proposed framework. Additional data and code not included in the repository are available from the corresponding author, Mohammed Tawfik (m.tawfik@su.edu.ye), upon reasonable request. Articles from Scientific Reports are provided here courtesy of Nature Publishing Group ACTIONS View on publisher site PDF (7.8 MB) Cite Collections Permalink RESOURCES Similar articles Cited by other articles Links to NCBI Databases Follow NCBI NCBI on X (formerly known as Twitter) NCBI on Facebook NCBI on LinkedIn NCBI on GitHub NCBI RSS feed Connect with NLM NLM on X (formerly known as Twitter) NLM on Facebook NLM on YouTube National Library of Medicine 8600 Rockville Pike Bethesda, MD 20894 Web Policies FOIA HHS Vulnerability Disclosure Help Accessibility Careers NLM NIH HHS USA.gov Back to Top

Related documents

• Engaging Trust and Security Saving E-KYC System Using Blockchain#78245
• Mitigating 51% Attacks in Blockchain Systems Through Early Detection and Checkpoint-Based Defense#1084604
• Method for protecting data used in cloud computing with homomorphic encryption — Parallels IP Holdings GmbH (US8925075B2)#607508
• Cloud computing and its ethical challenges#773973
• Trust in the Balance: Data Protection Laws as Tools for Privacy and Security in the Cloud#461676