FHE vs Secure Enclaves:
Comparing Privacy Technologies

FHE and secure enclaves (like Intel SGX and ARM TrustZone) both enable computation on sensitive data. However, they take fundamentally different approaches with different security properties. Understanding these differences helps you choose the right technology.

Fundamental Approaches

FHE (Fully Homomorphic Encryption)

Mathematical protection: data remains encrypted during computation on encrypted data, security based on cryptographic hardness. FHE schemes like BFV operate on lattice-based mathematical structures, encoding plaintext into polynomial rings and performing arithmetic directly on ciphertexts. The server executing the computation never sees the underlying data—it manipulates encrypted polynomials and returns an encrypted result that only the key holder can decrypt.

Secure Enclaves

Hardware protection: data decrypted inside a protected hardware region, security based on physical isolation. Enclaves carve out a section of the CPU’s memory space that is shielded from the operating system, the hypervisor, and even physical bus-snooping attacks. The processor enforces access controls at the silicon level, and remote attestation lets a client verify that the correct code is running inside the enclave before sending secrets.

Security Model Comparison

FHE Security

• Based on mathematical problems (lattice hardness—specifically RLWE/MLWE)
• No trusted hardware required
• Post-quantum secure (lattice-based schemes)
• Data protected even if server is fully compromised
• Security is provably reducible to well-studied hard problems

Enclave Security

• Based on hardware isolation enforced at the CPU microarchitecture level
• Requires trust in hardware manufacturer (Intel, AMD, ARM)
• Vulnerable to side-channel attacks (Spectre, Meltdown, Foreshadow, Plundervolt)
• Attestation proves code integrity but not absence of hardware flaws
• Security patches require microcode or firmware updates—often slow to deploy

Attack Surface

The difference in attack surface between FHE and secure enclaves is not merely theoretical—it has been demonstrated repeatedly in practice.

FHE Attack Vectors

• Cryptographic breaks (theoretical, none known for standard schemes)
• Implementation bugs in FHE libraries
• Key management failures

Enclave Attack Vectors

• Side-channel attacks (many demonstrated—SGX has been broken multiple times since 2018)
• Hardware vulnerabilities in the memory encryption engine
• Microcode/firmware attacks that bypass enclave isolation
• Supply chain attacks on hardware manufacturing
• Controlled-channel attacks exploiting page-table access patterns

Performance Comparison

Performance has historically been FHE’s weakness and enclaves’ strength. But that gap is narrowing rapidly—especially for structured operations like biometric matching, inner products, and threshold comparisons.

FHE Performance

• Significant overhead compared to plaintext—but improving rapidly
• 10–1000x improvement in the last five years through algorithmic and hardware co-optimization
• Simple operations (inner products, comparisons): microseconds to low milliseconds
• Complex operations (arbitrary circuits, deep neural nets): seconds to minutes

Enclave Performance

• Near-native speed for computation inside the enclave
• Overhead mainly in enclave entry/exit (ECALL/OCALL transitions)
• Limited Enclave Page Cache (EPC) causes expensive paging for large workloads
• Context switches are expensive—batching is essential for throughput

Why the Gap Matters Less Than You Think

For authentication workloads, the raw per-operation latency difference between FHE and enclaves is often irrelevant at the system level. H33’s BFV pipeline processes 32 biometric matches in a single ciphertext (~1,109µs per batch), leveraging SIMD batching across 4,096 polynomial slots. Combined with ZKP proof caching via in-process DashMap (0.085µs per lookup) and batch Dilithium attestation (~244µs per 32-user batch), the full-stack per-authentication cost lands at ~42µs. At that latency, FHE is no longer the bottleneck—network round-trip time is.

Practical Considerations

Choose FHE when:

• You cannot trust the computing infrastructure (cloud, third-party, multi-tenant)
• Post-quantum security is required now or in the foreseeable future
• Data must never be decrypted outside your control—even momentarily
• Computation is structured (inner products, polynomial evaluation, comparisons)
• Regulatory compliance demands mathematical proof of data confidentiality

Choose Enclaves when:

• Raw single-operation performance is critical and latency budgets are sub-microsecond
• Complex arbitrary code must run (full programs, ML inference on unstructured data)
• You can trust hardware attestation and accept the risk of hardware vulnerabilities
• Side-channel mitigations and microcode patching cadence are acceptable operational costs

Hybrid Approaches

The best solutions often combine both technologies in a defense-in-depth architecture:

• FHE for long-term data protection—biometric templates, medical records, and financial data encrypted at rest and during computation
• Enclaves for performance-critical key operations—TLS termination, key derivation, and session management where plaintext exposure is momentary and bounded
• FHE key operations inside enclaves—secret key material never leaves the enclave, while the FHE computation itself runs on untrusted hardware
• Layered attestation—enclave attestation verifies the execution environment, FHE guarantees data confidentiality independent of that environment

“The question is not whether to trust hardware or mathematics—it is how to architect systems so that neither a hardware flaw nor a cryptographic advance alone can compromise your users.”

H33’s Approach

We primarily use FHE for biometric matching because:

• Biometric data has lifetime sensitivity—you cannot revoke a fingerprint or retinal scan the way you rotate a password
• Users should not trust any third party with their biometrics—FHE ensures H33 never sees plaintext biometric templates
• Our optimizations achieve production-grade performance—2.17M auth/sec on Graviton4, ~42µs per authentication with full post-quantum attestation
• Post-quantum security future-proofs the protection—lattice-based BFV is natively resistant to quantum attacks, unlike hardware isolation which is cryptographically agnostic

# H33 full-stack pipeline per authentication
FHE batch (BFV, 32 users/CT) .... ~1,109 µs
ZKP cache (DashMap in-process) ...   ~0.085 µs
Attestation (Dilithium sign+verify) ~244 µs  (amortized over 32)
────────────────────────────────────
Total per batch .................. ~1,356 µs
Per authentication ............... ~42 µs
Sustained throughput ............. 2,172,518 auth/sec

Both FHE and secure enclaves have their place in the privacy-preserving computation landscape. The right choice depends on your threat model, performance requirements, and time horizon. For workloads where data must remain confidential over years or decades—biometrics, medical records, financial identities—FHE provides a guarantee that no hardware vulnerability can revoke. For workloads that demand arbitrary computation at native speed with acceptable hardware trust, enclaves remain a practical tool. Understand their trade-offs to make the right choice for your application.