Alternatives to Homomorphic Encryption for Protecting AI Data

The Privacy-Preserving Computation Landscape

Every organization processing sensitive data with AI faces the same question: how do you protect the data during computation? Encryption at rest and in transit are solved problems. The gap is data in use—the moment AI models process plaintext in memory, GPU VRAM, and compute pipelines.

Five main approaches attempt to close this gap. Each makes different assumptions about what you trust, what you are protecting against, and what performance cost you are willing to accept. None is universally superior. The right choice depends on your threat model, architecture, and regulatory requirements.

Trusted Execution Environments (TEEs)

TEEs create isolated hardware enclaves where code and data are protected from the rest of the system—including the operating system, hypervisor, and other tenants. The most prominent implementations: Intel SGX (Software Guard Extensions), AWS Nitro Enclaves, ARM TrustZone, and AMD SEV (Secure Encrypted Virtualization).

How they work: The CPU creates an encrypted memory region that only code running inside the enclave can access. Even a privileged attacker with root access to the host cannot read enclave memory. Data is decrypted only inside the enclave and encrypted whenever it leaves.

The appeal: TEEs are fast. Data is processed in plaintext inside the enclave, so there is no computational overhead for encryption during processing. Latency is near-native. This makes TEEs attractive for performance-sensitive AI workloads.

The problem: TEEs process plaintext. They trust the hardware vendor to implement the isolation correctly. That trust has been broken repeatedly:

• Spectre and Meltdown (2018) — demonstrated speculative execution attacks that can read data across security boundaries, including TEE boundaries.
• Foreshadow / L1TF (2018) — specifically targeted Intel SGX enclaves, allowing attackers to extract enclave secrets through L1 cache side channels.
• Plundervolt (2019) — undervolted the CPU to induce computational faults inside SGX enclaves, extracting cryptographic keys.
• AEPIC Leak (2022) — architectural bug in Intel CPUs that leaked enclave data through APIC MMIO registers.

Each generation of TEE patches previous attacks, but the fundamental issue persists: the security guarantee is hardware-based, not mathematical. A sufficiently sophisticated attacker (nation-state, supply chain compromise, future side-channel discovery) can potentially break TEE isolation. TEEs are also not quantum-resistant—the enclave protects memory access, not the underlying cryptographic operations.

Secure Multi-Party Computation (MPC)

MPC allows multiple parties to jointly compute a function on their private inputs without revealing those inputs to each other. Each party holds a share of the data. They compute together through interactive protocols—exchanging intermediate values that reveal nothing about the underlying data.

Security guarantee: As long as a threshold of parties remain honest (do not collude), no party learns anything about another party's input beyond what the output reveals. This is a mathematical guarantee, not a hardware one.

Strengths: Strong cryptographic guarantees for multi-organization computation. Proven protocols (Shamir secret sharing, GMW, garbled circuits) with decades of academic analysis. Ideal for scenarios where data inherently belongs to multiple organizations—cross-bank fraud detection, multi-hospital research, joint analytics.

Limitations: MPC requires multiple non-colluding parties, which means legal agreements, infrastructure coordination, and operational overhead. Communication rounds between parties add latency that scales with circuit depth—deep computations require many network round trips. Bandwidth requirements can be substantial. And all parties must be online simultaneously during computation. For single-organization AI inference, MPC adds complexity without matching the use case.

Differential Privacy

Differential privacy adds calibrated random noise to computation outputs so that the result does not reveal whether any individual's data was included in the input. The key property: an adversary observing the output cannot determine with confidence whether a specific person's data was used.

What it protects: Outputs. Differential privacy prevents statistical inference attacks on query results, model predictions, and published analytics. Apple uses it for keyboard suggestion data. Google uses it for Chrome usage statistics. The U.S. Census Bureau used it for the 2020 census.

What it does not protect: The data during computation. Differential privacy operates on outputs after computation completes. The AI model still processes plaintext in memory. The data still exists unencrypted on the compute infrastructure. A server compromise during processing exposes raw data regardless of what noise is added to the output later.

The tradeoff: Accuracy. Adding noise degrades the quality of results. The privacy budget (epsilon) quantifies this tradeoff—lower epsilon means stronger privacy but noisier results. For aggregate analytics and population-level statistics, this tradeoff is acceptable. For individual-record processing—biometric matching, per-patient diagnosis, per-transaction fraud scoring—differential privacy cannot help because the output must be precise for a specific record.

Federated Learning

Federated learning keeps data at the source. Instead of centralizing training data on a single server, models train locally on each data holder's device and share only model updates (gradients) with a central aggregator. The raw data never leaves its origin.

The promise: Data sovereignty. Hospitals train on their own patient data and share only gradient updates. Mobile devices train on local user behavior and upload only model improvements. The central server never sees raw data.

The reality: Gradients leak data. Research has repeatedly demonstrated that model gradients can be inverted to reconstruct training data with high fidelity. The Deep Leakage from Gradients attack (Zhu et al., 2019) showed pixel-perfect reconstruction of training images from shared gradients. Subsequent work has improved these attacks to work with larger batch sizes and more complex models.

Additional limitations: Federated learning only addresses training, not inference. Once the model is deployed, inference still requires data to be sent to the model (or the model to the data), and the computation happens on plaintext. Communication overhead for gradient exchange can be substantial—model weights for large models are gigabytes. And heterogeneous data distributions across participants (non-IID data) can degrade model quality.

Fully Homomorphic Encryption (FHE)

FHE provides the strongest guarantee: data remains encrypted throughout the entire computation. The server performs mathematical operations on ciphertext that produce results identical to operations on plaintext. No decryption at any point. No plaintext in memory. No hardware trust assumptions. No multi-party coordination.

The historical objection: Performance. Early FHE implementations were millions of times slower than plaintext operations. A single encrypted multiplication took 30 minutes in 2009. This made FHE a theoretical curiosity, not a practical tool.

The current reality: H33's production-optimized BFV implementation processes encrypted operations at 38.5 microseconds each. That is faster than most plaintext API round trips. The pipeline—FHE encryption, ZK-STARK proof generation, Dilithium post-quantum signature—sustains 2,172,518 operations per second on a single AWS Graviton4 ARM CPU. No GPU required. Per-operation cost below $0.000001.

Quantum resistance: FHE is based on the Ring Learning With Errors (RLWE) lattice problem, which is believed resistant to both classical and quantum computers. Combined with ML-DSA (Dilithium) signatures and SHA3-256 based ZK-STARKs, the entire pipeline is post-quantum secure.

Comparison Table

H33's Approach: FHE + ZK + PQ

H33 does not rely on any single privacy-preserving technique. The production pipeline combines three cryptographic primitives that together provide complete data protection with verifiable correctness and post-quantum security:

• Fully Homomorphic Encryption (BFV) — data remains encrypted during all computation. No plaintext on the server. No hardware trust assumptions. No multi-party coordination. Mathematical guarantee that the server learns nothing. RLWE-based, inherently quantum-resistant.
• ZK-STARKs — every encrypted computation produces a zero-knowledge proof that the operation was performed correctly on the ciphertext. The data owner can verify results without trusting the server's execution environment. SHA3-256 based, no trusted setup, quantum-resistant.
• Dilithium (ML-DSA, FIPS 204) — all proofs and results are signed with lattice-based digital signatures. Post-quantum secure. Provides non-repudiation and integrity verification for every operation in the pipeline.

The three layers address different threat vectors. FHE protects data confidentiality. ZK-STARKs ensure computation integrity. Dilithium provides authentication and non-repudiation. Together, they eliminate the need for hardware trust (unlike TEEs), multi-party coordination (unlike MPC), accuracy degradation (unlike differential privacy), and gradient exposure (unlike federated learning).