Skip to content
Published on

The HEIR Homomorphic Encryption Compiler and the Condition Called Cost — When the Comments Supply the Number the Announcement Omits

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Google is making private AI practical with homomorphic encryption, the item number is 49300314, and as of 2026-08-15 it stood at 234 points with 143 comments. The link points to a post on the Google security blog.

What the announcement introduces is HEIR, an open source compiler toolchain and development platform. The name itself stands for a homomorphic encryption intermediate representation, and it converts pre-trained models to operate on ciphertext.

The news is the compiler, not the cryptography

Homomorphic encryption is not new. Adding and multiplying over ciphertext and getting ciphertext back has been known for a long time. Deployments are rare, but not for want of mathematics.

The real barrier is parameter selection. In homomorphic encryption, noise accumulates as operations pile up, and once it passes a limit the decrypted result collapses. So designing a circuit means computing a noise budget, deciding where to bootstrap to reset that budget, and deciding how to pack multiple values into ciphertext slots.

These decisions are entangled. Change the packing and the required rotations change, which changes the noise growth rate, which changes where bootstrapping has to go. And if any one of them is wrong, the result breaks silently. Not many people in the world can do this by hand, and that has been the practical reason this technology stayed in papers.

What the announcement claims for HEIR sits exactly there: it moves those decisions into compiler passes, so a cryptographer does not have to be attached to every project. That is also why there is an intermediate representation — the structure lets the same optimizations be reused across several backends and several schemes.

This is a familiar story. What makes a technology widely used is usually not an improvement in the technology itself but the moment tooling absorbs the expertise required to use it.

The number the announcement does not give

But there is a decisive blank in this announcement: there is not a single overhead figure.

It mentions latency measurements on a single-threaded CPU, yet no concrete time and no multiplier appears. Instead it acknowledges that homomorphic encryption carries a nontrivial cost overhead, framing that as shifting the capability-versus-privacy trade-off into a question of cost.

That framing is not wrong, but calling something a question of cost without saying what the cost is leaves the reader unable to judge.

The comments filled that blank

The most information-dense part of this item was the comments, where several people stated their background and supplied numbers.

A commenter writing a master's thesis on privacy-preserving machine learning wrote that homomorphic encryption and related techniques carry roughly a thousandfold overhead on inference tasks, and are therefore hard to justify commercially. Another comment cited resource usage of more than a thousand times. A third said their understanding was that even basic operations were thousands of times more complex, and asked whether there had been a major advance since.

A commenter who has published two papers in the area summed it up as welcome that large players are producing usable tooling, but still far from commercial viability. Someone who researched the field twenty years ago recalled that their conclusion then was that ciphertext expansion was the biggest bottleneck. That point still holds, because people often look only at compute time and leave out storage and transfer cost.

So where does it apply?

Overlaying the four demonstrations in the announcement with those numbers makes the conditions sharp. The cases are a deep learning recommendation system, credit card fraud detection, network intrusion detection based on Kitsune, and hotword detection for audio privacy.

They share four properties.

  • The models are small. Fraud detection and hotword detection are not large-parameter models. A thousandfold overhead is only survivable when the base cost is small.
  • Inputs are small and outputs smaller. Typically a feature vector goes in and one score or one label comes out. The impact of ciphertext expansion is bounded.
  • The computation is shallow. Fewer layers means less accumulated noise, so bootstrapping can be reduced or avoided entirely.
  • The data is sensitive and the latency budget is loose. These are services that still work when a few hundred milliseconds become a few seconds.

Inverting that gives where it does not apply immediately. Large language model inference violates all four: the model is big, inputs and outputs are long, the network is deep, and a user is waiting. Do not read this announcement as meaning you can now run a model on an encrypted prompt. The announcement makes no such claim.

How to apply this

The test for whether this is worth evaluating now is simple: in your workload, is the value of keeping the server from seeing plaintext greater than a thousandfold compute cost?

That is true more often than you might think. Several institutions that must combine data but cannot hand over originals due to regulation; a product where the provider's inability to see the data is itself the selling condition; an audited context where access must be technically blocked rather than merely prohibited. In those places, overhead becomes a negotiable line item.

And if you do evaluate, there is an order. First, rule out the cheaper alternatives. Inference on the device, extracting only features before sending to the server, a trusted execution environment, differential privacy releasing aggregates only — all are far cheaper. One comment noted that the most private inference is the one running on your own hardware; that is not a snipe, it is genuinely the first option to consider. This thread is covered in on-device AI and privacy in edge inference.

When none of those hold — when the computation must happen on a server and the server must never see the contents — that is the seat where homomorphic encryption is the only answer.

Who this does not apply to

If you run an ordinary web service with encryption at rest and in transit, you do not need this now. Those two defend against different threats on the premise that the server can see the data, and most regulatory requirements are satisfied there.

Services where performance is the core of the product are also out. A thousandfold is not a gap you close with tuning.

If you are planning a cryptographic roadmap, be clear that this and the migration to post-quantum cryptography are separate work. The latter is a migration with a deadline; the former is still an optional capability. That distinction pairs well with migrating to post-quantum cryptography.

Summary

What actually advanced in this announcement is not cryptographic performance but accessibility. When a compiler absorbs an expert's judgment, the number of people who can use the technology grows, and that is frequently the real condition for adoption. But an announcement that calls something a question of cost while omitting the cost has told you only half, and the other half was in this item's comments. It is also a case study in why discussion is worth reading when the number you need to decide is missing from the source.

Sources and related reading

The four applicability conditions and the evaluation order are my own, built on the announcement and the comments.

Discuss on Twitter • View on GitHub