Today my team at Google published an article on Google’s Developers Blog with some updates on what we’ve been doing with fully homomorphic encryption (FHE). There’s fun stuff in there, including work on video processing FHE, compiling ML models to FHE, an FHE implementation for TPUs, and improvements to the compiler I wrote about earlier this year.
TODO: add mower gif video
A simple object movement tracking algorithm in FHE, tracking a runaway lawn mower from a Nest camera. The video is 720p.
But as we’ve inched closer to having production clients, the more gaps we’ve found in our existing tool set. Teams interested in using FHE have seasoned, complex C/C++ codebases, or serious ML models. The parts where the computation should be private are interspersed with all sorts of FHE-incompatible constructions (or at least, incompatible with the assumptions in our compiler). They have certain latency and bandwidth constraints, or a nuanced key management story, and it became clear to us that bringing FHE to production will require a stronger engineering foundation.
At the same time, my team and I had the pleasure of traveling to Seoul and Tokyo for this year’s flagship FHE workshops, the HE.org standards meeting and the FHE.org conference. My talk at the former presented this engineering problem and proposed MLIR as a common foundation that everyone working on FHE compilers can share.
We found kindred spirits among the attendees from ETH Zurich, Zama, Yonsei Univeristy, and others who had each implemented some flavor of FHE compiler on top of MLIR. We also met many folks working on hardware accelerators for FHE, everything from FPGAs to optical accelerators, and we agreed that getting fair evaluations across hardware and across FHE schemes is hindered by the current tooling and research silos. After a rousing discussion session, we decided to start work on a project we’re calling Homomorphic Encryption Internal Representation (HEIR, see website and GitHub), which we aim to make a standardized and “batteries included” starting point for researchers and practitioners interested in FHE compilers, as well as the basis for Google’s future compiler work.
The project is still very much in its early stages. The GitHub repository is quite sparse so far and we have no end-to-end compilation paths yet. But I’m excited and energetic about it, and working on it will be the bulk of my full time job for now. We also had a warm reception from the MLIR community. They’re going out of their way to help me sort through my MLIR questions, and some have expressed interest in upstreaming some of our more general ideas, like a dialect for polynomial arithmetic that is the core number crunching component of most FHE schemes.
In the mean time, I also want to encourage cryptographers, compiler engineers, and newcomers alike to participate. While we don’t yet have any “good first issues” to point to, there are quite a few active discussions going on, in-progress PRs we’re drafting, an open (video call) meeting every two weeks (see calendar), and past meeting notes to peruse.
Some members of the FHE community have also expressed to me that they’ve found MLIR to have too steep of a learning curve, and docs that are not low-level enough for a beginner. To help with that, I’ll be writing a series of “complete beginner” MLIR tutorials on this blog, with one pull request per article on this tutorial repository, in the style of my Searching for Riemann Hypothesis Counterexamples series. They’ll be slightly biased toward the HEIR project—using our chosen build system, bazel, rather than CMake, and focusing on out-of-tree development—but some MLIR beginners not involved in HEIR who read early drafts have told me they found it very useful. I’ll be publishing the first four articles this week and more periodically.