FHE vs Zero-Knowledge Proofs: When to Use Which

Fully homomorphic encryption computes on data you cannot see. Zero-knowledge proofs prove statements without revealing why they are true. They are not interchangeable. They are complementary. Here is when to use each — and what happens when you combine them in one pipeline.

They Solve Different Problems

FHE and ZK proofs get grouped together under "privacy-preserving cryptography," and that grouping obscures a fundamental distinction. They protect different things at different stages of a computation.

FHE protects data during computation. You encrypt your inputs. A server computes on the ciphertexts. The server never sees the plaintext. The output is an encrypted result that only you can decrypt. The server did useful work on data it could not read.

ZK proofs protect data during verification. You have a fact you want someone to believe. You construct a proof that the fact is true. The verifier checks the proof. At no point does the verifier see the underlying data that makes the fact true. The verifier is convinced; the data remains private.

The difference is not subtle. FHE answers: "How do I compute on private data without exposing it?" ZK answers: "How do I prove a claim without revealing the evidence?" These are different questions. They arise at different stages of a pipeline. And the engineering requirements for each are radically different.

When to Use FHE

FHE is the right tool when you have sensitive data and need to compute on it without exposing it to the party performing the computation. The defining characteristic: the computation produces an encrypted result. Nobody in the pipeline — not the server, not the network, not the storage layer — ever sees the plaintext inputs or the plaintext output.

Concrete use cases where FHE is the correct choice:

• Encrypted biometric matching. A user's biometric template is encrypted on-device. The server computes an inner product between the encrypted template and a stored encrypted reference. The match score is encrypted. The server knows whether authentication succeeded (via a threshold comparison), but never sees the biometric data. This is H33's core authentication pipeline: BFV inner product at 42 microseconds per auth.
• ML inference on private data. A hospital encrypts patient records. A model provider runs inference on the encrypted data. The predictions are returned encrypted. Neither the model provider nor any intermediate infrastructure sees the patient data. CKKS handles the real-number arithmetic: 333ms for a 64-dimensional encrypted dot product.
• Encrypted search and aggregation. A financial institution encrypts transaction records. An auditor runs encrypted queries — sum, average, count — over the encrypted dataset. The aggregate results are decrypted only by the institution. The auditor sees the aggregates, never the individual transactions.
• Encrypted threshold decisions. An insurance company needs to determine whether a risk score exceeds a threshold. TFHE evaluates the comparison gate on encrypted inputs. The comparison result is encrypted. The insurer decrypts only the boolean: above or below threshold. The actual score remains encrypted throughout.

The common thread: data stays encrypted through the entire computation. The output is encrypted. Decryption happens only at the endpoint that owns the key.

When to Use ZK

Zero-knowledge proofs are the right tool when you need to prove something to a verifier without revealing the underlying data. The defining characteristic: the verifier learns that a statement is true, and nothing else. Not the data. Not the computation path. Not any auxiliary information.

Concrete use cases where ZK is the correct choice:

• Age verification without identity disclosure. A user proves they are over 21 to a merchant. The merchant learns "over 21" and nothing else — not the birth date, not the name, not the ID number. The ZK proof encodes the age check against a committed credential.
• Compliance proof without record exposure. A bank proves to a regulator that all AML checks passed for a batch of transactions. The regulator verifies the proof. The individual transaction details remain confidential. The proof demonstrates compliance without creating a new data exposure surface.
• Identity attestation without credential revelation. A user proves they hold a valid credential (professional license, security clearance, health certification) without revealing the credential itself. The verifier confirms validity. The credential's contents remain private.
• Computation integrity proof. A server computes a result and publishes a proof that the computation was performed correctly. Any verifier can check the proof without re-executing the computation. This is how rollups work, and it is how H33 attests that FHE computation was performed correctly.

The common thread: a verifier is convinced of a fact. The evidence for that fact remains hidden. No data is computed on — a pre-existing statement is proven.

The Overlap Zone

Both FHE and ZK protect privacy. But they protect it at different stages. Understanding the overlap zone — where both are useful in the same pipeline — is where the real architectural insight lies.

Consider a practical scenario: encrypted credit scoring.

1. Stage 1 (FHE): A borrower's financial records are encrypted on-device. A lender's server runs an encrypted scoring model via CKKS. The output is an encrypted credit score. The lender's server never sees the financial records or the score.
2. Stage 2 (ZK): The encrypted score is decrypted by the borrower. The borrower generates a ZK proof that the score exceeds a threshold (e.g., above 700) without revealing the actual score. The lender verifies the proof. The lender knows "score above 700" and nothing more.
3. Stage 3 (Attestation): The entire pipeline — the FHE computation, the ZK proof, the threshold check — is committed to a post-quantum attestation. The attestation proves that the pipeline executed correctly, that the FHE computation used the correct model, and that the ZK proof verified.

FHE protected the data during computation. ZK protected the result during verification. The attestation binds both stages into an auditable, tamper-evident record. Neither technology alone covers all three stages. Together, they close every gap in the pipeline.

H33's Approach: Both in One Pipeline

H33 does not force you to choose. The platform routes operations to the appropriate cryptographic engine automatically. A single API call can involve FHE computation, ZK proof generation, and post-quantum attestation — the developer does not manage the transitions.

The production stack:

• FHE engines: BFV for exact integer arithmetic (biometric auth, encrypted search). CKKS for real-number computation (ML inference, scoring, aggregation). TFHE for boolean circuits and comparisons (threshold decisions, encrypted conditionals).
• ZK engine: STARK proofs for computation integrity and selective disclosure. Hash-based, no trusted setup, post-quantum secure by construction. No Groth16 anywhere in the stack — elliptic curve pairings are not quantum-resistant.
• Attestation: H33-74 substrate. 74 bytes containing a three-family post-quantum signature (ML-DSA + FALCON + SLH-DSA) that commits the computation result, the routing decision, and the authorization context.

The concrete pipeline for encrypted biometric authentication:

1. FHE (BFV): Encrypted biometric template is matched against an encrypted reference via inner product. 32 users per ciphertext, batch-processed. 943 microseconds for the FHE batch.
2. ZK (STARK): A cached STARK proof attests that the match computation was performed correctly and that the result satisfies the threshold. 2.0 microseconds to prove, 0.2 microseconds to verify (cached lookup via CacheeEngine).
3. Attestation (H33-74): The match result and STARK proof are committed to a three-family PQ signature. SHA3-256 hash + Dilithium sign + Dilithium verify. 391 microseconds for the batch attestation.

The ZK layer adds less than 1 microsecond per authentication to the FHE pipeline. It is not a performance penalty. It is a verification guarantee at near-zero marginal cost.

Performance Comparison

Measured on AWS Graviton4 c8g.metal-48xl (192 vCPUs, 96 physical cores). All numbers from production builds, not benchmarks on developer hardware.

FHE dominates the pipeline latency. That is expected — computing on encrypted data is inherently more expensive than proving a statement about plaintext. The ZK layer is three orders of magnitude faster than the FHE layer because it operates on hashes and commitments, not on encrypted polynomial rings.

This is why combining them works: the ZK overhead is invisible relative to the FHE cost. You get computation integrity verification for free, in performance terms.

Post-Quantum Security

Both FHE and STARKs are post-quantum secure, but for different reasons.

FHE (BFV, CKKS, TFHE): Based on the Ring Learning With Errors (RLWE) problem. The best known quantum algorithm for RLWE offers no significant advantage over classical algorithms. NIST's post-quantum standards (ML-KEM, ML-DSA) are built on the same lattice hardness assumptions. FHE inherits this security by construction.

STARKs: Based on collision-resistant hash functions (SHA3-256 in H33's implementation). Grover's algorithm reduces the effective security of hash functions by half — a 256-bit hash provides 128 bits of quantum security. This exceeds NIST's Level 1 threshold. No pairing-based mathematics. No elliptic curves. No trusted setup ceremony that could be compromised.

What H33 does NOT use: Groth16. BN254 pairings. Any SNARK construction that relies on the hardness of the discrete logarithm problem on elliptic curves. These constructions are efficient and widely deployed, but they are broken by Shor's algorithm. A post-quantum privacy stack cannot include non-post-quantum verification.

Every attestation in the H33 pipeline carries three independent post-quantum signature families: ML-DSA (lattice-based), FALCON (NTRU lattice-based), and SLH-DSA (hash-based). An attacker must break MLWE lattices, NTRU lattices, AND stateless hash functions simultaneously. Three independent mathematical bets.

Decision Framework

Use this table when architecting a privacy-preserving system. The question is not "FHE or ZK?" The question is "What does each stage of my pipeline need?"

The framework reduces to three questions:

1. Do I need to compute on encrypted data? If yes, FHE. Choose the scheme by data type: BFV for integers, CKKS for real numbers, TFHE for booleans and comparisons.
2. Do I need to prove a property of the result? If yes, ZK. Use STARKs for post-quantum security. Avoid Groth16/SNARKs if quantum resistance is a requirement.
3. Do I need a permanent, tamper-evident, post-quantum record? If yes, attestation. H33-74 substrate: 74 bytes, three PQ signature families, chain-agnostic.

Most production privacy pipelines need at least two of these three. Many need all three. The architecture that wins is the one where the developer does not have to stitch them together manually.

The Real Question

The industry conversation around "FHE vs ZK" frames them as competing technologies. They are not. They are complementary stages of a complete privacy pipeline. Asking "Should I use FHE or ZK?" is like asking "Should I use encryption or authentication?" The answer is yes. Both. For different purposes. In the same system.

FHE without ZK means you compute on encrypted data but cannot prove anything about the result without decrypting it. ZK without FHE means you can prove statements about data, but the data must exist in plaintext somewhere for the proof to be constructed. The combination — FHE computation followed by ZK verification — closes both gaps. The data is never plaintext during computation, and the result is never revealed during verification.

Add post-quantum attestation and the pipeline is complete: private computation, verifiable results, and a tamper-evident record that survives quantum computers. One API. Three cryptographic layers. Every gap closed.