Homomorphic Encryption in Python—
Compute on Encrypted Data Without Decrypting

What Is Fully Homomorphic Encryption?

Fully homomorphic encryption (FHE) is the holy grail of cryptography. It lets you compute on encrypted data without ever decrypting it. You encrypt your data, send the ciphertext to a server, the server processes it—adds, multiplies, runs algorithms—and sends back an encrypted result. You decrypt the result and get the correct answer. The server never sees your plaintext data at any point during the computation. Not during processing, not in memory, not in logs, not ever.

This sounds impossible, but the math has been proven since Craig Gentry's breakthrough in 2009. The challenge has always been performance. Early FHE schemes were millions of times slower than plaintext computation. A single encrypted multiplication could take seconds. For 15 years, FHE was an academic curiosity—mathematically elegant, practically useless. Researchers published papers. Nobody shipped products.

That changed. Modern FHE schemes—BFV for exact integer arithmetic, CKKS for approximate floating-point, BGV for modular arithmetic—combined with hardware-aware implementations have collapsed the performance gap to the point where FHE is production-viable for real workloads. H33 runs 2.17 million FHE-based authentications per second on a single Graviton4 instance. 38.5 microseconds per auth. That's not a lab result. That's a sustained 120-second benchmark on production hardware. The gap between "encrypted" and "fast" has closed.

The H33 Approach: 4 Engines, 1 API

FHE isn't one algorithm. It's a family of schemes, each optimized for different types of computation. Choosing the wrong scheme for your workload doesn't just slow things down—it can make the computation impossible. A scheme designed for exact integers can't do floating-point arithmetic. A scheme optimized for SIMD batching wastes resources on single-value operations. H33 runs four FHE engines and routes your computation automatically.

FHE-IQ is the key innovation for developers. You describe what you want to compute, and FHE-IQ selects the optimal engine, parameter set, and batching strategy. It analyzes the computation's multiplicative depth, plaintext modulus requirements, and precision needs, then routes to the right engine. You write application code. H33 handles the cryptography.

Python Example: Encrypt, Compute, Decrypt

Let's encrypt two numbers, multiply them while encrypted, and decrypt the result. The server that performs the multiplication never sees either number or the product.

import requests

API = "https://api.h33.ai/v1/fhe"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

# Step 1: Encrypt two values
ct_a = requests.post(f"{API}/encrypt", headers=HEADERS,
    json={"value": 42, "scheme": "auto"}).json()["ciphertext_id"]

ct_b = requests.post(f"{API}/encrypt", headers=HEADERS,
    json={"value": 7, "scheme": "auto"}).json()["ciphertext_id"]

# Step 2: Multiply while encrypted — server never sees 42 or 7
ct_result = requests.post(f"{API}/multiply", headers=HEADERS,
    json={"a": ct_a, "b": ct_b}).json()["ciphertext_id"]

# Step 3: Decrypt the result
result = requests.post(f"{API}/decrypt", headers=HEADERS,
    json={"ciphertext_id": ct_result}).json()["value"]

print(f"Encrypted 42 * 7 = {result}")  # Output: 294

That's the entire flow. scheme: "auto" tells FHE-IQ to pick the engine. For integer multiplication, it selects BFV (H33-128). If you encrypted floating-point values, it would route to CKKS. If you specified scheme: "bfv" or scheme: "ckks", you'd bypass auto-routing and use that engine directly. The ciphertext IDs are opaque references to encrypted values stored on H33's infrastructure. The plaintext values never leave your machine—they're encrypted client-side before transmission.

H33-Compile: The @h33.compile Decorator

The REST API works, but it's verbose for complex computations. H33-Compile lets you write normal Python functions and run them on encrypted data with a single decorator. You write Python. H33 compiles it to FHE circuits.

import h33

@h33.compile
def credit_score(income, debt, payment_history):
    """Compute credit score on encrypted financial data."""
    debt_ratio = debt / income
    score = 850 - (debt_ratio * 300) + (payment_history * 50)
    return score

# Encrypt inputs — the function runs entirely on ciphertext
encrypted_income = h33.encrypt(85000)
encrypted_debt = h33.encrypt(12000)
encrypted_history = h33.encrypt(0.95)

# Execute on encrypted data — H33 never sees the values
encrypted_score = credit_score(encrypted_income, encrypted_debt, encrypted_history)

# Decrypt the result
print(f"Credit score: {h33.decrypt(encrypted_score)}")  # ~855

The @h33.compile decorator analyzes the function's computation graph—arithmetic operations, control flow, data dependencies—and compiles it to an FHE circuit. FHE-IQ selects the optimal scheme (CKKS in this case, because of the division and floating-point arithmetic). The function executes on ciphertext from start to finish. H33's servers compute the credit score without ever seeing the income, debt, or payment history. The bank gets a score. The customer's financial data stays encrypted.

Biometric Matching on Ciphertext

This is where FHE gets transformative. Traditional biometric authentication requires the server to see your biometric template—your fingerprint encoding, face embedding, iris scan. If the server is breached, your biometrics are exposed. Unlike passwords, you can't rotate your fingerprints.

With H33's FHE biometric matching, the server computes the similarity between your live scan and your enrolled template without decrypting either one. The biometric data stays encrypted during the entire comparison. The server outputs an encrypted match/no-match result.

import h33

# Enroll: encrypt the biometric template (128-dim vector)
template = [0.23, 0.87, 0.45, ...]  # 128 dimensions
enrolled = h33.fhe.enroll_biometric(template)
# Returns: encrypted template ID — server never sees the vector

# Verify: encrypt a live scan, compare on ciphertext
live_scan = [0.24, 0.86, 0.44, ...]  # New capture
result = h33.fhe.verify_biometric(enrolled, h33.encrypt(live_scan))

print(f"Match: {result['match']}")      # True/False
print(f"Latency: {result['latency_us']}µs")  # ~38.5µs

The inner product between the encrypted template and encrypted live scan is computed using BFV's SIMD batching—32 users per ciphertext, 128 dimensions per user, all packed into 4,096 polynomial slots. One ciphertext multiply computes 32 biometric comparisons simultaneously. The result is an encrypted similarity score that's decrypted only to produce a binary match/no-match decision. The server never sees the biometric. The server never sees the similarity score. The server sees nothing.

AI-Blind: Let AI Process Your Data Without Seeing It

FHE enables a new category of AI: models that process your data without observing it. We call this AI-Blind. The model runs inference on encrypted inputs and produces encrypted outputs. The model operator learns nothing about your data. You learn nothing about the model's weights (protecting IP). Both parties benefit.

AI-Blind is not theoretical. H33-CKKS supports the approximate arithmetic that neural networks require. Linear layers, polynomial activations, and softmax approximations all work on CKKS ciphertext. The precision loss from CKKS approximation (~10^-7) is well within the noise tolerance of modern neural networks. You can run encrypted inference on models up to several hundred million parameters with acceptable latency for batch processing. Real-time inference on encrypted data is viable for smaller models and specific layers of larger models.

Production Performance

This isn't academic FHE running in a research lab. These are production numbers from H33's Graviton4 infrastructure, independently benchmarked and reproducible.

The key to H33's performance: we don't use general-purpose FHE libraries. The BFV engine uses Montgomery NTT with Harvey lazy reduction, NEON-accelerated Galois operations, pre-NTT public keys, NTT-domain enrolled templates, and batch CBD sampling. Every hot-path operation has been profiled and optimized at the assembly level for ARM Graviton4 (192 vCPUs, 377 GiB RAM). The result: 939 microseconds to batch-process 32 biometric authentications with FHE encryption, inner product, and decryption.

For comparison, Microsoft SEAL (the most popular FHE library) processes a single BFV multiplication in ~2 milliseconds on an Intel server. H33 processes 32 multiplications in 939 microseconds on Graviton4. The performance difference isn't incremental—it's a different class of engineering. This is what makes FHE production-ready instead of a science project.

Score Your Encryption Readiness

What's Next

You've seen FHE in action: encrypt data, compute on ciphertext, decrypt the result. Here's where to go deeper: