FHE versus TEEs versus MPC: An Honest Comparison for Confidential LLM Serving

Homomorphic encryption is not the only way to run a model without exposing the prompt; it is one of three main approaches to confidential inference, alongside trusted execution environments and secure multi-party computation. They reach a similar goal by very different means, and the right choice depends less on raw performance than on a single question: where does the trust live? This article compares the three honestly — their trust roots, their costs, and above all their threat models — so that FHE can be understood not in isolation but as one point on a spectrum of ways to compute on data you are not allowed to see.

The three approaches at a glance

All three approaches let a party compute on data it should not be able to read, but they achieve it through different mechanisms. Fully homomorphic encryption keeps the data encrypted the entire time and computes on the ciphertext, so plaintext never exists on the serving side. A trusted execution environment decrypts the data inside a hardware-protected enclave that the surrounding system cannot inspect, so plaintext exists but only within a shielded boundary. Secure multi-party computation splits the data among several parties who jointly compute a result without any single party ever holding the whole input in the clear.

The differences are not implementation details; they are differences in what you must trust. FHE asks you to trust only the mathematics of a hard lattice problem. A TEE asks you to trust a hardware vendor and the integrity of a chip. MPC asks you to trust that a set of parties will not collude beyond a threshold. Each places the root of trust somewhere different — in cryptography, in silicon, or in a distribution of parties — and that placement is the primary thing that distinguishes them.

Because the trust root differs, so does the adversary each defends against, and that is the axis on which they should be compared. Performance matters, and the three differ sharply there too, but a fast approach with a trust root that does not match your threat model is the wrong choice regardless of speed. The rest of this article compares them on trust first and cost second.

FHE and TEEs: cryptography versus hardware

FHE offers the strongest trust model of the three. Because the data is never decrypted on the serving side, a provider that is fully compromised — malicious insiders, a breached host, a coerced operator — still learns nothing beyond what the ciphertext reveals, which under semantic security is nothing about the plaintext. There is no hardware to trust and no enclave to break; the guarantee rests entirely on a well-studied lattice assumption. The cost of this purity is computation: as the earlier articles showed, homomorphic evaluation, dominated by bootstrapping, is orders of magnitude slower than plaintext computation.

A trusted execution environment makes the opposite trade. Data is decrypted and processed in the clear inside an enclave — a hardware-isolated region of a CPU, or increasingly a confidential GPU — that the host operating system and hypervisor cannot read, with remote attestation letting the client verify it is talking to a genuine enclave running the expected code. Because the computation runs on plaintext at hardware speed, TEEs deliver near-native performance, which is why confidential virtual machines and confidential GPUs are the pragmatic path to confidential LLM serving today.

The catch is that a TEE's guarantee is only as strong as the hardware and its isolation. You must trust the chip vendor's design and manufacturing, and the enclave boundary has repeatedly been probed by side-channel and speculative-execution attacks that leak data across it. A TEE defends against a curious or compromised host software stack; it does not, by construction, defend against the hardware vendor itself or against an attacker who breaks the microarchitectural isolation. FHE's threat model has no such caveats because it never relies on an isolation boundary at all — the trade is a much stronger guarantee for a much higher cost.

MPC: distributing the trust

Secure multi-party computation takes a third route: rather than relying on cryptography to hide data from one party or hardware to shield it, it distributes the data and the computation across several parties so that no single one ever sees the whole input. Each party holds only a share, and through an interactive protocol they jointly compute the result; the plaintext is reconstructed only in the output, and only by whoever is entitled to it. The trust root is a non-collusion assumption: the computation is secure as long as fewer than some threshold of the parties conspire.

This distributed trust is attractive precisely when no single party should be trusted but a set of mutually distrustful parties can be assembled — different organizations, different clouds, different jurisdictions — such that their collusion is implausible. The cost of MPC is communication rather than computation: the parties exchange many rounds of messages, so its performance is dominated by network latency and bandwidth, and it is most efficient when the parties are well-connected and the computation is not too deep. The full mechanics of MPC — secret sharing, garbled circuits, and their machine-learning applications — are the subject of a dedicated series, so here it is enough to place it as the non-collusion-rooted member of the trio.

MPC and FHE are close relatives in their guarantees and are often combined: FHE can compress the communication of an MPC protocol, and MPC can distribute the trust in an FHE key so that no single party can decrypt. The point of naming MPC here is comparative — it shows that FHE's cryptographic trust root is not the only alternative to hardware trust, and that the real design space is a choice among cryptography, hardware, and distribution, each defending a different adversary.

Choosing, combining, and the AI stakes

The honest comparison in the table shows there is no universal winner. FHE gives the strongest guarantee — no plaintext, no hardware trust — at the highest compute cost, and suits cases where the provider must be assumed hostile and latency can be relaxed. TEEs give near-native performance and are the practical default for confidential LLM serving today, at the price of trusting hardware and accepting side-channel risk. MPC gives distributed trust with no single point of failure, at the price of heavy communication and the need to assemble non-colluding parties. The choice is a match between the threat model you face and the trust root you can accept.

Increasingly the approaches are combined rather than chosen exclusively. A model can run under FHE inside a TEE, so that a break of the hardware enclave still leaves the attacker facing ciphertext; MPC protocols can use FHE to cut their communication; and confidential-GPU TEEs can host the linear algebra while a cryptographic technique protects the most sensitive step. These hybrids aim to get the performance of hardware with a cryptographic backstop, acknowledging that each single approach has a weakness the others can cover.

For confidential AI the stakes are concrete and immediate. Serving a large language model on prompts that may contain health records, legal matters, or trade secrets demands that the prompt not be exposed to the provider, and the three approaches are the menu for achieving it. FHE is where this series has lived because its guarantee is the strongest and its trajectory — cheaper bootstrapping, better approximations, accelerating hardware — is bending the cost curve toward practicality. But the mature engineering answer is rarely dogmatic: it is to read the threat model honestly, place the trust where it can defensibly go, and often to combine cryptography, hardware, and distribution so that no single failure exposes the plaintext. Choosing a confidential-computing approach is, in the end, choosing where to place trust — and that is a security decision before it is a performance one.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

confidential_serving:
  approaches:
    fhe: { trust: cryptography, cost: compute, adversary: compromised_provider }
    tee: { trust: hardware, cost: near_native, adversary: curious_host }
    mpc: { trust: non_collusion, cost: communication, adversary: colluding_minority }
  decision: match_trust_root_to_threat_model
  hybrids: [fhe_in_tee, mpc_with_fhe]

Glossary

Confidential inference

Running a model so the serving party does not see the plaintext input or output.

Trust root

What a confidential-computing approach ultimately relies on: cryptography (FHE), hardware (TEE), or non-collusion (MPC).

Trusted execution environment (TEE)

A hardware-isolated enclave (confidential CPU/VM or GPU) that processes plaintext shielded from the host, verified by remote attestation.

Remote attestation

A cryptographic proof that a client is communicating with a genuine enclave running the expected code.

Secure multi-party computation (MPC)

A protocol in which several parties jointly compute on shared data without any one seeing the whole input, secure below a collusion threshold.

Non-collusion assumption

The trust root of MPC: security holds as long as fewer than a threshold of the participating parties conspire.

References

1. Gentry, A Fully Homomorphic Encryption Scheme (STOC 2009)
2. Costan, Devadas, Intel SGX Explained (ePrint 2016/086)
3. Van Bulck et al., Foreshadow: Extracting the Keys to the Intel SGX Kingdom (USENIX Security 2018)
4. Yao, How to Generate and Exchange Secrets (FOCS 1986)
5. NIST Privacy-Enhancing Cryptography (PEC) project