I could go on, there are wonderful rabbit holes in the world of cryptographic systems, this is just a few I've enjoyed learning about. If it's your thing, I wrote an extended version of this thread with more links and more cat photos. Find it here: eligrubb.com/notes/2025/e...

This tradeoff allows assumptions and optimizations that speedup the total system's complexity. SHE is still an emerging area of research with regular exciting theoretical breakthroughs
eprint.iacr.org/2024/1760

One last approach I want to mention: it turns out *somewhat* homomorphic encryption (SHE) is a thing! Instead of restricting the *type* of encryption-in-use operations, SHE sets an upper-bound on the *complexity* of possible computations over encrypted data.

Another approach is Oblivious RAM (ORAM). While encryption guarantees secrecy, oblivious schemes only guarantee indistinguishability from "similar" computation patterns. Performance gains & you still maintain a haze of deniability.
eprint.iacr.org/2014/997
eprint.iacr.org/2013/280

From startups like @GetBlindInsight to big companies like @MongoDB's Queryable Encryption, searchable encryption is poised to enter production.
www.mongodb.com/docs/manual/...

An underrated approach is Searchable Encryption (SE). With SE, you can search/filter/perform analytics on encrypted data. SE isn't applicable to every computation, but some of the most common needs (sum, avg, count, min, max) have realistic solutions dl.acm.org/doi/10.1145/...

But what can we do, in practice, today?

The term fully homomorphic encryption begs the question, is there such a thing as partially or somewhat homomorphic encryption? Yes!

System design is all about compromise. By softening FHE's guarantees other approaches gain performance.

For the record, many people much smarter than I are all in on FHE, and I'm still bullish on it long term.

A 27,840,000-34,133,133X gap between FHE and unencrypted computation that only grows as the computation's complexity does.

This back-of-the-napkin math doesn't take into account the M1's multiple cores or the CPU's internal parallelism.

Let's compare Zama's encrypted results, performed on a 192-core, 768 GiB memory AWS hpc machine, with the unencrypted performance of Apple's M1 chip.

An M1 add is ~1 cycle and mul is ~3 cycles. On a 3.2GhZ chip, that's 0.0000003125 ms per add, and 0.0000009375 ms per mul.

For example, Zama's recent blog post cites impressive speedups to 64-bit encrypted add and multiply, clocking in at 8.7 ms and 32 ms, respectively.

That's a real milestone and cool to see! I recommend you check out the full post for all the juicy details:
www.zama.ai/post/bootstr...

FHE's draw comes from its universality, it's called *fully* homomorphic for a reason. But performance concerns in practical use are real.

Laurie references recent speedups; unfortunately most breakthroughs fail to address FHE's complexity, instead optimizing constant factors.