So, Is Homomorphic Encryption Slow? Let’s Talk Numbers

Intro

Homomorphic encryption keeps your vectors encrypted even while they’re being searched — great. But isn’t it slow?

It was. Past tense. The “impractically slow” reputation comes from benchmarks a decade out of date. The short version: FHE throughput has improved a billion-fold in ten years, driven by a scheme called CKKS — and in the workload that matters, searching encrypted data, it’s now faster than the decrypt-then-search pipeline it replaces.

A Billion-Fold in a Decade

Fully homomorphic encryption was invented in 2009 (Gentry, Stanford). The first generation was a proof of concept — and completely unusable. The second (BGV/BFV, 2011) enabled the first real applications; the third (CGGI, 2016) handled small-scale data.

Then came the fourth generation: CKKS, invented in Korea in 2017 (Cheon-Kim-Kim-Song, Seoul National University). CKKS was the first scheme designed to compute on real numbers — the arithmetic that machine learning and vector search actually use — and it took FHE from small-scale demos to large-scale data. Its 2024 iteration, CKKS+, pushed throughput from megabytes into gigabytes.

Plot that on a log scale: KB-scale throughput in 2009, GB-scale today. A billion-fold speedup in a decade. CKKS now leads global FHE standardization, with an ISO standard expected in 2026 — and it’s quantum-resistant, too.

Faster Than AES? In the Pipeline That Matters, Yes

Your encrypted data sits on a cloud server and you want to search it. With conventional AES-256, the server can’t compute on ciphertext, so the pipeline is: decrypt first, then search. Decryption runs at about 200 MB/s — and during the search, your data sits in plaintext in someone else’s memory. Exactly the exposure the last post warned about.

With CKKS, there is no decryption step. The server searches the ciphertext directly, at about 2 GB/s.

The encrypted path is 10x faster than the decrypt-then-search path. The step that was both the bottleneck and the breach risk is gone. You don’t trade speed for security — both come from the same design decision.

Encrypted LLMs: 8x Faster Than NVIDIA’s Published Result

Running a full LLM under encryption — every matrix multiplication on ciphertext — is the stress test. Here’s where the field stands:

NVIDIA’s published encrypted Llama 3-8B result: 134 seconds to first token on eight B200s. Three months later, our CKKS implementation ran the same model and token count in 15 seconds — on consumer RTX 5090s. An 8.4x speedup on far cheaper hardware, with decoding at about 1 second per token after prefill.

Summary

1. FHE’s slow reputation is a decade stale: a billion-fold throughput gain since 2009, driven by CKKS — invented in Korea, ISO standardization expected in 2026.
2. CKKS searches ciphertext at ~2 GB/s; the AES decrypt-then-search alternative runs at 200 MB/s and exposes plaintext. 10x faster, no breach surface.
3. Even full LLM inference runs encrypted at practical speed: 15s to first token, 8.4x faster than NVIDIA’s published result.

The question is no longer whether homomorphic encryption is fast enough. It’s whether you can still justify searching sensitive data in plaintext.

—————————————————————————————–

enVector runs similarity search directly over homomorphically encrypted vectors — powered by CKKS, encrypted client-side, never decrypted on the server. Deploy it from Google Cloud Marketplace: https://console.cloud.google.com/marketplace/product/heaan-public/envector-sm

References: Scaling up Privacy-Preserving ML: A CKKS Implementation of Llama-2-7B. arxiv.org/abs/2601.18511 Jayashankar et al. “A Scalable Multi-GPU Framework for Encrypted Large-Model Inference.” arxiv.org/abs/2512.11269 HEaaN Llama 3-8B result: RWC 2026, 8 × RTX 5090.