Homomorphic Encryption: Still Five Years Away, Now With More Keys

Every cybersecurity conference for the last decade has featured at least one keynote about fully homomorphic encryption (FHE). The pitch is always the same: compute on data without ever decrypting it. The future of privacy. The trust problem, solved. Math so elegant it makes cryptographers misty.

The math really is beautiful. I'll give it that.

It is also, in production, an operational disaster wearing a tuxedo.

If you're a CISO with a budget that exists this fiscal year and infrastructure that has to actually do things, it's worth a sober conversation about what FHE costs — and what it doesn't solve, no matter how many keynotes it gets.

The performance is, technically, a number

Operations on FHE-encrypted data run 100 to 1,000 times slower than on plaintext. The benchmarks read like a practical joke:

Encrypted inference on ResNet-20: over 200× slower than plaintext. After aggressive optimization. After 90% model pruning.

Sorting 128 encrypted elements: about 80 seconds.

Training a three-layer neural network on 60 images: a day and a half.

That last one is not a typo. Sixty images. Day and a half. You could draw the dataset by hand faster than FHE can train on it.

This is not a "throw GPUs at it" problem. It's a tax on every single operation, and the hardware accelerators that would close the gap have been about to ship for roughly the entire history of the field. They live in research labs, like jackalopes.

"We eliminated key exposure" (they did not)

The headline FHE pitch is that data stays encrypted during processing, which sounds like it should reduce key exposure. It does not. FHE needs public keys, private keys, and evaluation keys. The evaluation keys can run into multiple gigabytes for non-trivial operations.

You did not eliminate key management. You gave it a gym membership. You still generate keys, distribute keys, rotate keys, store keys, protect keys, and pray nobody mishandles keys. The lifecycle that keeps your team awake at night is alive, well, and significantly larger than it used to be.

And the math doesn't change the breach pattern, which is the part that should actually worry you. Capital One. LastPass. Uber. Snowflake. In every one of these, the attackers needed two things: data and keys. FHE keeps that second requirement firmly in play, and hands the attacker a bigger key surface to aim at.

Congratulations.

You will need a wizard

FHE is not a thing you pip install and forget. It demands working knowledge of lattice cryptography, noise budgets, bootstrapping, polynomial arithmetic, and parameter selection that trades security against performance in ways that are genuinely subtle. Get the parameters wrong and your ciphertexts dissolve into noise. Get them right and you're still bottlenecked on hardware that mostly doesn't exist outside academia.

The pool of people who can operationalize this in production is small enough to fit in a decent-sized pub, and most of them are professors who are not returning your recruiter's calls.

It's not solving the right problem

Step back from the math. FHE solves a computation problem: how do I run analytics on data I'm not allowed to see? That's a real problem in a small number of contexts. Multi-party computation between mutually suspicious banks. Specific privacy-preserving ML scenarios. A handful of regulated environments where the analyst genuinely cannot be trusted with cleartext.

It is not the problem keeping you awake at 2am.

The problem keeping you awake at 2am is a storage problem. Specifically: when an attacker waltzes in with valid credentials (and they will, because that is how every modern breach works), what do they walk out with?

Modern attackers don't break encryption. They steal access. They compromise IAM, abuse APIs, exploit misconfigured object storage, phish your help desk, and stroll through trusted cloud paths using permissions your organization grants every day. Once they have access to the data and the keys, the encryption is set dressing.

Gartner has a name for the category that actually targets this problem: cyberstorage. Storage that actively participates in cyber resilience instead of sitting in a corner trusting a key vault to never have a bad day.

A different question

HyperSphere SecureStorage was built for a world where compromise is the assumption, not the exception. Instead of asking how do we compute on encrypted data?, we asked a less glamorous question: What if data was encrypted with keys that never existed long enough to be stolen in the first place?

Here's how it works. An application writes data. SecureStorage intercepts it in the data path, splits it into frames, and derives a unique encryption key for each frame in memory. Frames get encrypted independently with quantum-resistant primitives (AES-256-GCM, KMAC-256), distributed across S3-compatible storage, and the keys are immediately erased. There are no persistent keys for an attacker to find, no matter how patient they are.

It runs in cloud, on-prem, hybrid, tactical edge, and disconnected environments. No application rewrites. No infrastructure redesigns. No wizards.

The encryption is real. The protection is real. The entire key management apparatus that FHE preserves and amplifies simply isn't there to compromise.

The right tool for the right problem

If your specific use case genuinely requires computation on encrypted data, FHE is a legitimate research direction. Emphasis on research direction. The math will keep getting better. The hardware will eventually arrive. There will be a small set of problems where the trade-offs make sense, and we should all be glad smart people are working on them.

But if your problem is protecting sensitive data at rest and surviving the next credential compromise (which, statistically, will be on a Tuesday), you don't need to absorb a 200× performance penalty, recruit cryptographers who don't exist, or wait for accelerators to escape the lab.

You need to make the second half of the attack equation — get the keys — structurally impossible.