# Beyond Encryption: How FHE, SMPC, ZKPs, and TEEs Actually Work in Practice

## Introduction

Most people think encryption ends at locking data away from attackers. But in reality, today's biggest challenge is not just protecting data at rest, but using it securely while keeping it private. That is where advanced privacy-preserving computation comes in.

Technologies like **Fully Homomorphic Encryption (FHE)**, **Secure Multi-Party Computation (SMPC)**, **Zero-Knowledge Proofs (ZKPs)**, and **Trusted Execution Environments (TEEs)** are quietly reshaping how we process sensitive information. From encrypted AI models to collaborative financial analytics, these techniques offer different answers to a common problem: **how to compute on data without exposing it.**

## Fully Homomorphic Encryption(FHE)

FHE allows data to be encrypted in a special way so that mathematical operations can be performed directly on the encrypted form. This is done using complex number systems called **lattices**, and it replaces regular addition/multiplication with **homomorphic equivalents** that work on ciphertext.

For example : When you encrypt a number (say 10), it becomes a random-looking encrypted value. You can still add or multiply it with other encrypted numbers, and the final result once decrypted matches what it *would have* if you had used the raw numbers.

Even with GPUs, FHE adds 1000x latency (Google's FHE transpiler still can't handle real-time workloads

```mermaid
flowchart TD
    classDef darkFill fill:#1a1a2e,stroke:#6dd5ff,stroke-width:2px,color:#fff
    classDef opNode fill:#16213e,stroke:#00d4ff,stroke-width:2px,color:#fff
    classDef result fill:#4e54c8,stroke:#6a3093,stroke-width:2px,color:#fff

    A[("🔒 Input Data")]:::darkFill --> B["Encrypt\n(Lattice Cryptography)"]:::opNode
    B --> C{{"Ciphertext"}}:::darkFill
    C --> D["Add/Multiply\n(Homomorphic Ops)"]:::opNode
    D --> E["Bootstrap\n(Noise Reduction)"]:::opNode
    E --> F{{"Encrypted Result"}}:::darkFill
    F --> G["🔓 Decrypt"]:::opNode
    G --> H[("Result")]:::result

    style A stroke-dasharray: 5 5
    style H stroke-dasharray: 5 5
```

#### Technologies Used

* **Circom + snarkjs** – Build circuits and generate zk-SNARKs in JS
    
* **zkSync** – ZK rollups for Ethereum L2
    
* **Zokrates** – ZKP toolkit for smart contracts (Rust + Solidity)
    
* **Halo2** – Used in privacy coins like Zcash
    
* **STARKWare** – zk-STARKs used in blockchain scalability
    

### Microsoft SEAL, Python wrapper

```python
from seal import EncryptionParameters, SEALContext, KeyGenerator, CKKSEncoder, Encryptor, Decryptor, Evaluator, scheme_type

parms = EncryptionParameters(scheme_type.CKKS)
parms.set_poly_modulus_degree(8192)
parms.set_coeff_modulus(seal.CoeffModulus.Create(8192, [60, 40, 40, 60]))
context = SEALContext.Create(parms)

keygen = KeyGenerator(context)
encryptor = Encryptor(context, keygen.public_key())
decryptor = Decryptor(context, keygen.secret_key())
encoder = CKKSEncoder(context)

scale = 2**40
x = encoder.encode(5.0, scale)
y = encoder.encode(3.0, scale)

enc_x = encryptor.encrypt(x)
enc_y = encryptor.encrypt(y)
enc_result = Evaluator(context).add(enc_x, enc_y)

dec_result = decryptor.decrypt(enc_result)
decoded = encoder.decode(dec_result)

print(decoded[0])  # Output: approx. 8.0
```

**Company:** IBM  
**Example:** IBM’s **HElib** library powers homomorphic encryption-based AI models in healthcare and finance.  
**Use Case:** IBM Research helped implement privacy-preserving disease prediction by letting hospitals run AI models on encrypted patient data **without ever decrypting it.**

## Secure Multi-Party Computation(SMPC)

SMPC works by **splitting data into “shares”** that are mathematically meaningless on their own. Each party holds only a share of the data, and computations happen across these shares. The parties follow a protocol to perform operations like addition, multiplication, or comparisons, without ever combining their full inputs.

For example, to add two secret numbers, each party computes its share of the result independently. When the shares are combined, the final answer appears, but no individual share reveals the original input.

```mermaid
flowchart TD
    classDef participant fill:#f0f4ff,stroke:#2563eb,stroke-width:1.5px,color:#1e3a8a
    classDef protocol fill:#e0f2fe,stroke:#0369a1,stroke-width:1.5px,color:#0c4a6e
    classDef output fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px,color:#065f46

    P1[["Party A<br/>(Input X)"]]:::participant
    P2[["Party B<br/>(Input Y)"]]:::participant
    P3[["Party C<br/>(Input Z)"]]:::participant

    P1 -->|Share X₁,X₂,X₃| S[["Secure Computation Phase"]]:::protocol
    P2 -->|Share Y₁,Y₂,Y₃| S
    P3 -->|Share Z₁,Z₂,Z₃| S

    S --> C1[["Add/Multiply Shares"]]:::protocol
    C1 --> C2[["Recombine Partial Results"]]:::protocol
    C2 --> R{{"Final Output<br/>(e.g., X+Y+Z)"}}:::output

    style P1 stroke:#7c3aed
    style P2 stroke:#db2777
    style P3 stroke:#059669
    style S stroke-dasharray: 3 3
```

#### Technologies Used

* **MP-SPDZ** – Modern and actively maintained for benchmarking protocols
    
* **CrypTen** – Built by Facebook, supports PyTorch-style SMPC
    
* **Sharemind** – Commercial-grade SMPC platform
    
* **PySyft** – SMPC in federated learning using PyTorch
    
* **EMP Toolkit** – Efficient MPC implementation in C++
    

### **SMPC with CrypTen (PyTorch-style secure computation)**

```python
import crypten
import torch

# Initialize CrypTen
crypten.init()

# Create plaintext tensors
x = torch.tensor([10.0])
y = torch.tensor([5.0])

# Encrypt tensors into secure cryptensors
x_enc = crypten.cryptensor(x)
y_enc = crypten.cryptensor(y)

# Perform secure addition
enc_result = x_enc + y_enc

# Reveal the decrypted result
print(enc_result.get_plain_text())  # Output: tensor([15.])
```

**Company:** Visa  
**Example:** Visa is working with cryptography startup **Inpher** to use SMPC for privacy-preserving analytics.  
**Use Case:** Multiple banks can analyze fraud trends collaboratively without revealing sensitive user data to each other.

## Zero-Knowledge Proofs (ZKPs)

ZKPs rely on interactive or non-interactive cryptographic protocols that let someone prove they know a fact or secret **without revealing any part of it**. Think of it like answering a riddle that only someone with the answer could solve, but without ever stating the answer.

For example, imagine you need to prove you know a password without telling it. A ZKP lets you answer a challenge based on that password in a way that proves you know it but the password itself never gets revealed. The verifier becomes convinced you’re legit, even though they never saw your secret.

ZKPs are already used in identity systems where users prove they’re over 18 without revealing their age this has major impact in privacy-first KYC systems

```mermaid
flowchart TD
    classDef darkFill fill:#1e1e1e,stroke:#2ecc71,stroke-width:2px,color:#fff
    classDef proof fill:#27ae60,stroke:#2ecc71,stroke-width:2px,color:#fff
    classDef verify fill:#3498db,stroke:#2ecc71,stroke-width:2px,color:#fff

    A[("🤫 Secret")]:::darkFill --> B["Arithmetize\n(R1CS/QAP)"]:::darkFill
    B --> C["Generate Proof\n(zk-SNARK)"]:::proof
    C --> D{{"Proof"}}:::darkFill
    D --> E["Verify"]:::verify
    E --> F{{"✅ Valid / ❌ Invalid"}}:::darkFill

    style A stroke-dasharray: 5 5
    style F stroke-dasharray: 5 5
```

#### Technologies Used

* **Circom + snarkjs** – Build circuits and generate zk-SNARKs in JS
    
* **zkSync** – ZK rollups for Ethereum L2
    
* **Zokrates** – ZKP toolkit for smart contracts (Rust + Solidity)
    
* **Halo2** – Used in privacy coins like Zcash
    
* **STARKWare** – zk-STARKs used in blockchain scalability
    
    #### ZKPs with ZoKrates
    
    Zokrates is a popular toolkit for writing zero-knowledge circuits in Ethereum. You'll create a circuit, compile it, generate a witness, a proof, and verify it.
    
    ```python
    def main(private field x, field y) -> (field):
        assert(x * x == y)
        return y
    ```
    

```bash
zokrates compile -i square.zok
zokrates setup
zokrates compute-witness -a 3 9        # Proves that x=3 and y=9
zokrates generate-proof
zokrates verify                        # Output: Verification successful==
```

**Company:** ConsenSys / Zcash  
**Example:** **Zcash** is the most well-known cryptocurrency that uses ZK-SNARKs for private transactions.  
**Use Case:** A user sends money on the blockchain, and the network verifies the transaction is valid **without revealing the amount, sender, or receiver.**

## Trusted Execution Environments (TEEs)

TEEs are **secure zones within a processor** that isolate code and data from the rest of the system. When a program runs in a TEE, even the operating system, hypervisor, or cloud provider cannot access what’s inside.

For example, a banking app sends sensitive customer data to the cloud. Instead of processing it openly, it runs inside a secure hardware bubble (the TEE). The data is decrypted only inside this isolated zone, processed securely, and then encrypted again before leaving. Even the cloud provider can’t peek inside during execution.

Intel SGX has faced 15+ side-channel attacks since 2018 (see CVE-2021-0127)

```mermaid
flowchart TD
    classDef darkFill fill:#1a1a1a,stroke:#f39c12,stroke-width:2px,color:#fff
    classDef enclave fill:#e67e22,stroke:#f39c12,stroke-width:2px,color:#000
    classDef result fill:#d35400,stroke:#f39c12,stroke-width:2px,color:#fff

    A[("Untrusted Host")]:::darkFill --> B["Create Enclave\n(SGX/SEV)"]:::enclave
    B --> C{{"Secure Zone"}}:::enclave
    C --> D["Decrypt & Compute"]:::enclave
    D --> E["Encrypt Result"]:::enclave
    E --> F[("Output")]:::result

    style A stroke-dasharray: 5 5
    style F stroke-dasharray: 5 5
```

#### Technologies Used

* **Intel SGX SDK** – Used for desktop and server enclave development
    
* **ARM TrustZone** – Secure zones on mobile processors
    
* **AWS Nitro Enclaves** – Cloud-native TEEs for secure EC2 processing
    
* **OpenEnclave SDK** – Unified framework for building TEE apps
    
* **Fortanix** – Commercial TEE platform with privacy-preserving SaaS
    

**Company:** Microsoft Azure  
**Example:** **Azure Confidential Computing** enables secure data processing inside Intel SGX-based TEEs.  
**Use Case:** Financial services and healthcare companies process sensitive data in the cloud while protecting it from even the cloud provider.

### Execution

```c
#include <stdio.h>
#include "sgx_urts.h"
#include "Enclave_u.h"
#include "Enclave_t.h"

// Enclave function definition
void ecall_add(int a, int b, int* result) {
    *result = a + b;  // Computation happens securely inside TEE
}

int main() {
    sgx_enclave_id_t eid;
    sgx_status_t status;

    // Create the enclave
    if (sgx_create_enclave("Enclave.signed.so", SGX_DEBUG_FLAG, NULL, NULL, &eid, NULL) != SGX_SUCCESS) {
        printf("Enclave creation failed.\n");
        return 1;
    }

    int result = 0;

    // Call the secure enclave function
    ecall_add(eid, 6, 4, &result);

    // Print result computed inside TEE
    printf("Result from enclave: %d\n", result);  // Output: 10

    // Destroy the enclave
    sgx_destroy_enclave(eid);
    return 0;
}
```

| Feature / Tech | **FHE (Fully Homomorphic Encryption)** | **SMPC (Secure Multi-Party Computation)** | **ZKP (Zero-Knowledge Proofs)** | **TEE (Trusted Execution Environments)** |
| --- | --- | --- | --- | --- |
| **Main Goal** | Compute on encrypted data without decrypting | Joint computation without revealing inputs | Prove something without revealing it | Secure processing inside hardware enclave |
| **Trust Model** | No trust required in computation party | Parties don't trust each other | Verifier trusts cryptographic proof | Trust the hardware (CPU vendor) |
| **Data Privacy** | Data stays encrypted end-to-end | Input data stays private between parties | No input data shared | Data is decrypted inside secure enclave |
| **Real-Time Use** | Not suitable due to high latency | High latency for large tasks | Yes (especially for authentication) | Near real-time performance |
| **Computation Type** | Arbitrary functions on encrypted data | Limited by protocol complexity | Only proves knowledge, not compute | Full computation with plaintext access |
| **Performance** | Very slow, resource-intensive | Moderate to high overhead | Efficient (depends on use case) | Fast (near-native speed) |
| **Deployment Ease** | Complex setup, library support limited | Complex coordination between parties | Easier with existing libraries | Easy on supported hardware (Intel SGX, ARM TrustZone) |
| **Quantum Attacks** | Resistant | Resistant | Resistant (only with STARKs) | Vulnerable |
| **Side-Channel Attacks** | None | Protocol-dependent | None | CPU-based vulnerabilities (e.g., Spectre, Meltdown) |

```mermaid
graph TD
    classDef question fill:#f5f7fa,stroke:#4a5568,stroke-width:1.5px,color:#2d3748,font-weight:600
    classDef tech fill:#ffffff,stroke:#4299e1,stroke-width:1.5px,color:#2d3748,font-weight:500
    classDef arrow stroke:#718096,stroke-width:2px

    A["① Need to compute on encrypted data?"]:::question
    B["② General-purpose computation needed?"]:::question
    C[["FHE<br/><i>Fully Homomorphic Encryption</i>"]]:::tech
    D[["ZKPs<br/><i>Zero-Knowledge Proofs</i>"]]:::tech
    E["③ Multiple parties involved?"]:::question
    F[["SMPC<br/><i>Secure Multi-Party Computation</i>"]]:::tech
    G["④ Performance critical?"]:::question
    H[["TEEs<br/><i>Trusted Execution Environments</i>"]]:::tech

    A -->|Yes| B
    A -->|No| E
    B -->|Yes| C
    B -->|No| D
    E -->|Yes| F
    E -->|No| G
    G -->|Yes| H
    G -->|No| C

    style C stroke:#667eea
    style D stroke:#48bb78
    style F stroke:#ed8936
    style H stroke:#9f7aea

    linkStyle 0,1,2,3,4,5,6,7 stroke:#a0aec0
```

## Adoption challenges

* **FHE:** Hardware acceleration need
    
* **SMPC:** Network overhead and trust assumptions
    
* **ZKPs:** Proof generation times or circuit complexity
    
* **TEEs:** Vendor lock-in (Intel/ARM) and patch risk
    

## **Key Takeaways & Future Outlook**

Each privacy preserving technique has its strengths and tradeoffs. FHE offers strong encryption but is slow. SMPC enables collaboration without data sharing but needs coordination. ZKPs prove facts without revealing them but can be complex to design. TEEs are fast but rely on trusted hardware. The future lies in combining these tools to balance privacy, speed, and trust. As platforms evolve, secure computation will become more practical for real world use.