HEIR Can Run Code on Encrypted Inputs—but the Quickstart Is Not One Click

The shortest HEIR application path is to install the Python package and OpenFHE, mark integer inputs as secret, compile a function, then run setup, encryption, evaluation and decryption. This executes the function on ciphertexts, but the Python package does not eliminate the separate native backend.

A two-integer expression is enough to reproduce the complete path. HEIR compiles the annotated Python through BGV to OpenFHE-backed machine code and provides helpers that keep plaintext inputs, ciphertext evaluation and final decryption visibly separate.

What the example proves

HEIR is an open-source, MLIR-based compiler toolchain for homomorphic encryption. Homomorphic encryption allows a service to process ciphertexts and return an encrypted result without learning the underlying inputs; Google presents a one-click route to encrypted production inference as the project’s vision, not as the workflow documented below.

In this example, BGV is the homomorphic-encryption scheme used for exact integer operations. OpenFHE is the backend library that performs the generated cryptographic operations. HEIR connects the source function to that backend; it is not a hosted service or a self-contained cryptographic runtime.

Install the Python package and native backend

Create an isolated environment with python -m venv venv, activate it with source venv/bin/activate, then run pip install "heir_py[python,openfhe]". The official HEIR getting-started guide says this package includes the heir-opt and heir-translate binaries, but it also requires users to install OpenFHE directly.

That separate installation is necessary because the Python frontend invokes a C++ compiler and links HEIR-generated code against OpenFHE. The OpenFHE build and discovery details depend on the operating system and configuration, including options such as OpenMP. After installation, confirm that heir-opt --help and heir-translate --help run inside the environment, then verify that the native compiler can locate the OpenFHE headers and libraries.

Compile a secret-typed function

Create a Python file and import compile from heir, together with I64 and Secret from heir.mlir. Define the function as follows: decorate it with @compile(), accept x: Secret[I64] and y: Secret[I64], and return (x + y) * (x - y) + (x * y).

For this Python path, the undecorated configuration defaults to the BGV scheme, the OpenFHE backend and disabled debug output. The Secret[I64] annotations identify the inputs that cross the encrypted boundary. They do not make arbitrary Python code compatible: the frontend still has to support every operation and type used by the function.

Call func.setup() after defining the function. Setup prepares the cryptographic context and keys used by the generated helpers. If compilation or linking fails, switching temporarily to @compile(debug=True) prints the compilation commands and exposes the native build step that otherwise sits behind the decorator.

Encrypt, evaluate and decrypt

Keep the stages separate in the first run. Encrypt the inputs with enc_x = func.encrypt_x(7) and enc_y = func.encrypt_y(8). Evaluate them with result_enc = func.eval(enc_x, enc_y), then decrypt the returned ciphertext with result = func.decrypt_result(result_enc).

For these sample values, the expected result is 41: 15 multiplied by −1 gives −15, while 7 multiplied by 8 adds 56. Printing func.original(7, 8) beside the decrypted result should therefore produce 41 on both paths.

This comparison is a correctness check for one input pair, not a security audit or benchmark. It does not establish safe cryptographic parameters, acceptable multiplicative depth, production key custody, resistance to leakage, or suitable latency and memory use.

Where the quickstart stops

The HEIR repository lists three current routes: Bazel with rules_heir, Python with a separately installed OpenFHE backend, or a source build followed by manual integration of generated backend code. It also states that HEIR is not an officially supported Google product.

The surrounding tooling carries further limits. HEIR’s prebuilt nightly binaries are intended for testing compiler passes, not production use. The Python documentation says support for backends other than OpenFHE remains in progress, while standard C and C++ input support is described as experimental at best.

Before treating the example as the basis of a production pilot, require answers to these questions:

• Does the chosen scheme-and-backend combination support every operation and data type in the workload?
• Can HEIR, OpenFHE and the native compiler be reproduced from pinned versions instead of an unpinned nightly build?
• Have the cryptographic parameters and multiplicative depth been reviewed for the real computation?
• Are key generation, storage, rotation and the separation between data owner and evaluator defined?
• Have correctness, ciphertext size, latency and memory consumption been measured with representative inputs?
• Who owns upgrades and incident response despite the project’s support disclaimer?

The example establishes a narrow but useful result: a secret-typed Python function can be compiled, evaluated on encrypted inputs and decrypted through HEIR’s documented OpenFHE path. Moving it into production requires native build discipline, workload measurements and cryptographic review beyond the quickstart.

Also read:

• Google Product Listings Are Still Free—but Visibility Is Not Guaranteed
• Donate Attention, Not the Whole Page: A Safer Use for SEO Traffic
• Use Hashtags for Context, Not Reach: Instagram Now Caps Them at Five