// HACKER NEWS — CYBERSECURITY
Updates on HEIR, the Homomorphic Encryption Compiler Project
On 2026-08-14 I published
an article on the Google Security blog
with an update on HEIR, our homomorphic encryption (HE) compiler.
This is a companion article,
in which I have no limits on word count or jargon,
and I can feel free to be honest.
So strap in.
Assuming you won’t read the linked corporate blog post,
HEIR is a compiler that converts an input program to
a program that operates directly on encrypted data.
The guarantee of homomorphic encryption is that,
assuming you haven’t cracked the cryptography,
at no point does the computer running the program
get even a single bit of information about the cleartext data
used to generate the encrypted inputs.
No information about the inputs, outputs,
or any intermediate values.1
The blog post focuses on HEIR’s ability
to compile pre-trained ML models,
and gives four examples of small, but nontrivial models
that it can compile.
Hence, homomorphic encryption can enable services
to provide perfectly private inference.
I’ll try to say more about when and where this is useful later in this article.
First I wanted to give a more concrete sense
for how HEIR works in the context of these examples,
and outline (my view on) the project’s roadmap for the future.
I won’t do a deep dive on HEIR’s internals by any means,
since that would make the article too long.
Give me a shout if you want that, but there are plenty of docs
to read through at heir.dev
and you can see a recent (fast-paced)
talk
I gave at ASPLOS this year.
The blog post ends with a list of examples compiled with HEIR.
Those examples point to a GitHub repository2
that you can clone and run yourself.
The biggest hurdle is installing bazel,
and then bazel hermetically manages everything else.3
The simplest and fastest example to try is the
credit card fraud detector.
This is a simple three-layer feed-forward network with sigmoid activations,
trained on a Kaggle dataset.
The linear layers have dimensions 128, 64, and 2 (the last being the logits for the two classes, fraud and not-fraud).
This command will compile the (pre-trained, checked-in) cc_fraud model
to the Lattigo backend, and then
run it on a sample input. The command above outputs:
The central point here is that the evaluation of the model on encrypted inputs
took about 2 seconds on a single-threaded CPU.
Compare this to the same execution on cleartext inputs, noting that this is the
latency of a single inference, so it doesn’t benefit from amortization. (This
requires fetching and encoding the original dataset, which is explained in the
README;
I’ll skip that part here).
Anyone who has heard of HE may have heard that it is slow, but I want to pause
here to compare this (single-threaded CPU, non-amortized!) runtime: 2 seconds
for HE inference vs 0.5 ms for cleartext. This is a 4,000x slowdown, and the
computation involves two matrix-vector products (where the matrix is not
private), with two evaluations of a sigmoid function.
There are many caveats to this demo worth briefly noting: