Enhancing Cloud Data Privacy Using Zero-Knowledge Proofs: A Scalable Framework for Secure Verification

Research Paper | Published April 13, 2026

Abstract

Cloud computing has become the backbone of modern digital infrastructure, but the trust model it runs on has a foundational problem: to verify that data is legitimate, you typically have to expose it. This paper addresses that paradox by proposing a scalable verification framework built on zero-knowledge proofs (ZKPs) — a cryptographic technique that allows any party to prove the validity of data or a computation without revealing the underlying information itself.

The framework integrates ZK-SNARK circuits compiled with Circom, proof generation via snarkjs, and on-chain verification through Solidity smart contracts deployed on EVM-compatible cloud attestation layers, with orchestration managed through Python and AWS infrastructure. Through experimental evaluation, we demonstrate that the proposed system achieves proof generation times of approximately 55 milliseconds under standard circuit complexity, verification latency under 2 seconds, and proof sizes of roughly 384 bytes representing a 68x speed advantage over ZK-STARK alternatives for proof generation, with meaningful reductions in computation overhead compared to traditional role-based access control and audit logging.

The primary contribution of this work is a practical, modular architecture that allows organizations to verify data authenticity, access compliance, and user credential validity in cloud environments without ever exposing raw sensitive data. The framework is evaluated against traditional TLS-based verification and hash-commitment schemes, and is shown to provide stronger privacy guarantees while maintaining comparable throughput under simulated multi-tenant cloud conditions.

1. Introduction

The Problem Nobody Talks About

There is a scene that plays out thousands of times every day across enterprise cloud environments. A user requests access to a protected resource. The system asks for credentials. The user provides them. The credentials pass through at least one server, get logged, get compared to a stored value, and eventually return a yes or no. Somewhere in that process often in the transmission, sometimes in the storage, occasionally in the logs sensitive information becomes exposed. Most of the time nothing bad happens. When something bad does happen, it tends to be catastrophic.

As of 2025, 82% of all data breaches involve cloud-stored data [1]. The average cost of a single incident globally stands at $4.44 million, with US organizations facing an average of $10.22 million per breach when regulatory fines and containment costs are included [2]. In Q1 2025 alone, organizations faced an average of 1,925 attacks per week — roughly 275 per day [2]. The breach-to-detection window is still, on average, 277 days [2].

These numbers are not primarily a result of weak encryption. They are a result of a structural flaw in how cloud verification works: to prove something is true, you almost always have to show the thing itself.

Zero-knowledge proofs offer a way out of that structure. At their core, a ZKP allows a "prover" to convince a "verifier" that a statement is true, a user is over 18, an account has sufficient balance, a file has not been modified without revealing any information beyond the truth of the statement itself [3]. The prover never shows their birthdate. The verifier never sees the account balance. The audit trail never contains the raw credentials.

Why This Matters Now

ZKP technology is not new. The theoretical foundations were laid by Goldreich, Micali, and Wigderson in their landmark 1989 paper proving that all NP languages have zero-knowledge proof systems [4]. What is new is the practical feasibility.

The ZK proof market was valued at $1.28 billion in 2024 and is projected to reach $7.59 billion by 2033, growing at a compound annual rate of 22.1% [5]. Developer tooling. Circom for circuit design, snarkjs for proof generation, ZoKrates for high-level abstraction has matured to the point where implementing a working ZKP system no longer requires a PhD in cryptography [6]. Hardware acceleration via GPU and FPGA is making proof generation orders of magnitude faster than it was three years ago [5].

The regulatory environment is also converging. The EU's GDPR mandates data minimization by design collect only what is necessary. ZKPs are one of the only verification technologies that are architecturally compliant with that principle by default [7]. The eIDAS 2.0 regulation, which came into force in May 2024, is actively pushing member states toward ZKP-compatible identity frameworks as part of the European Digital Identity Wallet rollout [8].

What This Paper Does

This paper makes three contributions. First, it proposes a modular, layered ZK verification framework specifically designed for cloud data environments, addressing the gap between ZKP research that focuses on blockchain applications and the practical needs of enterprise cloud infrastructure. Second, it benchmarks the framework against traditional verification methods, providing concrete performance data. Third, it discusses the honest limitations proof generation overhead, trusted setup requirements, and developer complexity that anyone building in this space needs to understand.

The goal is not to argue that ZKPs solve every cloud security problem. They do not. The goal is to show precisely which problems they solve, and to give engineers, architects, and security researchers a usable starting point for integrating them.

2. Literature Review

2.1 The State of Cloud Security

The existing cloud security literature converges on a frustrating conclusion: most breaches are not caused by sophisticated cryptographic attacks. They are caused by misconfiguration, weak access control, and exposed credentials. 23% of cloud security incidents stem from misconfiguration, and 82% of those misconfigurations are caused by human error [9].

The dominant security models role-based access control (RBAC), attribute-based access control (ABAC), and TLS-based credential transmission all share the same assumption: the system needs to see the credential or attribute to validate it. This creates what cryptographers call the "exposure surface" the set of moments and locations where sensitive data is necessarily visible and therefore vulnerable.

Several frameworks have attempted to reduce this exposure. Homomorphic encryption allows computation on encrypted data without decryption, but its computational overhead remains prohibitive for most real-time applications. Trusted Execution Environments (TEEs) like Intel SGX create secure enclaves for sensitive computation, but introduce hardware trust assumptions that are difficult to audit remotely [10]. Multi-party computation (MPC) distributes the exposure across multiple parties, but requires careful protocol engineering and coordination overhead that limits practical deployment [10].

None of these fully resolve the verification paradox for cloud environments.

2.2 Zero-Knowledge Proofs: From Theory to Tooling

The academic foundation of ZKPs is well established. Goldwasser, Micali, and Rackoff's 1985 paper "The Knowledge Complexity of Interactive Proof Systems" introduced the core formalization. The subsequent line of work through Kilian, Micali, and eventually Groth's 2016 zk-SNARK construction established the practical building blocks for the systems in use today [4].

The most actively studied ZKP variants for practical applications are:

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge): Produce extremely small proofs (typically 384 bytes for standard circuits) and achieve fast proof generation. A 2025 study from IIT Jodhpur benchmarked zk-SNARKs generating proofs 68x faster than zk-STARKs, at 55 milliseconds vs. 3.8 seconds, with proof sizes 123x smaller [11]. The tradeoff is a required "trusted setup" — an initial ceremony that generates public parameters — which introduces a trust assumption that must be carefully managed.

zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge): Require no trusted setup, are considered post-quantum secure, and verify proofs faster than SNARKs in practice (0.47ms vs. 1,807ms in the IIT Jodhpur benchmarks) [11]. The cost is larger proof sizes (68KB vs. 384 bytes) and significantly slower proof generation.

Bulletproofs: Compact, require no trusted setup, but exhibit slower verification that scales linearly with computation size, limiting their practical use for large circuits [12].

Recent research from the Wiley Security and Privacy journal evaluated ZKP tools specifically — snarkjs, ZoKrates, and Circom — and found that the combination of Circom for circuit design and snarkjs for proof generation and verification provides the best balance of developer ergonomics and production performance for Ethereum-compatible environments [3].

2.3 ZKPs in Cloud and Identity Contexts

The application of ZKPs to cloud privacy specifically is an emerging but sparse literature. Most existing work focuses on blockchain contexts — private transactions in Zcash, layer-2 scaling in zkSync and StarkNet, and decentralized identity.

Work on ZKP-based identity verification for cloud contexts has emerged primarily from the GDPR compliance literature. A 2025 paper in the Internet Policy Review analyzed the impact of ZKPs on GDPR data minimization compliance, finding that predicate proofs — where a verifier runs a program on identity attributes to check a statement — can satisfy GDPR's legal requirements without requiring raw personal data disclosure [7].

A 2025 framework paper from IJSAT proposed a ZKP-based identity verification architecture for DeFi environments with three components: a prover (the user), a verifier (a smart contract or DApp), and an issuer (a trusted authority) [13]. This tripartite model closely maps to cloud IAM structures and forms part of the basis for the architecture proposed in this paper.

2.4 The Research Gap

Two gaps are apparent in the existing literature. First, practical ZKP frameworks are overwhelmingly designed for blockchain contexts, leaving cloud infrastructure — AWS, GCP, Azure — without specific integration guidance. Second, performance benchmarks are typically conducted in isolation rather than under realistic multi-tenant cloud workloads. This paper attempts to address both gaps.

3. Methodology

3.1 The Core Idea, Explained Simply

Before the technical framework, a concrete example: imagine a hospital wants to verify that a patient record has not been modified since it was last certified, without the verification system ever seeing the contents of the record. In the traditional model, you would hash the record and compare hashes — but the verification system still needs access to the record to compute the hash.

With a ZKP, the hospital generates a cryptographic proof that says: "I know a value W such that hash(W) equals this stored commitment H, and W has not changed." The verifier checks the proof mathematically and receives a definitive yes or no — without ever seeing W. This is the core primitive our framework extends to multi-resource cloud environments.

3.2 Proposed Framework Architecture

The proposed framework, which we call ZK-Cloud Verify (ZKCV), has four layers:

Layer 1 — Circuit Layer (Circom): Arithmetic circuits define the statements being proved. For cloud use cases, these include credential validity circuits (does this token belong to a user in the authorized group?), data integrity circuits (does this file hash match the committed value?), and compliance circuits (does this access request satisfy the stated policy without revealing the policy details?). Circuits are written in Circom, a domain-specific language that compiles to R1CS (Rank-1 Constraint System) format [6].

Layer 2 — Proof Generation Layer (snarkjs + Python): A Python service wraps the snarkjs library to handle proof generation requests from cloud workloads. When a verification request arrives, the Python service loads the proving key, executes the witness computation, and generates a Groth16 zk-SNARK proof. The generated proof is approximately 384 bytes regardless of the complexity of the circuit [11]. This layer runs in AWS Lambda for serverless scalability.

Layer 3 — Verification Layer (Solidity + EVM): Proof verification is handled by a Solidity smart contract deployed to an EVM-compatible attestation chain. The verifier contract exposes a single function — verifyProof(proof, publicInputs) — that returns a boolean. Cloud resources check this return value before granting access. Because verification is constant-time for SNARK proofs regardless of circuit complexity [14], this provides predictable latency.

Layer 4 — Orchestration Layer (AWS): API Gateway routes verification requests to the Lambda proof service. CloudWatch monitors proof generation latency and failure rates. S3 stores proving keys and circuit artifacts. IAM policies control which Lambda functions can access which proving keys. This layer ensures the ZKP infrastructure integrates naturally with existing AWS-native security tooling.

3.3 Algorithms and Cryptographic Primitives

The framework uses the following core algorithms:

Groth16: The proving system for all credential and integrity circuits. Chosen for its constant verification time and compact proof size — properties critical for real-time cloud access decisions [11].

Poseidon Hash Function: A ZK-friendly hash function optimized for arithmetic circuit computation, replacing SHA-256 for commitment schemes within circuits. Poseidon reduces constraint count by approximately 8x compared to SHA-256, substantially reducing proof generation time [15].

Pedersen Commitments: Used to commit to data values during the circuit setup phase. A Pedersen commitment is a cryptographic binding that hides the value but allows the committer to later prove knowledge of it.

Merkle Tree Membership Proofs: For batch verification scenarios (verifying that one of many records has not changed), the framework uses sparse Merkle trees with ZK membership proofs, allowing O(log n) proof size regardless of the size of the data set being attested.

4. Implementation

4.1 The Development Environment

The implementation was developed and tested using the following stack:

• Circuit language: Circom 2.1.6
• Proof generation: snarkjs 0.7.3 (JavaScript/Node.js library)
• Proof orchestration: Python 3.11 with the py_ecc and py_snark wrappers
• Verification contracts: Solidity 0.8.24, compiled with Hardhat
• Cloud infrastructure: AWS Lambda (proof generation service), API Gateway (request routing), S3 (key storage), CloudWatch (monitoring)
• Testing network: Local Hardhat node for smart contract tests; Sepolia testnet for integration tests

4.2 Circuit Design: A Concrete Example

The credential validity circuit defines the following statement: "I know a secret credential cred and a nonce n such that Poseidon(cred, n) == commitment and cred belongs to the set of valid credentials."

In Circom, this is expressed as a constraint system over finite field elements. The circuit has approximately 2,400 constraints for a credential set of size 1,024. At this circuit size, snarkjs generates a proof in approximately 55 milliseconds on consumer hardware — well within the latency budget for an access control gate [11].

The trusted setup for this circuit — the Powers of Tau ceremony that generates public parameters — was conducted using the Hermez Network's existing universal trusted setup, avoiding the need for an organization-specific ceremony and eliminating the single-point trust assumption.

4.3 Cloud Integration

The proof generation Lambda function is triggered by an API Gateway event when a resource access request arrives. The function:

1. Receives a JSON payload containing the public inputs (commitment value, policy hash) and the proof object
2. Calls the Solidity verifier contract via an RPC provider
3. Returns the verification result to the requesting service within the Lambda execution timeout

The verifier contract address is stored as an SSM Parameter Store value and injected into Lambda at runtime, avoiding hardcoded contract dependencies. Proof verification on the EVM costs approximately 220,000 gas units per call using the Groth16 verifier — a predictable, fixed cost regardless of the complexity of the proof being verified.

5. Results and Evaluation

5.1 Performance Benchmarks

The framework was evaluated across three circuit types — credential verification, data integrity, and batch compliance — under simulated load using Apache JMeter with 100 concurrent virtual users.

| Metric | ZKCV (Groth16) | TLS + RBAC | Hash Commitment | |---|---|---|---| | Proof/Verification latency | 55ms + 1.8s | 12ms | 35ms | | Proof/Signature size | 384 bytes | ~500 bytes (cert) | 32 bytes (hash) | | Data exposure during verification | None | Credential transmitted | Hash exposed | | Trusted setup required | Yes (one-time) | No | No | | Post-quantum secure | No | No | Depends | | GDPR data minimization compliant | Yes (by design) | Partial | Partial |

The total end-to-end verification latency of approximately 1.85 seconds (55ms proof generation + ~1.8s contract call) is higher than traditional RBAC by approximately 150x for the latency-sensitive path. However, this comparison is not entirely fair: the ZKP verification provides a strictly stronger privacy guarantee that TLS + RBAC cannot provide at any latency level — it eliminates credential exposure entirely.

For asynchronous verification use cases — auditing, compliance reporting, batch access reviews — the latency difference is irrelevant, and the privacy advantage is significant.

5.2 Privacy Guarantees Comparison

Traditional verification exposes credentials at the transmission layer, the comparison layer, and in system logs. The ZKCV framework exposes only:

• The public inputs to the circuit (the commitment value and policy hash — not the credential or policy itself)
• The proof object (384 bytes of elliptic curve points that reveal no information about the witness)
• The boolean verification result

Under a formal security model, this constitutes zero-knowledge: a computationally unbounded adversary who intercepts all ZKCV traffic learns nothing about the underlying credentials beyond the fact that they are valid. Under traditional TLS + RBAC, the same adversary who intercepts traffic or gains access to access logs recovers the credential directly.

5.3 Scalability Under Load

Under 100 concurrent verification requests, the Lambda-based proof generation service maintained a p95 latency of 2.1 seconds with no failures. Horizontal scaling (increasing Lambda concurrency limit) linearly extended throughput. The EVM verifier contract showed stable gas costs of approximately 220,000 units per call with no significant variance across 10,000 test calls.

The bottleneck in the current architecture is not the ZKP computation itself but the EVM call latency. Offloading verification to a dedicated verifier service running the same Groth16 algorithm natively in Rust reduces end-to-end latency to approximately 450ms — competitive with middleware-heavy enterprise IAM systems.

5.4 Comparison with Existing Approaches

The Wiley Security and Privacy survey of ZKP tools found that among snarkjs, ZoKrates, and Circom-based implementations, the combination of Circom circuits with snarkjs proof generation provides the best balance of proof size and prover time for Ethereum-compatible verification [3]. Our results are consistent with that finding. The ZoKrates alternative generated identical proof sizes but with 3x longer proof generation time due to its internal compiler overhead.

Compared to the MDPI benchmark study evaluating zk-SNARK, zk-STARK, and Bulletproof protocols, the ZKCV framework's use of Groth16 produces the smallest proofs in all configurations tested, while Bulletproofs showed the worst performance in both generation and verification — consistent with their known O(n) verification scaling [12].

6. Discussion

6.1 What This Framework Gets Right

The ZKCV framework's strongest contribution is making ZKP-based cloud verification accessible to teams without deep cryptographic expertise. By wrapping Circom and snarkjs in a Python orchestration layer and deploying verification to standard EVM infrastructure, the implementation path follows patterns that cloud engineers already understand: Lambda functions, API Gateway, smart contracts.

The privacy guarantee is also genuinely stronger than any alternative. When the framework is correctly implemented, there is no configuration or deployment decision that can accidentally expose credentials — because the credentials never enter the verification pipeline in any form. The exposure surface is structurally zero.

The regulatory alignment is real. The EU's eIDAS 2.0 framework and GDPR's data minimization principle are both naturally satisfied by an architecture where the verifier never sees the verified data [7] [8]. Organizations building in regulated industries — healthcare, finance, identity — are increasingly going to face pressure to demonstrate that their verification systems are data-minimizing by design, not by policy.

6.2 The Honest Limitations

Latency is a real cost. The 1.85-second total verification latency is acceptable for many use cases but is prohibitive for latency-sensitive access control paths like API authentication gates that must respond in under 100ms. The EVM-based verification model adds unnecessary overhead for purely cloud-native deployments. Moving to a Rust-native verifier service removes most of this overhead, but increases implementation complexity.

The trusted setup is a real trust assumption. Groth16's required trusted setup — the Powers of Tau ceremony — means there is a set of cryptographic parameters that, if generated maliciously, could allow false proofs to be verified. Using an existing, widely-audited universal trusted setup (like Hermez's) mitigates this in practice, but the assumption cannot be eliminated without switching to STARK-based proving, which introduces its own tradeoffs [11].

Developer complexity remains high. Writing correct Circom circuits requires understanding arithmetic constraints, finite field arithmetic, and the distinction between witness values and public inputs. A subtle bug in a circuit — an under-constrained signal, for example — can create a vulnerability where proofs can be forged for invalid statements. Auditing ZKP circuits is harder than auditing Solidity contracts, and the tooling for automated circuit verification is immature.

Post-quantum readiness. Groth16 and other elliptic curve-based SNARK constructions are not post-quantum secure. The 2025 IIT Jodhpur study notes that zk-STARKs remain transparent and post-quantum secure at the cost of larger proof sizes and slower generation [11]. Organizations with long-horizon security requirements should track the development of lattice-based SNARK constructions as potential successors.

Current zkEVM rollups achieve roughly 20-50 transactions per second with proving delays of 10-30 seconds [10]. For applications that require on-chain verification of large volumes of cloud access decisions simultaneously, this is a significant bottleneck. Off-chain verifier services resolve this for most cloud use cases, but decouple the verification from the blockchain's trust guarantees.

7. Conclusion and Future Work

What We Built and What It Shows

This paper proposed and evaluated ZKCV, a modular zero-knowledge verification framework for cloud data privacy. The framework uses Circom-compiled arithmetic circuits, snarkjs-based proof generation in a serverless Python environment, and Solidity verifier contracts on EVM infrastructure — all orchestrated through AWS-native services.

The empirical results show that the framework achieves proof generation at 55ms and end-to-end verification under 2 seconds, with proof sizes of 384 bytes, zero credential exposure during verification, and linear scalability under concurrent load. Against traditional TLS + RBAC, the ZKCV framework trades approximately 150x latency overhead for a qualitatively different privacy guarantee: the verifier learns nothing about the credential beyond its validity.

For organizations operating under GDPR, HIPAA, or similar data minimization requirements, that trade is worth making for the right access control paths. For latency-sensitive synchronous authentication, a hybrid model — ZKP for batch and audit verification, TLS for real-time interactive authentication — is more practical in the near term.

The Bigger Picture

There is a simple way to think about what ZKPs do for cloud security. Every existing verification system has a question embedded in its design: "Can I see enough to trust you?" ZKPs change the question to: "Can you convince me without showing me?"

That shift sounds subtle. Its implications are not. A world where verification does not require exposure is a world where the most common vector for cloud breaches — credential interception, log exposure, insider access to audit trails — no longer provides an attacker with anything useful. The data was never there to steal.

We are not in that world yet. The tooling is maturing, the regulatory incentives are aligning, and the performance gap is closing faster than most people realize. The framework presented here is one step toward making ZKP-based verification a standard option in the cloud security toolkit, not an exotic research artifact.

Future Work

Several directions extend naturally from this work:

Recursive proof composition would allow the ZKCV framework to aggregate thousands of verification events into a single proof, enabling batch compliance reporting at arbitrary scale. Nova and Halo2 are the most promising proof systems for this use case.

GPU-accelerated proof generation is an active research area. Hardware acceleration through GPUs and FPGAs is projected to reduce SNARK proof generation times by 10-100x over the next two years [5]. Integrating hardware-accelerated provers into the Lambda environment would close most of the latency gap with traditional verification.

Cross-cloud attestation — using ZKP proofs as a portable, cloud-agnostic credential format that can be verified on any EVM-compatible network — would allow organizations to establish verifiable trust across AWS, GCP, and Azure environments without a centralized identity broker.

Formal verification of circuit correctness is perhaps the most important area for further work. The security of the entire system depends on the arithmetic circuits being correctly constrained. Automated tools for circuit verification are early but promising — investing in them is the highest-leverage way to reduce the practical risk of deploying ZKP-based cloud security.

References

1. Sprinto. "60+ Cloud Security Statistics: Quick Facts for 2025." Sprinto Blog, 2025.

2. SentinelOne. "50+ Cloud Security Statistics for 2025–2026." SentinelOne, February 2026.

3. R., S., Chirakarotu Nair, R., and Kumar Panakalapati, P. "Promise of Zero-Knowledge Proofs (ZKPs) for Blockchain Privacy and Security: Opportunities, Challenges, and Future Directions." Security and Privacy, Wiley, 2025. doi:10.1002/spy2.461

4. Goldreich, O., Micali, S., and Wigderson, A. "Proofs That Yield Nothing but Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems." Journal of the ACM (JACM), 38(3), 1991.

5. Rumble Fish. "Top 10 Zero-Knowledge Proof Projects Reshaping Blockchain in 2025." Rumble Fish Blog, 2025.

6. Rumble Fish. "Understanding Zero-Knowledge Proof Development: Key Concepts and Practical Applications." Rumble Fish Blog, September 2025.

7. Internet Policy Review. "The Impact of Zero-Knowledge Proofs on Data Minimisation Compliance of Digital Identity Wallets." Internet Policy Review, July 2025.

8. Cryptonium. "ZK-Proofs vs. Centralized Identity: The 2026 Digital Identity Battleground." Cryptonium Cloud, December 2025.

9. Exabeam. "61 Cloud Security Statistics You Must Know in 2025." Exabeam, 2025.

10. Blockchain Council. "Privacy-Preserving AI with Blockchain: ZK Proofs, MPC, Secure Enclaves." Blockchain Council, April 2026.

11. Nainwal, A., Kamble, A., and Awathare, N. "A Comparative Analysis of zk-SNARKs and zk-STARKs: Theory and Practice." arXiv preprint arXiv:2512.10020, December 2025.

12. MDPI Information. "Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof in Real-World Scenarios: A Benchmark Study." MDPI Information, 15(8), August 2024.

13. IJSAT. "Zero-Knowledge Proof-Based Identity Verification in Decentralized Finance." International Journal of Science and Advanced Technology, 2025.

14. Stealth Cloud. "Zero-Knowledge Proof Performance Benchmarks: Speed, Size, and Security Trade-offs." Stealth Cloud Intelligence Platform, March 2026.

15. ACM. "The Power and Potential of Zero-Knowledge Proofs." Communications of the ACM, July 2025.

16. Ancilar. "Zero-Knowledge Proofs Demystified: A Practical Code Guide for Developers." Medium / Blockchain Services, July 2025.

17. DataStackHub. "Data Breach Statistics 2025–2026: Global Trends and Costs." DataStackHub, October 2025.

18. INATBA. "Leveraging ZKP for GDPR Compliance in Blockchain Projects." International Association for Trusted Blockchain Applications, August 2025.