1 of 70

2.7 Welcome

Concrete is an open-source FHE Compiler that simplifies the use of Fully Homomorphic Encryption (FHE).

Get started

Learn the basics of Concrete, set it up, and make it run with ease.

Build with Concrete

Start building with Concrete by exploring its core features, discovering essential guides, and learning more with step-by-step tutorials.

Explore more

Access to additional resources and join the Zama community.

Explanations

Refer to the API, review product architecture, and access additional resources for in-depth explanations while working with Concrete.

API
Frontend fusing
Compiler backend
Optimizer

Support channels

Ask technical questions and discuss with the community. Our team of experts usually answers within 24 hours in working days.

Developers

Collaborate with us to advance the FHE spaces and drive innovation together.

Zama 5-Question Developer Survey

We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. 👉 Click here to participate.

Get Started

What is Concrete?

Concrete is an open source framework that simplifies the use of Fully Homomorphic Encryption (FHE).

FHE is a powerful technology that enables computations on encrypted data without needing to decrypt it. This capability ensures user privacy and provides robust protection against data breaches, as operations are performed on encrypted data, keeping sensitive information secure even if the server is compromised.

The Concrete framework makes writing FHE programs easy for developers by incorporating a Fully Homomorphic Encryption over the Torus (TFHE) Compiler based on LLVM.

Concrete enables developers to efficiently develop privacy-preserving applications for various use cases. For instance, Concrete ML is built on top of Concrete to integrate privacy-preserving features of FHE into machine learning use cases.

Installation

This document explains the steps to install Concrete into your project.

Concrete is natively supported on Linux and macOS from Python 3.8 to 3.11 inclusive. If you have Docker in your platform, you can use the docker image to use Concrete.

Using PyPI

Install Concrete from PyPI using the following commands:

pip install -U pip wheel setuptools
pip install concrete-python

Not all versions are available on PyPI. If you need a version that is not on PyPI (including nightly releases), you can install it from our package index by adding --extra-index-url https://pypi.zama.ai/cpu/. GPU wheels are also available under https://pypi.zama.ai/gpu/ (check https://pypi.zama.ai/ for all available platforms).

To enable all the optional features, install the full version of Concrete:

pip install -U pip wheel setuptools
pip install concrete-python[full]

Not all versions are available on PyPI. If you need a version that is not on PyPI (including nightly releases), you can install it from our package index by adding --index-url https://pypi.zama.ai/cpu.

In particular, wheels with GPU support are not on PyPI. You can install it from our package index by adding --index-url https://pypi.zama.ai/gpu, more information on GPU wheels here.

The full version requires pygraphviz, which depends on graphviz. Make sure to install all the dependencies on your operating system before installing concrete-python[full].

Installing pygraphviz on macOS can be problematic (see more details here).

If you're using homebrew, you can try the following way:

brew install graphviz
CFLAGS=-I$(brew --prefix graphviz)/include LDFLAGS=-L$(brew --prefix graphviz)/lib pip --no-cache-dir install pygraphviz

before running:

pip install concrete-python[full]

Using Docker

You can also get the Concrete docker image. Replace v2.4.0 below by the version you want to install:

docker pull zamafhe/concrete-python:v2.4.0
docker run --rm -it zamafhe/concrete-python:latest /bin/bash

Docker is not supported on Apple Silicon.

Compatibility

Supported operations

This document lists the operations you can use inside the function that you are compiling.

Some operations are not supported between two encrypted values. If attempted, a detailed error message will be raised.

Supported Python operators.

Supported NumPy functions.

Supported `ndarray` methods.

Supported `ndarray` properties.

Limitations

Control flow constraints

Concrete doesn not support some control flow statements, including the if and while statement when the condition depends on an encrypted value. However, control flow statements with constant values are allowed, for example, for i in range(SOME_CONSTANT), if os.environ.get("SOME_FEATURE") == "ON":.

Type constraints

Floating-point inputs or floating-point outputs are not supported. You can have floating-point intermediate values as long as they can be converted to an integer Table Lookup, for example, (60 * np.sin(x)).astype(np.int64).

Bit width constraints

Bit width of encrypted values has a limit. We are constantly working on increasing the bit width limit. Exceeding this limit will trigger an error.

Terminology

This document provides clear definitions of key concepts used in Concrete framework.

Computation graph: A data structure to represent a computation. It takes the form of a directed acyclic graph where nodes represent inputs, constants, or operations.
Tracing: A method that takes a Python function provided by the user and generates a corresponding computation graph.
Bounds: The minimum and the maximum value that each node in the computation graph can take. Bounds are used to determine the appropriate data type (for example, uint3 or int5) for each node before the computation graphs are converted to MLIR. Concrete simulates the graph with the inputs in the inputset to record the minimum and the maximum value for each node.
Circuit: The result of compilation. A circuit includes both client and server components. It has methods for various operations, such as printing and evaluation.

Core features

Overview

Operations on encrypted values

The idea of homomorphic encryption is that you can compute on ciphertexts without knowing the messages they encrypt. A scheme is said to be , if an unlimited number of additions and multiplications are supported ( is a plaintext and is the corresponding ciphertext):

homomorphic addition:
homomorphic multiplication:

Noise and Bootstrap

FHE encrypts data as LWE ciphertexts. These ciphertexts can be visually represented as a bit vector with the encrypted message in the higher-order (yellow) bits as well as a random part (gray), that guarantees the security of the encrypted message, called noise.

Under the hood, each time you perform an operation on an encrypted value, the noise grows and at a certain point, it may overlap with the message and corrupt its value.

There is a way to decrease the noise of a ciphertext with the Bootstrap operation. The bootstrap operation takes as input a noisy ciphertext and generates a new ciphertext encrypting the same message, but with a lower noise. This allows additional operations to be performed on the encrypted message.

A typical FHE program will be made up of a series of operations followed by a Bootstrap, this is then repeated many times.

Probability of Error

The amount of noise in a ciphertext is not as bounded as it may appear in the above illustration. As the errors are drawn randomly from a Gaussian distribution, they can be of varying size. This means that we need to be careful to ensure the noise terms do not affect the message bits. If the error terms do overflow into the message bits, this can cause an incorrect output (failure) when bootstrapping.

The default failure probability in Concrete is set for the whole program and is by default. This means that 1 execution of every 100,000 may result in an incorrect output. To have a lower probability of error, you need to change the cryptographic parameters, likely resulting in worse performance. On the other side of this trade-off, allowing a higher probability of error will likely speed-up operations.

Function evaluation

So far, we only introduced arithmetic operations but a typical program usually also involves functions (maximum, minimum, square root…)

During the Bootstrap operation, in TFHE, you could perform a table lookup simultaneously to reduce noise, turning the Bootstrap operation into a Programmable Bootstrap (PBS).

Concrete uses the PBS to support function evaluation:

homomorphic univariate function evaluation:

Let's take a simple example. A function (or circuit) that takes a 4 bits input variable and output the maximum value between a clear constant and the encrypted input:

example:

could be turned into a table lookup:

The Lookup table lut being applied during the Programmable Bootstrap.

PBS management

You should not worry about PBS, they are completely managed by Concrete during the compilation process. Each function evaluation will be turned into a Lookup table and evaluated by a PBS.

See this in action with the previous example, if you dump the MLIR code produced by the frontend, you will see (forget about MLIR syntax, just see the Lookup table value on the 4th line):

The only thing you should keep in mind is that it adds a constraint on the input type, and that is the reason behind having a maximum bit-width supported in Concrete.

Second takeaway is that PBS are the most costly operations in FHE, the less PBS in your circuit the faster it will run. It is an interesting metrics to optimize (you will see that Concrete could give you the number of PBS used in your circuit).

Note also that PBS cost varies with the input variable precision (a circuit with 8 bit PBS will run faster than one with 16 bits PBS).

Development Workflow

Allowing computation on encrypted data is particularly interesting in the client/server model, especially when the client data are sensitive and the server not trusted. You could split the workflow in two main steps: development and deployment.

Development

During development, you will turn your program into its FHE equivalent. Concrete automates this task with the compilation process but you can make this process even easier by reducing the precision required, reducing the number of PBSs or allowing more parallelization in your code (e.g. working on bit chunks instead of high bit-width variables).

Once happy with the code, the development process is over and you will create the compiler artifact that will be used during deployment.

Deployment

A typical Concrete deployment will host on a server the compilation artifact: Client specifications required by the compiled circuits and the fhe executable itself. Client will ask for the circuit requirements, generate keys accordingly, then it will send an encrypted payload and receive an encrypted result.

For more information on deployment, see

Table lookups (basics)

Zama 5-Question Developer Survey

We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. 👉 Click here to participate.

In TFHE, there exists mainly two operations: the linear operations (additions, subtractions, multiplications by integers) and the rest. And the rest is done with table lookups (TLUs), which means that a lot of things are done with TLU. In this document, we explain briefly, from a user point of view, how TLU can be used. In the poweruser documentation, we enter a bit more into the details.

Performance

Before entering into the details on how we can use TLU in Concrete, let us mention the most important parameter for speed here: the smallest the bitwidth of a TLU is, the faster the corresponding FHE operation will be. Which means, in general, the user should try to reduce the size of the inputs to the tables. Also, we propose in the end of this document ways to truncate or round entries, which makes effective inputs smaller and so makes corresponding TLU faster.

Direct TLU

Direct TLU stands for instructions of the form y = T[i], for some table T and some index i. One can use the fhe.LookupTable to define the table values, and then use it on scalars or tensors.

from concrete import fhe

table = fhe.LookupTable([2, -1, 3, 0])

@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[x]

inputset = range(4)
circuit = f.compile(inputset)

assert circuit.encrypt_run_decrypt(0) == table[0] == 2
assert circuit.encrypt_run_decrypt(1) == table[1] == -1
assert circuit.encrypt_run_decrypt(2) == table[2] == 3
assert circuit.encrypt_run_decrypt(3) == table[3] == 0

from concrete import fhe
import numpy as np

table = fhe.LookupTable([2, -1, 3, 0])


@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[x]


inputset = [np.random.randint(0, 4, size=(2, 3)) for _ in range(10)]
circuit = f.compile(inputset)

sample = [
    [0, 1, 3],
    [2, 3, 1],
]
expected_output = [
    [2, -1, 0],
    [3, 0, -1],
]
actual_output = circuit.encrypt_run_decrypt(np.array(sample))

assert np.array_equal(actual_output, expected_output)

LookupTable mimics array indexing in Python, which means if the lookup variable is negative, the table is looked up from the back.

Multi TLU

Multi TLU stands for instructions of the form y = T[j][i], for some set of tables T, some table-index j and some index i. One can use the fhe.LookupTable to define the table values, and then use it on scalars or tensors.

from concrete import fhe
import numpy as np

squared = fhe.LookupTable([i ** 2 for i in range(4)])
cubed = fhe.LookupTable([i ** 3 for i in range(4)])

table = fhe.LookupTable([
    [squared, cubed],
    [squared, cubed],
    [squared, cubed],
])

@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[x]

inputset = [np.random.randint(0, 4, size=(3, 2)) for _ in range(10)]
circuit = f.compile(inputset)

sample = [
    [0, 1],
    [2, 3],
    [3, 0],
]
expected_output = [
    [0, 1],
    [4, 27],
    [9, 0]
]
actual_output = circuit.encrypt_run_decrypt(np.array(sample))

assert np.array_equal(actual_output, expected_output)

Transparent TLU

For lot of programs, users will not even need to define their table lookup, it will be done automatically by Concrete.

from concrete import fhe

@fhe.compiler({"x": "encrypted"})
def f(x):
    return x ** 2

inputset = range(4)
circuit = f.compile(inputset, show_mlir = True)

assert circuit.encrypt_run_decrypt(0) == 0
assert circuit.encrypt_run_decrypt(1) == 1
assert circuit.encrypt_run_decrypt(2) == 4
assert circuit.encrypt_run_decrypt(3) == 9

Remark that this kind of TLU is compatible with the TLU options, and in particular, with rounding and truncating which are explained below.

fhe.univariate and fhe.multivariate extensions are convenient ways to perform more complex operations as transparent TLUs.

TLU on the most significant bits

As we said in the beginning of this document, bitsize of the inputs of TLU are critical for the efficiency of the execution: the slower they are, the faster the TLU will be. Thus, we have proposed a few mechanisms to reduce this bitsize: the main one is rounding or truncating.

For lot of use-cases, like for example in Machine Learning, it is possible to replace the table lookup y = T[i] by some y = T'[i'], where i' only has the most significant bits of i and T' is a much shorter table, and still maintain a good accuracy of the function. The interest of such a method stands in the fact that, since the table T' is much smaller, the corresponding TLU will be done much more quickly.

There are different flavors of doing this in Concrete. We describe them quickly here, and refer the user to the poweruser documentation for more explanations.

The first possibility is to set i' as the truncation of i: here, we just take the most significant bits of i. This is done with fhe.truncate_bit_pattern.

from concrete import fhe
import numpy as np

table = fhe.LookupTable([i**2 for i in range(16)])
lsbs_to_remove = 1


@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[fhe.truncate_bit_pattern(x, lsbs_to_remove)]


inputset = range(16)
circuit = f.compile(inputset)

for i in range(16):
    rounded_i = int(i / 2**lsbs_to_remove) * 2**lsbs_to_remove

    assert circuit.encrypt_run_decrypt(i) == rounded_i**2

The second possibility is to set i' as the rounding of i: here, we take the most significant bits of i, and increment by 1 if ever the most significant ignored bit is a 1, to round. This is done with fhe.round_bit_pattern. It's however a bit more complicated, since rounding may make us go "out" of the original table. Remark how we enlarged the original table by 1 index.

from concrete import fhe
import numpy as np

table = fhe.LookupTable([i**2 for i in range(17)])
lsbs_to_remove = 1


def our_round(x):
    float_part = x - np.floor(x)
    if float_part < 0.5:
        return int(np.floor(x))
    return int(np.ceil(x))


@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[fhe.round_bit_pattern(x, lsbs_to_remove)]


inputset = range(16)
circuit = f.compile(inputset)

for i in range(16):
    rounded_i = our_round(i * 1.0 / 2**lsbs_to_remove) * 2**lsbs_to_remove

    assert (
        circuit.encrypt_run_decrypt(i) == rounded_i**2
    ), f"Miscomputation {i=} {circuit.encrypt_run_decrypt(i)} {rounded_i**2}"

Finally, for fhe.round_bit_pattern, there exist an exactness=fhe.Exactness.APPROXIMATE option, which can make computations even faster, at the price of having a few (minor) differences between cleartext computations and encrypted computations.

from concrete import fhe
import numpy as np

table = fhe.LookupTable([i**2 for i in range(17)])
lsbs_to_remove = 1


@fhe.compiler({"x": "encrypted"})
def f(x):
    return table[fhe.round_bit_pattern(x, lsbs_to_remove, exactness=fhe.Exactness.APPROXIMATE)]


inputset = range(16)
circuit = f.compile(inputset)

for i in range(16):
    lower_i = np.floor(i * 1.0 / 2**lsbs_to_remove) * 2**lsbs_to_remove
    upper_i = np.ceil(i * 1.0 / 2**lsbs_to_remove) * 2**lsbs_to_remove

    assert circuit.encrypt_run_decrypt(i) in [
        lower_i**2,
        upper_i**2,
    ], f"Miscomputation {i=} {circuit.encrypt_run_decrypt(i)} {[lower_i**2, upper_i**2]}"

Zama 5-Question Developer Survey

We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. 👉 Click here to participate.

Advanced features

Bit extraction

Some applications require directly manipulating bits of integers. Concrete provides a bit extraction operation for such applications.

Bit extraction is capable of extracting a slice of bits from an integer. Index 0 corresponds to the lowest significant bit. The cost of this operation is proportional to the highest significant bit index.

Bit extraction only works in the Native encoding, which is usually selected when all table lookups in the circuit are less than or equal to 8 bits.

Slices can be used for indexing fhe.bits(value) as well.

Even slices with negative steps are supported!

Signed integers are supported as well.

Lastly, here is a practical use case of bit extraction.

prints

Limitations

Bits cannot be extracted using a negative index.
- Which means fhe.bits(x)[-1] or fhe.bits(x)[-4:-1] is not supported for example.
- The reason for this is that we don't know in advance (i.e., before inputset evaluation) how many bits x has.
  - For example, let's say you have x == 10 == 0b_000...0001010, and you want to do fhe.bits(x)[-1]. If the value is 4-bits (i.e., 0b_1010), the result needs to be 1, but if it's 6-bits (i.e., 0b_001010), the result needs to be 0. Since we don't know the bit-width of x before inputset evaluation, we cannot calculate fhe.bits(x)[-1].
When extracting bits using slices in reverse order (i.e., step < 0), the start bit needs to be provided explicitly.
- Which means fhe.bits(x)[::-1] or fhe.bits(x)[:2:-1] is not supported for example.
- The reason is the same as above.
When extracting bits of signed values using slices, the stop bit needs to be provided explicitly.
- Which means fhe.bits(x)[1:] or fhe.bits(x)[1::2] is not supported for example.
- The reason is similar to above.
  - To explain a bit more, signed integers use representation. In this representation, negative values have their most significant bits set to 1 (e.g., -1 == 0b_11111, -2 == 0b_11110, -3 == 0b_11101). Extracting bits always returns a positive value (e.g., fhe.bits(-1)[1:3] == 0b_11 == 3) This means if you were to do fhe.bits(x)[1:] where x == -1, if x is 4 bits, the result would be 0b_111 == 7, but if x is 5 bits the result would be 0b_1111 == 15. Since we don't know the bit-width of x before inputset evaluation, we cannot calculate fhe.bits(x)[1:].
Bits of floats cannot be extracted.
- Floats are partially supported but extracting their bits is not supported at all.

Performance Considerations

A Chain of Individual Bit Extractions

Key Concept: Extracting a specific bit requires clearing all the preceding lower bits. This involves extracting these previous bits as intermediate values and then subtracting them from the input.

Implications:

Bits are extracted sequentially, starting from the least significant bit to the more significant ones. The cost is proportional to the index of the highest extracted bit plus one.
No parallelization is possible. The computation time is proportional to the cost, independent of the number of CPUs.

Examples:

Extracting fhe.bits(x)[4] is approximately five times costlier than extracting fhe.bits(x)[0].
Extracting fhe.bits(x)[4] takes around five times more wall clock time than fhe.bits(x)[0].
The cost of extracting fhe.bits(x)[0:5] is almost the same as that of fhe.bits(x)[5].

Reuse of Intermediate Extracted Bits

Key Concept: Common sub-expression elimination is applied to intermediate extracted bits.

Implications:

The overall cost for a series of fhe.bits(x)[m:n] calls on the same input x is almost equivalent to the cost of the single most computationally expensive extraction in the series, i.e. fhe.bits(x)[n].
The order of extraction in that series does not affect the overall cost.

Example:

The combined operation fhe.bit(x)[3] + fhe.bit(x)[2] + fhe.bit(x)[1] has almost the same cost as fhe.bits(x)[3].

TLUs of 1b input precision

Each extracted bit incurs a cost of approximately one TLU of 1-bit input precision. Therefore, fhe.bits(x)[0] is generally faster than any other TLU operation.

Compilation

Combining compiled functions

In various cases, deploying a server that contains many compatible functions is important. By compatible, we mean that the functions will be used together, with outputs of some of them being used as inputs of some other ones, without decryption in the middle. It also encompasses the use of recursive functions.

To support this feature in Concrete, we have two ways:

using the composable flag in the compilation, when there is a unique function. This option is described in
using the Concrete modules, when there are several functions, or when there is a unique function for which we want to more precisely detail how outputs are reused as further inputs. This functionality is described in

With composition

A simple way to say that a function f should be compiled such that its outputs can be reused as inputs is to use the composable configuration setting to True when compiling. Doing so, we can then easily compute f(f(x)) or f**i(x) = f(f(...(f(x) ..)) for a variable non-encrypted integer i, which is typically what happens for recursions.

from concrete import fhe

@fhe.compiler({"counter": "encrypted"})
def increment(counter):
   return (counter + 1) % 100

print("Compiling `increment` function")
increment_fhe = increment.compile(list(range(0, 100)), composable=True)

print("Generating keyset ...")
increment_fhe.keygen()

print("Encrypting the initial counter value")
counter = 0
counter_enc = increment_fhe.encrypt(counter)

print(f"| iteration || decrypted | cleartext |")
for i in range(10):
    counter_enc = increment_fhe.run(counter_enc)
    counter = increment(counter)

    # For demo purpose; no decryption is needed.
    counter_dec = increment_fhe.decrypt(counter_enc)
    print(f"|     {i}     || {counter_dec:<9} | {counter:<9} |")

Remark that this option is the equivalent of using the fhe.AllComposable policy of modules. In particular, the same limitations may occur (see limitations documentation section).

With modules

This document explains how to compile Fully Homomorphic Encryption (FHE) modules containing multiple functions using Concrete.

Deploying a server that contains many compatible functions is important for some use cases. With Concrete, you can compile FHE modules containing as many functions as needed.

These modules support the composition of different functions, meaning that the encrypted result of one function can be used as the input for another function without needing to decrypt it first. Additionally, a module is deployed in a single artifact, making it as simple to use as a single-function project.

Single inputs / outputs

The following example demonstrates how to create an FHE module:

from concrete import fhe

@fhe.module()
class Counter:
    @fhe.function({"x": "encrypted"})
    def inc(x):
        return x + 1 % 20

    @fhe.function({"x": "encrypted"})
    def dec(x):
        return x - 1 % 20

Then, you can compile the FHE module Counter using the compile method. To do that, you need to provide a dictionary of input-sets for every function:

inputset = list(range(20))
CounterFhe = CounterFhe.compile({"inc": inputset, "dec": inputset})

After the module is compiled, you can encrypt and call the different functions as follows:

x = 5
x_enc = CounterFhe.inc.encrypt(x)
x_inc_enc = CounterFhe.inc.run(x_enc)
x_inc = CounterFhe.inc.decrypt(x_inc_enc)
assert x_inc == 6

x_inc_dec_enc = CounterFhe.dec.run(x_inc_enc)
x_inc_dec = CounterFhe.dec.decrypt(x_inc_dec_enc)
assert x_inc_dec == 5

for _ in range(10):
    x_enc = CounterFhe.inc.run(x_enc)
x_dec = CounterFhe.inc.decrypt(x_enc)
assert x_dec == 15

Multi inputs / outputs

Composition is not limited to single input / single output. Here is an example that computes the 10 first elements of the Fibonacci sequence in FHE:

from concrete import fhe

def noise_reset(x):
   return fhe.univariate(lambda x: x)(x)

@fhe.module()
class Fibonacci:

    @fhe.function({"n1th": "encrypted", "nth": "encrypted"})
    def fib(n1th, nth):
       return noise_reset(nth), noise_reset(n1th + nth)

print("Compiling `Fibonacci` module ...")
inputset = list(zip(range(0, 100), range(0, 100)))
FibonacciFhe = Fibonacci.compile({"fib": inputset})

print("Generating keyset ...")
FibonacciFhe.keygen()

print("Encrypting initial values")
n1th = 1
nth = 2
(n1th_enc, nth_enc) = FibonacciFhe.fib.encrypt(n1th, nth)

print(f"|           ||        (n-1)-th       |         n-th          |")
print(f"| iteration || decrypted | cleartext | decrypted | cleartext |")
for i in range(10):
   (n1th_enc, nth_enc) = FibonacciFhe.fib.run(n1th_enc, nth_enc)
   (n1th, nth) = Fibonacci.fib(n1th, nth)

    # For demo purpose; no decryption is needed.
   (n1th_dec, nth_dec) = FibonacciFhe.fib.decrypt(n1th_enc, nth_enc)
   print(f"|     {i}     || {n1th_dec:<9} | {n1th:<9} | {nth_dec:<9} | {nth:<9} |")

Executing this script will provide the following output:

Compiling `Fibonacci` module ...
Generating keyset ...
Encrypting initial values
|           ||        (n-1)-th       |         n-th          |
| iteration || decrypted | cleartext | decrypted | cleartext |
|     0     || 2         | 2         | 3         | 3         |
|     1     || 3         | 3         | 5         | 5         |
|     2     || 5         | 5         | 8         | 8         |
|     3     || 8         | 8         | 13        | 13        |
|     4     || 13        | 13        | 21        | 21        |
|     5     || 21        | 21        | 34        | 34        |
|     6     || 34        | 34        | 55        | 55        |
|     7     || 55        | 55        | 89        | 89        |
|     8     || 89        | 89        | 144       | 144       |
|     9     || 144       | 144       | 233       | 233       |

Iterations

With the previous example, we see that modules allow iteration with cleartext iterands to some extent. Specifically, loops with the following structure are supported:

for i in some_cleartext_constant_range:
    # Do something in FHE in the loop body, implemented as an FHE function.

With this pattern, we can also support unbounded loops or complex dynamic condition, as long as this condition is computed in pure cleartext python. Here is an example that computes the Collatz sequence:

from concrete import fhe

@fhe.module()
class Collatz:

    @fhe.function({"x": "encrypted"})
    def collatz(x):

        y = x // 2
        z = 3 * x + 1

        is_x_odd = fhe.bits(x)[0]

        # In a fast way, compute ans = is_x_odd * (z - y) + y
        ans = fhe.multivariate(lambda b, x: b * x)(is_x_odd, z - y) + y

        is_one = ans == 1

        return ans, is_one


print("Compiling `Collatz` module ...")
inputset = [i for i in range(63)]
CollatzFhe = collatz.compile({"collatz": inputset})

print("Generating keyset ...")
CollatzFhe.keygen()

print("Encrypting initial value")
x = 19
x_enc = CollatzFhe.collatz.encrypt(x)
is_one_enc = None

print(f"| decrypted | cleartext |")
while is_one_enc is None or not CollatzFhe.collatz.decrypt(is_one_enc):
    x_enc, is_one_enc = CollatzFhe.collatz.run(x_enc)
    x, is_one = Collatz.collatz(x)

    # For demo purpose; no decryption is needed.
    x_dec = CollatzFhe.collatz.decrypt(x_enc)
    print(f"| {x_dec:<9} | {x:<9} |")

This script prints the following output:

Compiling `Collatz` module ...
Generating keyset ...
Encrypting initial value
| decrypted | cleartext |
| 58        | 58        |
| 29        | 29        |
| 88        | 88        |
| 44        | 44        |
| 22        | 22        |
| 11        | 11        |
| 34        | 34        |
| 17        | 17        |
| 52        | 52        |
| 26        | 26        |
| 13        | 13        |
| 40        | 40        |
| 20        | 20        |
| 10        | 10        |
| 5         | 5         |
| 16        | 16        |
| 8         | 8         |
| 4         | 4         |
| 2         | 2         |
| 1         | 1         |

In this example, a while loop iterates until the decrypted value equals 1. The loop body is implemented in FHE, but the iteration control must be in cleartext.

Runtime optimization

By default, when using modules, all inputs and outputs of every function are compatible, sharing the same precision and crypto-parameters. This approach applies the crypto-parameters of the most costly code path to all code paths. This simplicity may be costly and unnecessary for some use cases.

To optimize runtime, we provide finer-grained control over the composition policy via the composition module attribute. Here is an example:

from concrete import fhe

@fhe.module()
class Collatz:

    @fhe.function({"x": "encrypted"})
    def collatz(x):
        y = x // 2
        z = 3 * x + 1
        is_x_odd = fhe.bits(x)[0]
        ans = fhe.multivariate(lambda b, x: b * x)(is_x_odd, z - y) + y
        is_one = ans == 1
        return ans, is_one

    composition = fhe.AllComposable()

You have 3 options for the composition attribute:

fhe.AllComposable (default): This policy ensures that all ciphertexts used in the module are compatible. It is the least restrictive policy but the most costly in terms of performance.
fhe.NotComposable: This policy is the most restrictive but the least costly. It is suitable when you do not need any composition and only want to pack multiple functions in a single artifact.
fhe.Wired: This policy allows you to define custom composition rules. You can specify which outputs of a function can be forwarded to which inputs of another function.
Here is an example:

from concrete import fhe
from fhe import Wired, Wire, Output, Input

@fhe.module()
class Collatz:

    @fhe.function({"x": "encrypted"})
    def collatz(x):
        y = x // 2
        z = 3 * x + 1
        is_x_odd = fhe.bits(x)[0]
        ans = fhe.multivariate(lambda b, x: b * x)(is_x_odd, z - y) + y
        is_one = ans == 1
        return ans, is_one

    composition = Wired(
        [
            Wire(Output(collatz, 0), Input(collatz, 0)
        ]
    )

In this case, the policy states that the first output of the collatz function can be forwarded to the first input of collatz, but not the second output (which is decrypted every time, and used for control flow).

You can use the fhe.Wire between any two functions. It is also possible to define wires with fhe.AllInputs and fhe.AllOutputs ends. For instance, in the previous example:

    composition = Wired(
        [
            Wire(AllOutputs(collatz), AllInputs(collatz))
        ]
    )

This policy would be equivalent to using the fhe.AllComposable policy.

Current limitations

Depending on the functions, composition may add a significant overhead compared to a non-composable version.

To be composable, a function must meet the following condition: every output that can be forwarded as input (according to the composition policy) must contain a noise-refreshing operation. Since adding a noise refresh has a noticeable impact on performance, Concrete does not automatically include it.

For instance, to implement a function that doubles an encrypted value, you might write:

@fhe.module()
class Doubler:
    @fhe.compiler({"counter": "encrypted"})
    def double(counter):
       return counter * 2

This function is valid with the fhe.NotComposable policy. However, if compiled with the fhe.AllComposable policy, it will raise a RuntimeError: Program cannot be composed: ..., indicating that an extra Programmable Bootstrapping (PBS) step must be added.

To resolve this and make the circuit valid, add a PBS at the end of the circuit:

def noise_reset(x):
   return fhe.univariate(lambda x: x)(x)

@fhe.module()
class Doubler:
    @fhe.compiler({"counter": "encrypted"})
    def double(counter):
       return noise_reset(counter * 2)

Key-related options for faster execution

Multi parameters

Integers in Concrete are encrypted and processed according to a set of cryptographic parameters. By default, multiple sets of such parameters are selected by the Concrete Optimizer. This might not be the best approach for every use case, and there is the option to use mono parameters instead.

When multi parameters are enabled, a different set of parameters are selected for each bit-width in the circuit, which results in:

Faster execution (generally).
Slower key generation.
Larger keys.
Larger memory usage during execution.

To disable it, you can use parameter_selection_strategy=fhe.ParameterSelectionStrategy.MONO configuration option.

When enabled, you can select the level of circuit partitioning, with multi_parameter_strategy in configuration.

Compression

Fully Homomorphic Encryption (FHE) needs both ciphertexts (encrypted data) and evaluation keys to carry out the homomorphic evaluation of a function. Both elements are large, which may critically affect the application's performance depending on the use case, application deployment, and the method for transmitting and storing ciphertexts and evaluation keys.

During compilation, you can enable compression options to enforce the use of compression features. The two available compression options are:

compress_evaluation_keys: bool = False,
- This specifies that serialization takes the compressed form of evaluation keys.
compress_input_ciphertexts: bool = False,
- This specifies that serialization takes the compressed form of input ciphertexts.

You can see the impact of compression by comparing the size of the serialized form of input ciphertexts and evaluation keys with a sample code.

The compression factor largely depends on the cryptographic parameters identified and the compression algorithms selected during the compilation.

Currently, Concrete uses the seeded compression algorithms. These algorithms rely on the fact that CSPRNGs are deterministic. Consequently, the chain of random values can be replaced by the seed and later recalculated using the same seed.

Typically, the size of a ciphertext is (lwe dimension + 1) * 8 bytes, while the size of a seeded ciphertext is constant, equal to 3 * 8 bytes. Thus, the compression factor ranges from a hundred to thousands. Understanding the compression factor of evaluation keys is complex. The compression factor of evaluation keys typically ranges between 0 and 10.

Please note that while compression may save bandwidth and disk space, it incurs the cost of decompression. Currently, decompression occur more or less lazily during FHE evaluation without any control.

Reusing arguments

Encryption can take quite some time, memory, and network bandwidth if encrypted data is to be transported. Some applications use the same argument, or a set of arguments as one of the inputs. In such applications, it doesn't make sense to encrypt and transfer the arguments each time. Instead, arguments can be encrypted separately, and reused:

If you have multiple arguments, the encrypt method would return a tuple, and if you specify None as one of the arguments, None is placed at the same location in the resulting tuple (e.g., circuit.encrypt(a, None, b, c, None) would return (encrypted_a, None, encrypted_b, encrypted_c, None)). Each value returned by encrypt can be stored and reused anytime.

The ordering of the arguments must be kept consistent! Encrypting an x and using it as a y could result in undefined behavior.

Common errors

This document explains the most common errors and provides solutions to fix them.

1. Could not find a version that satisfies the requirement concrete-python (from versions: none)

Error message: Could not find a version that satisfies the requirement concrete-python (from versions: none)

Cause: The installation does not work fine for you.

Possible solutions:

Be sure that you use a supported Python version (currently from 3.8 to 3.11, included).
Check that you have done pip install -U pip wheel setuptools before.
Consider adding a --extra-index-url https://pypi.zama.ai/cpu/.
Concrete requires glibc>=2.28, be sure to have a sufficiently recent version.

2. Only integers are supported

Error message: RuntimeError: Function you are trying to compile cannot be compiled with extra information only integers are supported

Cause: Parts of your program contain graphs that are not from integer to integer

Possible solutions:

You can use floats as intermediate values (see the documentation). However, both inputs and outputs must be integers. Consider converting values to integers, such as .astype(np.uint64)

3. No parameters found

Error message: NoParametersFound

Cause: The optimizer can't find cryptographic parameters for the circuit that are both secure and correct.

Possible solutions:

Try to simplify your circuit.
Use smaller weights.
Add intermediate PBS to reduce the noise, with identity function fhe.univariate(lambda x: x).

4. Too long inputs for table looup

Error message: RuntimeError: Function you are trying to compile cannot be compiled, with extra information as this [...]-bit value is used as an input to a table lookup with but only up to 16-bit table lookups are supported

Cause: The program uses a Table Lookup that contains oversized inputs exceeding the current 16-bit limit.

Possible solutions:

Try to simplify your circuit.
Use smaller weights.
Look to the graph to understand where this oversized input comes from and ensure that the input size for Table Lookup operations does not exceed 16 bits.
Use show_bit_width_constraints=True to understand bit widths are assigned the way they are.

5. Impossible to fuse multiple-nodes

Error message: RuntimeError: A subgraph within the function you are trying to compile cannot be fused because it has multiple input nodes

Cause: A subgraph in your program uses two or more input nodes. It is impossible to fuse such a graph, meaning replace it by a table lookup. Concrete will indicate the input nodes with this is one of the input nodes printed in the circuit.

Possible solutions:

Try to simplify your circuit.
Have a look to fhe.multivariate.

6. Function is not supported

Error message: RuntimeError: Function '[...]' is not supported

Cause: The function used is not currently supported by Concrete.

Possible solutions:

Try to change your program.
Check the corresponding documentation to see if there are ways to implement the function differently.
Post your issue in our community channels.

7. Branching is not allowed

Error message: RuntimeError: Branching within circuits is not possible

Cause: Branching operations, such as if statements or non-constant loops, are not supported in Concrete's FHE programs.

Possible solutions:

Change your program.
Consider using tricks to replace ternary-if, as c ? t : f = f + c * (t-f).

Execution / Analysis

Simulation

During development, the speed of homomorphic execution can be a blocker for fast prototyping. You could call the function you're trying to compile directly, of course, but it won't be exactly the same as FHE execution, which has a certain probability of error (see Exactness).

To overcome this issue, simulation is introduced:

from concrete import fhe
import numpy as np

@fhe.compiler({"x": "encrypted"})
def f(x):
    return (x + 1) ** 2

inputset = [np.random.randint(0, 10, size=(10,)) for _ in range(10)]
circuit = f.compile(inputset, p_error=0.1, fhe_simulation=True)

sample = np.array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

actual = f(sample)
simulation = circuit.simulate(sample)

print(actual.tolist())
print(simulation.tolist())

After the simulation runs, it prints the following:

[1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
[1, 4, 9, 16, 16, 36, 49, 64, 81, 100]

There are some operations which are not supported in simulation yet. They will result in compilation failures. You can revert to simulation using graph execution using circuit.graph(...) instead of circuit.simulate(...), which won't simulate FHE, but it will evaluate the computation graph, which is like simulating the operations without any errors due to FHE.

Overflow Detection in Simulation

Overflow can happen during an FHE computation, leading to unexpected behaviors. Using simulation can help you detect these events by printing a warning whenever an overflow happens. This feature is disabled by default, but you can enable it by setting detect_overflow_in_simulation=True during compilation.

To demonstrate, we will compile the previous circuit with overflow detection enabled and trigger an overflow:

# compile with overflow detection enabled
circuit = f.compile(inputset, p_error=0.1, fhe_simulation=True, detect_overflow_in_simulation=True)
# cause an overflow
circuit.simulate([0,1,2,3,4,5,6,7,8,15])

You will see the following warning after the simulation call:

WARNING at loc("script.py":3:0): overflow happened during addition in simulation

If you look at the MLIR (circuit.mlir), you will see that the input type is supposed to be eint4 represented in 4 bits with a maximum value of 15. Since there's an addition of the input, we used the maximum value (15) here to trigger an overflow (15 + 1 = 16 which needs 5 bits). The warning specifies the operation that caused the overflow and its location. Similar warnings will be displayed for all basic FHE operations such as add, mul, and lookup tables.

Debugging and artifact

In this section, you will learn how to debug the compilation process easily and find help in the case that you cannot resolve your issue.

Compiler debug and verbose modes

There are two options that you can use to understand what's happening under the hood during the compilation process.

compiler_verbose_mode will print the passes applied by the compiler and let you see the transformations done by the compiler. Also, in the case of a crash, it could narrow down the crash location.
compiler_debug_mode is a lot more detailed version of the verbose mode. This is even better for crashes.

These flags might not work as expected in Jupyter notebooks as they output to stderr directly from C++.

Debug artifacts

Concrete has an artifact system to simplify the process of debugging issues.

Automatic export.

In case of compilation failures, artifacts are exported automatically to the .artifacts directory under the working directory. Let's intentionally create a compilation failure to show what is exported.

This function fails to compile because Concrete does not support floating-point outputs. When you try to compile it, an exception will be raised and the artifacts will be exported automatically. If you go to the .artifacts directory under the working directory, you'll see the following files:

environment.txt

This file contains information about your setup (i.e., your operating system and python version).

requirements.txt

This file contains information about Python packages and their versions installed on your system.

function.txt

This file contains information about the function you tried to compile.

parameters.txt

This file contains information about the encryption status of the parameters of the function you tried to compile.

1.initial.graph.txt

This file contains the textual representation of the initial computation graph right after tracing.

2.final.graph.txt

This file contains the textual representation of the final computation graph right before MLIR conversion.

traceback.txt

This file contains information about the error that was received.

Manual exports.

Manual exports are mostly used for visualization. They can be very useful for demonstrations. Here is how to perform one:

If you go to the /tmp/custom/export/path directory, you'll see the following files:

1.initial.graph.txt

This file contains the textual representation of the initial computation graph right after tracing.

2.after-fusing.graph.txt

This file contains the textual representation of the intermediate computation graph after fusing.

3.final.graph.txt

This file contains the textual representation of the final computation graph right before MLIR conversion.

mlir.txt

This file contains information about the MLIR of the function which was compiled using the provided inputset.

client_parameters.json

This file contains information about the client parameters chosen by Concrete.

Asking the community

You can seek help with your issue by asking a question directly in the .

Submitting an issue

If you cannot find a solution in the community forum, or if you have found a bug in the library, you could create an issue in our GitHub repository.

In case of a bug, try to:

minimize randomness;
minimize your function as much as possible while keeping the bug - this will help to fix the bug faster;
include your inputset in the issue;
include reproduction steps in the issue;
include debug artifacts in the issue.

In case of a feature request, try to:

give a minimal example of the desired behavior;
explain your use case.

Other

Statistics

Concrete analyzes all compiled circuits and calculates some statistics. These statistics can be used to find bottlenecks and compare circuits. Statistics are calculated in terms of basic operations. There are 6 basic operations in Concrete:

clear addition: x + y where x is encrypted and y is clear
encrypted addition: x + y where both x and y are encrypted
clear multiplication: x * y where x is encrypted and y is clear
encrypted negation: -x where x is encrypted
key switch: building block for table lookups
packing key switch: building block for table lookups
programmable bootstrapping: building block for table lookups

You can print all statistics using the show_statistics configuration option:

This code will print:

Each of these properties can be directly accessed on the circuit (e.g., circuit.programmable_bootstrap_count).

Progressbar

Big circuits can take a long time to execute, and waiting for execution to finish without having any indication of its progress can be frustrating. For this reason, progressbar feature is introduced:

import time

import matplotlib.pyplot as plt
import numpy as np
import randimage
from concrete import fhe

configuration = fhe.Configuration(
    enable_unsafe_features=True,
    use_insecure_key_cache=True,
    insecure_key_cache_location=".keys",

    # To enable displaying progressbar
    show_progress=True,
    # To enable showing tags in the progressbar (does not work in notebooks)
    progress_tag=True,
    # To give a title to the progressbar
    progress_title="Evaluation:",
)

@fhe.compiler({"image": "encrypted"})
def to_grayscale(image):
    with fhe.tag("scaling.r"):
        r = image[:, :, 0]
        r = (r * 0.30).astype(np.int64)

    with fhe.tag("scaling.g"):
        g = image[:, :, 1]
        g = (g * 0.59).astype(np.int64)

    with fhe.tag("scaling.b"):
        b = image[:, :, 2]
        b = (b * 0.11).astype(np.int64)

    with fhe.tag("combining.rgb"):
        gray = r + g + b
        
    with fhe.tag("creating.result"):
        gray = np.expand_dims(gray, axis=2)
        result = np.concatenate((gray, gray, gray), axis=2)
    
    return result

image_size = (16, 16)
image_data = (randimage.get_random_image(image_size) * 255).round().astype(np.int64)

print()

print(f"Compilation started @ {time.strftime('%H:%M:%S', time.localtime())}")
start = time.time()
inputset = [np.random.randint(0, 256, size=image_data.shape) for _ in range(100)]
circuit = to_grayscale.compile(inputset, configuration)
end = time.time()
print(f"(took {end - start:.3f} seconds)")

print()

print(f"Key generation started @ {time.strftime('%H:%M:%S', time.localtime())}")
start = time.time()
circuit.keygen()
end = time.time()
print(f"(took {end - start:.3f} seconds)")

print()

print(f"Evaluation started @ {time.strftime('%H:%M:%S', time.localtime())}")
start = time.time()
grayscale_image_data = circuit.encrypt_run_decrypt(image_data)
end = time.time()
print(f"(took {end - start:.3f} seconds)")

fig, axs = plt.subplots(1, 2)
axs = axs.flatten()

axs[0].set_title("Original")
axs[0].imshow(image_data)
axs[0].axis("off")

axs[1].set_title("Grayscale")
axs[1].imshow(grayscale_image_data)
axs[1].axis("off")

plt.show()

When you run this code, you will see a progressbar like:

Evaluation:  10% |█████.............................................|  10% (scaling.r)
^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^
Title        Progressbar                                                   Tag

And as the circuit progresses, this progressbar would fill:

Evaluation:  30% |███████████████...................................|  30% (scaling.g)

Evaluation:  50% |█████████████████████████.........................|  50% (scaling.b)

It is not a uniform progressbar. For example, when the progressbar shows 50%, this does not mean that half of the execution is performed in terms of seconds. Instead, it means that half of the nodes in the graph have been calculated. Since different node types can take a different amount of time, this should not be used to get an ETA.

Once the progressbar fills and execution completes, you will see the following figure:

Guides

Configure

Concrete can be customized using Configurations:

You can overwrite individual options as kwargs to the compile method:

Or you can combine both:

Additional kwargs to compile functions take higher precedence. So if you set the option in both configuration and compile methods, the value in the compile method will be used.

Options

show_graph: Optional[bool] = None
- Print computation graph during compilation. True means always print, False means never print, None means print depending on verbose configuration below.
show_mlir: Optional[bool] = None
- Print MLIR during compilation. True means always print, False means never print, None means print depending on verbose configuration below.
show_optimizer: Optional[bool] = None
- Print optimizer output during compilation. True means always print, False means never print, None means print depending on verbose configuration below.
show_statistics: Optional[bool] = None
- Print circuit statistics during compilation. True means always print, False means never print, None means print depending on verbose configuration below.
verbose: bool = False
- Print details related to compilation.
dump_artifacts_on_unexpected_failures: bool = True
- Export debugging artifacts automatically on compilation failures.
auto_adjust_rounders: bool = False
- Adjust rounders automatically.
p_error: Optional[float] = None
- Error probability for individual table lookups. If set, all table lookups will have the probability of a non-exact result smaller than the set value. See to learn more.
global_p_error: Optional[float] = None
- Global error probability for the whole circuit. If set, the whole circuit will have the probability of a non-exact result smaller than the set value. See to learn more.
single_precision: bool = False
- Use single precision for the whole circuit.
parameter_selection_strategy: (fhe.ParameterSelectionStrategy) = fhe.ParameterSelectionStrategy.MULTI
- Set how cryptographic parameters are selected.
multi_parameter_strategy: fhe.MultiParameterStrategy = fhe.MultiParameterStrategy.PRECISION
- Set the level of circuit partionning when using fhe.ParameterSelectionStrategy.MULTI.
- PRECISION: all TLU with same input precision have their own parameters.
- PRECISION_AND_NORM2: all TLU with same input precision and output have their own parameters.
loop_parallelize: bool = True
- Enable loop parallelization in the compiler.
dataflow_parallelize: bool = False
- Enable dataflow parallelization in the compiler.
auto_parallelize: bool = False
- Enable auto parallelization in the compiler.
use_gpu: bool = False
- Enable generating code for GPU in the compiler.
enable_unsafe_features: bool = False
- Enable unsafe features.
use_insecure_key_cache: bool = False (Unsafe)
- Use the insecure key cache.
insecure_key_cache_location: Optional[Union[Path, str]] = None
- Location of insecure key cache.
show_progress: bool = False,
- Display a progress bar during circuit execution
progress_title: str = "",
- Title of the progress bar
progress_tag: Union[bool, int] = False,
- How many nested tag elements to display with the progress bar. True means all tag elements and False disables the display. 2 will display elmt1.elmt2
fhe_simulation: bool = False
- Enable FHE simulation. Can be enabled later using circuit.enable_fhe_simulation().
fhe_execution: bool = True
- Enable FHE execution. Can be enabled later using circuit.enable_fhe_execution().
compiler_debug_mode: bool = False,
- Enable/disable debug mode of the compiler. This can show a lot of information, including passes and pattern rewrites.
compiler_verbose_mode: bool = False,
- Enable/disable verbose mode of the compiler. This mainly shows logs from the compiler, and is less verbose than the debug mode.
comparison_strategy_preference: Optional[Union[ComparisonStrategy, str, List[Union[ComparisonStrategy, str]]]] = None
- Specify preference for comparison strategies, can be a single strategy or an ordered list of strategies. See to learn more.
bitwise_strategy_preference: Optional[Union[BitwiseStrategy, str, List[Union[BitwiseStrategy, str]]]] = None
- Specify preference for bitwise strategies, can be a single strategy or an ordered list of strategies. See to learn more.
shifts_with_promotion: bool = True,
- Enable promotions in encrypted shifts instead of casting in runtime. See to learn more.
composable: bool = False,
- Specify that the function must be composable with itself. Only used when compiling a single circuit; when compiling modules use the .
relu_on_bits_threshold: int = 7,
- Bit-width to start implementing the ReLU extension with .
relu_on_bits_chunk_size: int = 3,
- Chunk size of the ReLU extension when implementation is used.
if_then_else_chunk_size: int = 3
- Chunk size to use when converting fhe.if_then_else extension.
rounding_exactness : Exactness = fhe.Exactness.EXACT
- Set default exactness mode for the rounding operation:
- EXACT: threshold for rounding up or down is exactly centered between upper and lower value,
- APPROXIMATE: faster but threshold for rounding up or down is approximately centered with pseudo-random shift.
- Precise and more complete behavior is described in .
approximate_rounding_config : ApproximateRoundingConfig = fhe.ApproximateRoundingConfig():
- Provide more fine control on :
- to enable exact cliping,
- or/and approximate clipping which make overflow protection faster.
optimize_tlu_based_on_measured_bounds : bool = False
- Enables TLU optimizations based on measured bounds.
- Not enabled by default as it could result in unexpected overflows during runtime.
enable_tlu_fusing : bool = True
- Enables TLU fusing to reduce the number of table lookups.
print_tlu_fusing : bool = False
- Enables printing TLU fusing to see which table lookups are fused.
compress_evaluation_keys: bool = False,
- This specifies that serialization takes the compressed form of evaluation keys.
compress_input_ciphertexts: bool = False,
- This specifies that serialization takes the compressed form of input ciphertexts.
optimize_tlu_based_on_original_bit_width: Union[bool, int] = 8,
- Configures whether to convert values to their original precision before doing a table lookup on them.
- True enables it for all cases.
- False disables it for all cases.
- Integer value enables or disables it depending on the original bit width.
- With the default value of 8, only the values with original bit width <= 8 will be converted to their original precision.
simulate_encrypt_run_decrypt: bool = False
- Whether to use simulate encrypt/run/decrypt methods of the circuit/module instead of doing the actual encryption/evaluation/decryption.
  - When this option is set to True, encrypt and decrypt are identity functions, and run is a wrapper around simulation. In other words, this option allows to switch off the encryption to quickly test if a function has expected semantic (without paying the price of FHE execution).
- This is extremely unsafe and should only be used during development.
- For this reason, it requires enable_unsafe_features to be set to True.

Manage keys

Concrete generates keys for you implicitly when they are needed and if they have not already been generated. This is useful for development, but it's not flexible (or secure!) for production. Explicit key management API is introduced to be used in such cases to easily generate and re-use keys.

Definition

Let's start by defining a circuit:

from concrete import fhe

@fhe.compiler({"x": "encrypted"})
def f(x):
    return x ** 2

inputset = range(10)
circuit = f.compile(inputset)

Circuits have a property called keys of type fhe.Keys, which has several utility functions dedicated to key management!

Generation

To explicitly generate keys for a circuit, you can use:

circuit.keys.generate()

Generated keys are stored in memory upon generation, unencrypted.

And it's possible to set a custom seed for reproducibility:

circuit.keys.generate(seed=420)

Do not specify the seed manually in a production environment!

Serialization

To serialize keys, say to send it across the network:

serialized_keys: bytes = circuit.keys.serialize()

Keys are not serialized in encrypted form! Please make sure you keep them in a safe environment, or encrypt them manually after serialization.

Deserialization

To deserialize the keys back, after receiving serialized keys:

keys: fhe.Keys = fhe.Keys.deserialize(serialized_keys)

Assignment

Once you have a valid fhe.Keys object, you can directly assign it to the circuit:

circuit.keys = keys

If assigned keys are generated for a different circuit, an exception will be raised.

Saving

You can also use the filesystem to store the keys directly, without needing to deal with serialization and file management yourself:

circuit.keys.save("/path/to/keys")

Keys are not saved encrypted! Please make sure you store them in a safe environment, or encrypt them manually after saving.

Loading

After keys are saved to disk, you can load them back via:

circuit.keys.load("/path/to/keys")

Automatic Management

If you want to generate keys in the first run and reuse the keys in consecutive runs:

circuit.keys.load_if_exists_generate_and_save_otherwise("/path/to/keys")

Deploy

After developing your circuit, you may want to deploy it. However, sharing the details of your circuit with every client might not be desirable. As well as this, you might want to perform the computation on dedicated servers. In this case, you can use the Client and Server features of Concrete.

Development of the circuit

You can develop your circuit using the techniques discussed in previous chapters. Here is a simple example:

from concrete import fhe

@fhe.compiler({"x": "encrypted"})
def function(x):
    return x + 42

inputset = range(10)
circuit = function.compile(inputset)

Once you have your circuit, you can save everything the server needs:

circuit.server.save("server.zip")

Then, send server.zip to your computation server.

Setting up a server

You can load the server.zip you get from the development machine:

from concrete import fhe

server = fhe.Server.load("server.zip")

You will need to wait for requests from clients. The first likely request is for ClientSpecs.

Clients need ClientSpecs to generate keys and request computation. You can serialize ClientSpecs:

serialized_client_specs: str = server.client_specs.serialize()

Then, you can send it to the clients requesting it.

Setting up clients

After getting the serialized ClientSpecs from a server, you can create the client object:

client_specs = fhe.ClientSpecs.deserialize(serialized_client_specs)
client = fhe.Client(client_specs)

Generating keys (on the client)

Once you have the Client object, you can perform key generation:

client.keys.generate()

This method generates encryption/decryption keys and evaluation keys.

The server needs access to the evaluation keys that were just generated. You can serialize your evaluation keys as shown:

serialized_evaluation_keys: bytes = client.evaluation_keys.serialize()

After serialization, send the evaluation keys to the server.

Serialized evaluation keys are very large, so you may want to cache them on the server instead of sending them with each request.

Encrypting inputs (on the client)

The next step is to encrypt your inputs and request the server to perform some computation. This can be done in the following way:

arg: fhe.Value = client.encrypt(7)
serialized_arg: bytes = arg.serialize()

Then, send the serialized arguments to the server.

Performing computation (on the server)

Once you have serialized evaluation keys and serialized arguments, you can deserialize them:

deserialized_evaluation_keys = fhe.EvaluationKeys.deserialize(serialized_evaluation_keys)
deserialized_arg = fhe.Value.deserialize(serialized_arg)

You can perform the computation, as well:

result: fhe.Value = server.run(deserialized_arg, evaluation_keys=deserialized_evaluation_keys)
serialized_result: bytes = result.serialize()

Then, send the serialized result back to the client. After this, the client can decrypt to receive the result of the computation.

Decrypting the result (on the client)

Once you have received the serialized result of the computation from the server, you can deserialize it:

deserialized_result = fhe.Value.deserialize(serialized_result)

Then, decrypt the result:

decrypted_result = client.decrypt(deserialized_result)
assert decrypted_result == 49

Deployment of modules

Deploying a module follows the same logic as the deployment of circuits. Assuming a module compiled in the following way:

from concrete import fhe

@fhe.module()
class MyModule:
    @fhe.function({"x": "encrypted"})
    def inc(x):
        return x + 1

    @fhe.function({"x": "encrypted"})
    def dec(x):
        return x - 1

inputset = list(range(20))
my_module = MyModule.compile({"inc": inputset, "dec": inputset})
)

You can extract the server from the module and save it in a file:

my_module.server.save("server.zip")

The only noticeable difference between the deployment of modules and the deployment of circuits is that the methods Client::encrypt, Client::decrypt and Server::run must contain an extra function_name argument specifying the name of the targeted function.

The encryption of an argument for the inc function of the module would be:

arg = client.encrypt(7, function_name="inc")
serialized_arg = arg.serialize()

The execution of the inc function would be :

result = server.run(deserialized_arg, evaluation_keys=deserialized_evaluation_keys, function_name="inc")
serialized_result = result.serialize()

Finally, decrypting a result from the execution of dec would be:

decrypted_result = client.decrypt(deserialized_result, function_name="dec")

Tutorials

See all tutorials

Start here

Go further

Code examples on GitHub

Blog tutorials

- November 7, 2023
- March 16, 2023

Video tutorials

- February 22, 2024
- October 27, 2023
- October 4, 2023
- July 28, 2023

Zama 5-Question Developer Survey

We want to hear from you! Take 1 minute to share your thoughts and helping us enhance our documentation and libraries. 👉 to participate.

References

Explanations

Compiler workflow

There are two main entry points to the Concrete Compiler. The first is to use the Concrete Python frontend. The second is to use the Compiler directly, which takes as input. Concrete Python is more high level and uses the Compiler under the hood.

Compilation begins in the frontend with tracing to get an easy-to-manipulate representation of the function. We call this representation a Computation Graph, which is a Directed Acyclic Graph (DAG) containing nodes representing computations done in the function. Working with graphs is useful because they have been studied extensively and there are a lot of available algorithms to manipulate them. Internally, we use , which is an excellent graph library for Python.

The next step in compilation is transforming the computation graph. There are many transformations we perform, and these are discussed in their own sections. The result of a transformation is another computation graph.

After transformations are applied, we need to determine the bounds (i.e., the minimum and the maximum values) of each intermediate node. This is required because FHE allows limited precision for computations. Measuring these bounds helps determine the required precision for the function.

The frontend is almost done at this stage and only needs to transform the computation graph to equivalent MLIR code. Once the MLIR is generated, our Compiler backend takes over. Any other frontend wishing to use the Compiler needs to plugin at this stage.

The Compiler takes MLIR code that makes use of both the FHE and FHELinalg for scalar and tensor operations respectively.

Compilation then ends with a series of that generates a native binary which contains executable code. Crypto parameters are generated along the way as well.

Tracing

We start with a Python function f, such as this one:

The goal of tracing is to create the following computation graph without requiring any change from the user.

(Note that the edge labels are for non-commutative operations. To give an example, a subtraction node represents (predecessor with edge label 0) - (predecessor with edge label 1))

To do this, we make use of Tracers, which are objects that record the operation performed during their creation. We create a Tracer for each argument of the function and call the function with those Tracers. Tracers make use of the operator overloading feature of Python to achieve their goal:

2 * y will be performed first, and * is overloaded for Tracer to return another tracer: Tracer(computation=Multiply(Constant(2), self.computation)), which is equal to Tracer(computation=Multiply(Constant(2), Input("y"))).

x + (2 * y) will be performed next, and + is overloaded for Tracer to return another tracer: Tracer(computation=Add(self.computation, (2 * y).computation)), which is equal to Tracer(computation=Add(Input("x"), Multiply(Constant(2), Input("y"))).

In the end, we will have output tracers that can be used to create the computation graph. The implementation is a bit more complex than this, but the idea is the same.

Tracing is also responsible for indicating whether the values in the node would be encrypted or not. The rule for that is: if a node has an encrypted predecessor, it is encrypted as well.

Topological transforms

The goal of topological transforms is to make more functions compilable.

With the current version of Concrete, floating-point inputs and floating-point outputs are not supported. However, if the floating-point operations are intermediate operations, they can sometimes be fused into a single table lookup from integer to integer, thanks to some specific transforms.

Let's take a closer look at the transforms we can currently perform.

Fusing.

We have allocated a whole new chapter to explaining fusing. You can find it .

Bounds measurement

Given a computation graph, the goal of the bounds measurement step is to assign the minimal data type to each node in the graph.

If we have an encrypted input that is always between 0 and 10, we should assign the type EncryptedScalar<uint4> to the node of this input as EncryptedScalar<uint4>. This is the minimal encrypted integer that supports all values between 0 and 10.

If there were negative values in the range, we could have used intX instead of uintX.

Bounds measurement is necessary because FHE supports limited precision, and we don't want unexpected behaviour while evaluating the compiled functions.

Let's take a closer look at how we perform bounds measurement.

Inputset evaluation

This is a simple approach that requires an inputset to be provided by the user.

The inputset is not to be confused with the dataset, which is classical in ML, as it doesn't require labels. Rather, the inputset is a set of values which are typical inputs of the function.

The idea is to evaluate each input in the inputset and record the result of each operation in the computation graph. Then we compare the evaluation results with the current minimum/maximum values of each node and update the minimum/maximum accordingly. After the entire inputset is evaluated, we assign a data type to each node using the minimum and maximum values it contains.

Here is an example, given this computation graph where x is encrypted:

and this inputset:

Evaluation result of 2:

x: 2
2: 2
*: 4
3: 3
+: 7

New bounds:

x: [2, 2]
2: [2, 2]
*: [4, 4]
3: [3, 3]
+: [7, 7]

Evaluation result of 3:

x: 3
2: 2
*: 6
3: 3
+: 9

New bounds:

x: [2, 3]
2: [2, 2]
*: [4, 6]
3: [3, 3]
+: [7, 9]

Evaluation result of 1:

x: 1
2: 2
*: 2
3: 3
+: 5

New bounds:

x: [1, 3]
2: [2, 2]
*: [2, 6]
3: [3, 3]
+: [5, 9]

Assigned data types:

x: EncryptedScalar<uint2>
2: ClearScalar<uint2>
*: EncryptedScalar<uint3>
3: ClearScalar<uint2>
+: EncryptedScalar<uint4>

MLIR Compiler Passes

We describe below some of the main passes in the compilation pipeline.

FHE to TFHE

This pass converts high level operations which are not crypto specific to lower level operations from the TFHE scheme. Ciphertexts get introduced in the code as well. TFHE operations and ciphertexts require some parameters which need to be chosen, and the pass does just that.

TFHE Parameterization

TFHE Parameterization takes care of introducing the chosen parameters in the Intermediate Representation (IR). After this pass, you should be able to see the dimension of ciphertexts, as well as other parameters in the IR.

TFHE to Concrete

This pass lowers TFHE operations to low level operations that are closer to the backend implementation, working on tensors and memory buffers (after a bufferization pass).

Concrete to LLVM

This pass lowers everything to LLVM-IR in order to generate the final binary.

Compiler internals

Truncating

Table lookups have a strict constraint on the number of bits they support. This can be limiting, especially if you don't need exact precision. As well as this, using larger bit-widths leads to slower table lookups.

To overcome these issues, truncated table lookups are introduced. This operation provides a way to zero the least significant bits of a large integer and then apply the table lookup on the resulting (smaller) value.

Imagine you have a 5-bit value, you can use fhe.truncate_bit_pattern(value, lsbs_to_remove=2) to truncate it (here the last 2 bits are discarded). Once truncated, value will remain in 5-bits (e.g., 22 = 0b10110 would be truncated to 20 = 0b10100), and the last 2 bits of it would be zero. Concrete uses this to optimize table lookups on the truncated value, the 5-bit table lookup gets optimized to a 3-bit table lookup, which is much faster!

Let's see how truncation works in practice:

prints:

and displays:

Now, let's see how truncating can be used in FHE.

prints:

These speed-ups can vary from system to system.

The reason why the speed-up is not increasing with lsbs_to_remove is because the truncating operation itself has a cost: each bit removal is a PBS. Therefore, if a lot of bits are removed, truncation itself could take longer than the bigger TLU which is evaluated afterwards.

and displays:

Auto Truncators

Truncating is very useful but, in some cases, you don't know how many bits your input contains, so it's not reliable to specify lsbs_to_remove manually. For this reason, the AutoTruncator class is introduced.

AutoTruncator allows you to set how many of the most significant bits to keep, but they need to be adjusted using an inputset to determine how many of the least significant bits to remove. This can be done manually using fhe.AutoTruncator.adjust(function, inputset), or by setting auto_adjust_truncators configuration to True during compilation.

Here is how auto truncators can be used in FHE:

prints:

and displays:

AutoTruncators should be defined outside the function that is being compiled. They are used to store the result of the adjustment process, so they shouldn't be created each time the function is called. Furthermore, each AutoTruncator should be used with exactly one truncate_bit_pattern call.

Floating points

Concrete partly supports floating points. There is no support for floating point inputs or outputs. However, there is support for intermediate values to be floating points (under certain constraints).

Floating points as intermediate values

Concrete-Compile, which is used for compiling the circuit, doesn't support floating points at all. However, it supports table lookups which take an integer and map it to another integer. The constraints of this operation are that there should be a single integer input, and a single integer output.

As long as your floating point operations comply with those constraints, Concrete automatically converts them to a table lookup operation:

In the example above, a, b, and c are floating point intermediates. They are used to calculate d, which is an integer with a value dependent upon x, which is also an integer. Concrete detects this and fuses all of these operations into a single table lookup from x to d.

This approach works for a variety of use cases, but it comes up short for others:

This results in:

The reason for the error is that d no longer depends solely on x; it depends on y as well. Concrete cannot fuse these operations, so it raises an exception instead.

Min/Max operations

Finding the minimum or maximum of two numbers is not a native operation in Concrete, so it needs to be implemented using existing native operations (i.e., additions, clear multiplications, negations, table lookups). Concrete offers two different implementations for this.

Chunked

This is the most general implementation that can be used in any situation. The idea is:

# (example below is for bit-width of 8 and chunk size of 4)

# compare lhs and rhs
select_lhs = lhs < rhs  # or lhs > rhs for maximum

# multiply lhs with select_lhs
lhs_contribution = lhs * select_lhs

# multiply rhs with 1 - select_lhs
rhs_contribution = rhs * (1 - select_lhs)

# compute the result
result = lhs_contribution + rhs_contribution

Notes

Initial comparison is chunked as well, which is already very expensive.
Multiplication with operands aren't allowed to increase the bit-width of the inputs, so they are very expensive as well.
Optimal chunk size is selected automatically to reduce the number of table lookups.
Chunked comparisons result in at least 9 and at most 21 table lookups.
It is used if no other implementation can be used.

Pros

Can be used with any integers.

Cons

Extremely expensive.

Example

import numpy as np
from concrete import fhe

def f(x, y):
    return np.minimum(x, y)

inputset = [
    (np.random.randint(0, 2**4), np.random.randint(0, 2**4))
    for _ in range(100)
]

compiler = fhe.Compiler(f, {"x": "encrypted", "y": "encrypted"})
circuit = compiler.compile(inputset, show_mlir=True)

produces

module {

  func.func @main(%arg0: !FHE.eint<4>, %arg1: !FHE.eint<4>) -> !FHE.eint<4> {
  
    // calculating select_x, which is x < y since we're computing the minimum
    %cst = arith.constant dense<[0, 0, 0, 0, 4, 4, 4, 4, 8, 8, 8, 8, 12, 12, 12, 12]> : tensor<16xi64>
    %0 = "FHE.apply_lookup_table"(%arg0, %cst) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %cst_0 = arith.constant dense<[0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3]> : tensor<16xi64>
    %1 = "FHE.apply_lookup_table"(%arg1, %cst_0) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %2 = "FHE.add_eint"(%0, %1) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>
    %cst_1 = arith.constant dense<[0, 1, 1, 1, 2, 0, 1, 1, 2, 2, 0, 1, 2, 2, 2, 0]> : tensor<16xi64>
    %3 = "FHE.apply_lookup_table"(%2, %cst_1) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %cst_2 = arith.constant dense<[0, 4, 8, 12, 0, 4, 8, 12, 0, 4, 8, 12, 0, 4, 8, 12]> : tensor<16xi64>
    %4 = "FHE.apply_lookup_table"(%arg0, %cst_2) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %cst_3 = arith.constant dense<[0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3]> : tensor<16xi64>
    %5 = "FHE.apply_lookup_table"(%arg1, %cst_3) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %6 = "FHE.add_eint"(%4, %5) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>
    %cst_4 = arith.constant dense<[0, 4, 4, 4, 8, 0, 4, 4, 8, 8, 0, 4, 8, 8, 8, 0]> : tensor<16xi64>
    %7 = "FHE.apply_lookup_table"(%6, %cst_4) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<4>
    %8 = "FHE.add_eint"(%7, %3) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>
    %cst_5 = arith.constant dense<[0, 1, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0]> : tensor<16xi64>
    %9 = "FHE.apply_lookup_table"(%8, %cst_5) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<1>
    
    // extracting the first 2 bits of x shifhted to left by 1 bits for packing
    %cst_6 = arith.constant dense<[0, 2, 4, 6, 0, 2, 4, 6, 0, 2, 4, 6, 0, 2, 4, 6]> : tensor<16xi64>
    %10 = "FHE.apply_lookup_table"(%arg0, %cst_6) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<3>
    
    // casting select_x to 3 bits for packing
    %cst_7 = arith.constant dense<[0, 1]> : tensor<2xi64>
    %11 = "FHE.apply_lookup_table"(%9, %cst_7) : (!FHE.eint<1>, tensor<2xi64>) -> !FHE.eint<3>
    
    // packing the first 2 bits of x with select_x
    %12 = "FHE.add_eint"(%10, %11) : (!FHE.eint<3>, !FHE.eint<3>) -> !FHE.eint<3>
    
    // calculating contribution of 0 if select_x is 0 else the first 2 bits of x
    %cst_8 = arith.constant dense<[0, 0, 0, 1, 0, 2, 0, 3]> : tensor<8xi64>
    %13 = "FHE.apply_lookup_table"(%12, %cst_8) : (!FHE.eint<3>, tensor<8xi64>) -> !FHE.eint<4>
    
    // extracting the last 2 bits of x shifhted to the left by 1 bit for packing
    %cst_9 = arith.constant dense<[0, 0, 0, 0, 2, 2, 2, 2, 4, 4, 4, 4, 6, 6, 6, 6]> : tensor<16xi64>
    %14 = "FHE.apply_lookup_table"(%arg0, %cst_9) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<3>
    
    // packing the last 2 bits of x with select_x
    %15 = "FHE.add_eint"(%14, %11) : (!FHE.eint<3>, !FHE.eint<3>) -> !FHE.eint<3>
    
    // calculating contribution of 0 if select_x is 0 else the last 2 bits of x shifted by 2 bits for direct addition
    %cst_10 = arith.constant dense<[0, 0, 0, 4, 0, 8, 0, 12]> : tensor<8xi64>
    %16 = "FHE.apply_lookup_table"(%15, %cst_10) : (!FHE.eint<3>, tensor<8xi64>) -> !FHE.eint<4>
    
    // computing x * select_x
    %17 = "FHE.add_eint"(%13, %16) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>
    
    // extracting the first 2 bits of y shifhted to the left by 1 bit for packing
    %18 = "FHE.apply_lookup_table"(%arg1, %cst_6) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<3>
    
    // packing the first 2 bits of y with select_x
    %19 = "FHE.add_eint"(%18, %11) : (!FHE.eint<3>, !FHE.eint<3>) -> !FHE.eint<3>
    
    // calculating contribution of 0 if select_x is 1 else the first 2 bits of y
    %cst_11 = arith.constant dense<[0, 0, 1, 0, 2, 0, 3, 0]> : tensor<8xi64>
    %20 = "FHE.apply_lookup_table"(%19, %cst_11) : (!FHE.eint<3>, tensor<8xi64>) -> !FHE.eint<4>
    
    // extracting the last 2 bits of y shifhted to left by 1 bit for packing
    %21 = "FHE.apply_lookup_table"(%arg1, %cst_9) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.eint<3>
    
    // packing the last 2 bits of y with select_x
    %22 = "FHE.add_eint"(%21, %11) : (!FHE.eint<3>, !FHE.eint<3>) -> !FHE.eint<3>
    
    // calculating contribution of 0 if select_x is 1 else the last 2 bits of y shifted by 2 bits for direct addition
    %cst_12 = arith.constant dense<[0, 0, 4, 0, 8, 0, 12, 0]> : tensor<8xi64>
    %23 = "FHE.apply_lookup_table"(%22, %cst_12) : (!FHE.eint<3>, tensor<8xi64>) -> !FHE.eint<4>
    
    // computing y * (1 - select_x)
    %24 = "FHE.add_eint"(%20, %23) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>
    
    // computing the result
    %25 = "FHE.add_eint"(%17, %24) : (!FHE.eint<4>, !FHE.eint<4>) -> !FHE.eint<4>

    return %25 : !FHE.eint<4>
    
  }
  
}

Min/Max Trick

This implementation uses the fact that [min,max](x, y) is equal to [min, max](x - y, 0) + y, which is just a subtraction, a table lookup and an addition!

There are two major problems with this implementation though:

subtraction before the TLU requires up to 2 additional bits to avoid overflows (it is 1 in most cases).
subtraction and addition require the same bit-width across operands.

What this means is that if we are comparing uint3 and uint6, we need to convert both of them to uint7 in some way to do the subtraction and proceed with the TLU in 7-bits. There are 2 ways to achieve this behavior.

Requirements

(x - y).bit_width <= MAXIMUM_TLU_BIT_WIDTH

1. fhe.MinMaxStrategy.ONE_TLU_PROMOTED

This strategy makes sure that during bit-width assignment, both operands are assigned the same bit-width, and that bit-width contains at least the amount of bits required to store x - y. The idea is:

comparison_lut = fhe.LookupTable([...])
result = comparison_lut[x_promoted_to_uint7 - y_promoted_to_uint7] + y_promoted_to_uint7

Pros

It will always result in a single table lookup.

Cons

It will increase the bit-width of both operands and the result, and lock them together across the whole circuit, which can result in significant slowdowns if the result or the operands are used in other costly operations.

Example

import numpy as np
from concrete import fhe

configuration = fhe.Configuration(
    min_max_strategy_preference=fhe.MinMaxStrategy.ONE_TLU_PROMOTED,
)

def f(x, y):
    return np.minimum(x, y)

inputset = [
    (np.random.randint(0, 2**4), np.random.randint(0, 2**2))
    for _ in range(100)
]

compiler = fhe.Compiler(f, {"x": "encrypted", "y": "encrypted"})
circuit = compiler.compile(inputset, configuration, show_mlir=True)

produces

module {

  // promotions          ............         ............
  func.func @main(%arg0: !FHE.eint<5>, %arg1: !FHE.eint<5>) -> !FHE.eint<5> {
  
    // subtraction
    %0 = "FHE.to_signed"(%arg0) : (!FHE.eint<5>) -> !FHE.esint<5>
    %1 = "FHE.to_signed"(%arg1) : (!FHE.eint<5>) -> !FHE.esint<5>
    %2 = "FHE.sub_eint"(%0, %1) : (!FHE.esint<5>, !FHE.esint<5>) -> !FHE.esint<5>
    
    // tlu
    %cst = arith.constant dense<[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -16, -15, -14, -13, -12, -11, -10, -9, -8, -7, -6, -5, -4, -3, -2, -1]> : tensor<32xi64>
    %3 = "FHE.apply_lookup_table"(%2, %cst) : (!FHE.esint<5>, tensor<32xi64>) -> !FHE.eint<5>
    
    // addition
    %4 = "FHE.add_eint"(%3, %arg1) : (!FHE.eint<5>, !FHE.eint<5>) -> !FHE.eint<5>
    
    return %4 : !FHE.eint<5>
    
  }
  
}

2. fhe.MinMaxStrategy.THREE_TLU_CASTED

This strategy will not put any constraint on bit-widths during bit-width assignment. Instead, operands are cast to a bit-width that can store x - y during runtime using table lookups. The idea is:

uint3_to_uint7_lut = fhe.LookupTable([...])
x_cast_to_uint7 = uint3_to_uint7_lut[x]

uint6_to_uint7_lut = fhe.LookupTable([...])
y_cast_to_uint7 = uint6_to_uint7_lut[y]

comparison_lut = fhe.LookupTable([...])
result = comparison_lut[x_cast_to_uint7 - y_cast_to_uint7] + y

Notes

It can result in a single table lookup as well, if x and y are assigned (because of other operations) the same bit-width, and that bit-width can store x - y.
Or in two table lookups if only one of the operands is assigned a bit-width bigger than or equal to the bit width that can store x - y.

Pros

It will not put any constraints on bit-widths of the operands, which is amazing if they are used in other costly operations.
It will result in at most 3 table lookups, which is still good.

Cons

If you are not doing anything else with the operands, or doing less costly operations compared to comparison, it will introduce up to two unnecessary table lookups and slow down execution compared to fhe.MinMaxStrategy.ONE_TLU_PROMOTED.

Example

import numpy as np
from concrete import fhe

configuration = fhe.Configuration(
    min_max_strategy_preference=fhe.MinMaxStrategy.THREE_TLU_CASTED,
)

def f(x, y):
    return np.minimum(x, y)

inputset = [
    (np.random.randint(0, 2**4), np.random.randint(0, 2**2))
    for _ in range(100)
]

compiler = fhe.Compiler(f, {"x": "encrypted", "y": "encrypted"})
circuit = compiler.compile(inputset, configuration, show_mlir=True)

produces

module {

  // no promotions
  func.func @main(%arg0: !FHE.eint<4>, %arg1: !FHE.eint<2>) -> !FHE.eint<2> {
  
    // casting x
    %cst = arith.constant dense<[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]> : tensor<16xi64>
    %0 = "FHE.apply_lookup_table"(%arg0, %cst) : (!FHE.eint<4>, tensor<16xi64>) -> !FHE.esint<5>
    
    // casting y
    %cst_0 = arith.constant dense<[0, 1, 2, 3]> : tensor<4xi64>
    %1 = "FHE.apply_lookup_table"(%arg1, %cst_0) : (!FHE.eint<2>, tensor<4xi64>) -> !FHE.esint<5>
    
    // subtraction
    %2 = "FHE.sub_eint"(%0, %1) : (!FHE.esint<5>, !FHE.esint<5>) -> !FHE.esint<5>
    
    // tlu
    %cst_1 = arith.constant dense<[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -16, -15, -14, -13, -12, -11, -10, -9, -8, -7, -6, -5, -4, -3, -2, -1]> : tensor<32xi64>
    %3 = "FHE.apply_lookup_table"(%2, %cst_1) : (!FHE.esint<5>, tensor<32xi64>) -> !FHE.eint<2>
    
    // addition
    %4 = "FHE.add_eint"(%3, %arg1) : (!FHE.eint<2>, !FHE.eint<2>) -> !FHE.eint<2>
    
    return %4 : !FHE.eint<2>
    
  }
  
}

Summary

Strategy

Minimum # of TLUs

Maximum # of TLUs

Can increase the bit-width of the inputs

CHUNKED

ONE_TLU_PROMOTED

✓

THREE_TLU_CASTED

Concrete will choose the best strategy available after bit-width assignment, regardless of the specified preference.

Different strategies are good for different circuits. If you want the best runtime for your use case, you can compile your circuit with all different comparison strategy preferences, and pick the one with the lowest complexity.

Direct circuits

Direct circuits are still experimental. It is very easy to make mistakes (e.g., due to no overflow checks or type coercion) while using direct circuits, so utilize them with care.

For some applications, the data types of inputs, intermediate values, and outputs are known (e.g., for manipulating bytes, you would want to use uint8). Using inputsets to determine bounds in these cases is not necessary, and can even be error-prone. Therefore, another interface for defining such circuits is introduced:

from concrete import fhe

@fhe.circuit({"x": "encrypted"})
def circuit(x: fhe.uint8):
    return x + 42

assert circuit.encrypt_run_decrypt(10) == 52

There are a few differences between direct circuits and traditional circuits:

Remember that the resulting dtype for each operation will be determined by its inputs. This can lead to some unexpected results if you're not careful (e.g., if you do -x where x: fhe.uint8, you won't receive a negative value as the result will be fhe.uint8 as well)
There is no inputset evaluation when using fhe types in .astype(...) calls (e.g., np.sqrt(x).astype(fhe.uint4)), so the bit width of the output cannot be determined.
Specify the resulting data type in univariate extension (e.g., fhe.univariate(function, outputs=fhe.uint4)(x)), for the same reason as above.
Be careful with overflows. With inputset evaluation, you'll get bigger bit widths but no overflows. With direct definition, you must ensure that there aren't any overflows manually.

Let's review a more complicated example to see how direct circuits behave:

from concrete import fhe
import numpy as np

def square(value):
    return value ** 2

@fhe.circuit({"x": "encrypted", "y": "encrypted"})
def circuit(x: fhe.uint8, y: fhe.int2):
    a = x + 10
    b = y + 10

    c = np.sqrt(a).round().astype(fhe.uint4)
    d = fhe.univariate(square, outputs=fhe.uint8)(b)

    return d - c

print(circuit)

This prints:

%0 = x                       # EncryptedScalar<uint8>
%1 = y                       # EncryptedScalar<int2>
%2 = 10                      # ClearScalar<uint4>
%3 = add(%0, %2)             # EncryptedScalar<uint8>
%4 = 10                      # ClearScalar<uint4>
%5 = add(%1, %4)             # EncryptedScalar<int4>
%6 = subgraph(%3)            # EncryptedScalar<uint4>
%7 = square(%5)              # EncryptedScalar<uint8>
%8 = subtract(%7, %6)        # EncryptedScalar<uint8>
return %8

Subgraphs:

    %6 = subgraph(%3):

        %0 = input                         # EncryptedScalar<uint8>
        %1 = sqrt(%0)                      # EncryptedScalar<float64>
        %2 = around(%1, decimals=0)        # EncryptedScalar<float64>
        %3 = astype(%2)                    # EncryptedScalar<uint4>
        return %3

Here is the breakdown of the assigned data types:

%0 is uint8 because it's specified in the definition
%1 is  int2 because it's specified in the definition
%2 is uint4 because it's the constant 10
%3 is uint8 because it's the addition between uint8 and uint4
%4 is uint4 because it's the constant 10
%5 is  int4 because it's the addition between int2 and uint4
%6 is uint4 because it's specified in astype
%7 is uint8 because it's specified in univariate
%8 is uint8 because it's subtraction between uint8 and uint4

As you can see, %8 is subtraction of two unsigned values, and the result is unsigned as well. In the case that c > d, we have an overflow, and this results in undefined behavior.

Tagging

When you have big circuits, keeping track of which node corresponds to which part of your code becomes difficult. A tagging system can simplify such situations:

When you compile f with inputset of range(10), you get the following graph:

If you get an error, you'll see exactly where the error occurred (e.g., which layer of the neural network, if you tag layers).

In the future, we plan to use tags for additional features (e.g., to measure performance of tagged regions), so it's a good idea to start utilizing them for big circuits.

Security

Parameter Curves

To select secure cryptographic parameters for usage in Concrete, we utilize the Lattice-Estimator. In particular, we use the following workflow:

Data Acquisition
- For a given value of $(n, q = 2^{64}, \sigma)$ we obtain raw data from the Lattice Estimator, which ultimately leads to a security level $\lambda$ . All relevant attacks in the Lattice Estimator are considered.
- Increase the value of $\sigma$ , until the tuple $(n, q = 2^{64}, \sigma)$ satisfies the target level of security $\lambda_{target}$ .
- Repeat for several values of $n$ .
Model Generation for $\lambda = \lambda_{target}$ .
- At this point, we have several sets of points $\{(n, q = 2^{64}, \sigma)\}$ satisfying the target level of security $\lambda_{target}$ . From here, we fit a model to this raw data ( $\sigma$ as a function of $n$ ).
Model Verification.
- For each model, we perform a verification check to ensure that the values output from the function $\sigma(n)$ provide the claimed level of security, $\lambda_{target}$ .

These models are then used as input for Concrete, to ensure that the parameter space explored by the compiler attains the required security level. Note that we consider the RC.BDGL16 lattice reduction cost model within the Lattice Estimator. Therefore, when computing our security estimates, we use the call LWE.estimate(params, red_cost_model = RC.BDGL16) on the input parameter set params.

The cryptographic parameters are chosen considering the IND-CPA security model, and are selected with a bootstrapping failure probability fixed by the user. In particular, it is assumed that the results of decrypted computations are not shared by the secret key owner with any third parties, as such an action can lead to leakage of the secret encryption key. If you are designing an application where decryptions must be shared, you will need to craft custom encryption parameters which are chosen in consideration of the IND-CPA^D security model [1].

[1] Li, Baiyu, et al. “Securing approximate homomorphic encryption using differential privacy.” Annual International Cryptology Conference. Cham: Springer Nature Switzerland, 2022. https://eprint.iacr.org/2022/816.pdf

Usage

To generate the raw data from the lattice estimator, use::

make generate-curves

by default, this script will generate parameter curves for {80, 112, 128, 192} bits of security, using $log_2(q) = 64$ .

To compare the current curves with the output of the lattice estimator, use:

make compare-curves

this will compare the four curves generated above against the output of the version of the lattice estimator found in the third_party folder.

To generate the associated cpp and rust code, use::

make generate-code

further advanced options can be found inside the Makefile.

Example

To look at the raw data gathered in step 1., we can look in the sage-object folder. These objects can be loaded in the following way using SageMath:

sage: X = load("128.sobj")

entries are tuples of the form: $(n, log_2(q), log_2(\sigma), \lambda)$ . We can view individual entries via::

sage: X["128"][0]
(2366, 64.0, 4.0, 128.51)

To view the interpolated curves we load the verified_curves.sobj object inside the sage-object folder.

sage: curves = load("verified_curves.sobj")

This object is a tuple containing the information required for the four security curves ({80, 112, 128, 192} bits of security). Looking at one of the entries:

sage: curves[2][:3]
(-0.026599462343105267, 2.981543184145991, 128)

Here we can see the linear model parameters $(a = -0.026599462343105267, b = 2.981543184145991)$ along with the security level 128. This linear model can be used to generate secure parameters in the following way: for $q = 2^{64}$ , if we have an LWE dimension of $n = 1536$ , then the required noise size is:

$\sigma = a * n + b = -37.85$

This value corresponds to the logarithm of the relative error size. Using the parameter set $(n, log(q), \sigma = 2^{64 - 37.85})$ in the Lattice Estimator confirms a 128-bit security level.

Frontend fusing

Fusing is the act of combining multiple nodes into a single node, which is converted to a table lookup.

How is it done?

Code related to fusing is in the frontends/concrete-python/concrete/fhe/compilation/utils.py file. Fusing can be performed using the fuse function.

Within fuse:

We loop until there are no more subgraphs to fuse.
Within each iteration: 2.1. We find a subgraph to fuse.
2.2. We search for a terminal node that is appropriate for fusing.
2.3. We crawl backwards to find the closest integer nodes to this node.
2.4. If there is a single node as such, we return the subgraph from this node to the terminal node.
2.5. Otherwise, we try to find the lowest common ancestor (lca) of this list of nodes.
2.6. If an lca doesn't exist, we say this particular terminal node is not fusable, and we go back to search for another subgraph.
2.7. Otherwise, we use this lca as the input of the subgraph and continue with subgraph node creation below.
2.8. We convert the subgraph into a subgraph node by checking fusability status of the nodes of the subgraph in this step.
2.9. We substitute the subgraph node to the original graph.

Limitations

With the current implementation, we cannot fuse subgraphs that depend on multiple encrypted values where those values don't have a common lca (e.g., np.round(np.sin(x) + np.cos(y))).

Developers

Contributing

There are two ways to contribute to Concrete. You can:

Open issues to report bugs and typos or suggest ideas;
Request to become an official contributor by emailing [email protected]. Only approved contributors can send pull requests (PRs), so get in touch before you do.

Project layout

Concrete layout

Concrete is a modular framework composed by sub-projects using different technologies, all having theirs own build system and test suite. Each sub-project have is own README that explain how to setup the developer environment, how to build it and how to run tests commands.

Concrete is made of 4 main categories of sub-project that are organized in subdirectories from the root of the Concrete repo:

frontends contains high-level transpilers that target end users developers who want to use the Concrete stack easily from their usual environment. There are for now only one frontend provided by the Concrete project: a Python frontend named concrete-python.
compilers contains the sub-projects in charge of actually solving the compilation problem of an high-level abstraction of FHE to an actual executable. concrete-optimizer is a Rust based project that solves the optimization problems of an FHE dag to a TFHE dag and concrete-compiler which use concrete-optimizer is an end-to-end MLIR-based compiler that takes a crypto free FHE dialect and generates compilation artifacts both for the client and the server. concrete-compiler project provide in addition of the compilation engine, a client and server library in order to easily play with the compilation artifacts to implement a client and server protocol.
backends contains CAPI that can be called by the concrete-compiler runtime to perform the cryptographic operations. There are currently two backends:
- concrete-cpu, using TFHE-rs that implement the fastest implementation of TFHE on CPU.
- concrete-cuda that provides a GPU acceleration of TFHE primitives.
tools are basically every other sub-projects that cannot be classified in the three previous categories and which are used as a common support by the others.

Concrete Python layout

The module structure of Concrete Python. You are encouraged to check individual .py files to learn more.

concrete
- fhe
  - dtypes: data type specifications (e.g., int4, uint5, float32)
  - values: value specifications (i.e., data type + shape + encryption status)
  - representation: representation of computation (e.g., computation graphs, nodes)
  - tracing: tracing of python functions
  - extensions: custom functionality (see Extensions)
  - mlir: computation graph to mlir conversion
  - compilation: configuration, compiler, artifacts, circuit, client/server, and anything else related to compilation

Compiler backend

The Concrete backends are implementations of the cryptographic primitives of the Zama variant of TFHE. The compiler emits code which combines call into these backends to perform more complex homomorphic operations.

There are client and server features.

Client features are:

private (G)LWE key generation (currently random bits)
encryption of ciphertexts using a private key
public key generation from private keys for keyswitch, bootstrap or private packing
(de)serialization of ciphertexts and public keys (also needed server side)

Server features are homomorphic operations on ciphertexts:

linear operations (multisums with plain weights)
keyswitch
simple PBS
WoP PBS

There are currently 2 backends:

concrete-cpu which implements both client and server features targeting the CPU.
concrete-cuda which implements only server features targeting GPUs to accelerate homomorphic circuit evaluation.

The compiler uses concrete-cpu for the client and can use either concrete-cpu or concrete-cuda for the server.

Optimizer

concrete-optimizer is a tool that selects appropriate cryptographic parameters for a given fully homomorphic encryption (FHE) computation. These parameters have an impact on the security, correctness, and efficiency of the computation.

The computation is guaranteed to be secure with the given level of security (see here for details) which is typically 128 bits. The correctness of the computation is guaranteed up to a given failure probability. A surrogate of the execution time is minimized which allows for efficient FHE computation.

The cryptographic parameters are degrees of freedom in the FHE algorithms (bootstrapping, keyswitching, etc.) that need to be fixed. The search space for possible crypto-parameters is finite but extremely large. The role of the optimizer is to quickly find the most efficient crypto-parameters possible while guaranteeing security and correctness.

Security, Correctness, and Efficiency

Security

The security level is chosen by the user. We typically operate at a fixed security level, such as 128 bits, to ensure that there is never a trade-off between security and efficiency. This constraint imposes a minimum amount of noise in all ciphertexts.

An independent public research tool, the lattice estimator, is used to estimate the security level. The lattice estimator is maintained by FHE experts. For a given set of crypto-parameters, this tool considers all possible attacks and returns a security level.

For each security level, a parameter curve of the appropriate minimal error level is pre-computed using the lattice estimator, and is used as an input to the optimizer. Learn more about the parameter curves here.

Correctness

Correctness decreases as the level of noise increases. Noise accumulates during homomorphic computation until it is actively reduced via bootstrapping. Too much noise can lead to the result of a computation being inaccurate or completely incorrect.

Before optimization, we compute a noise bound that guarantees a given error level (under the assumption that noise growth is correctly managed via bootstrapping). The noise growth depends on a critical quantity: the 2-norm of any dot product (or equivalent) present in the calculus. This 2-norm changes the scale of the noise, so we must reduce it sufficiently for the next dot product operation whenever we reduce the noise.

The user can control error probability in two ways: via the PBS error probability and the global error probability.

The PBS error probability controls correctness locally (i.e., represents the error probability of a single PBS operation), while the global error probability focuses on the overall computation result (i.e., represents the error probability of the entire computation). These probabilities are related, and choosing which one to use may depend on the specific use case.

Efficiency

Efficiency decreases as more precision is required, e.g. 7-bits versus 8-bits. The larger the 2-norm is, the bigger the noise will be after a dot product. To remain below the noise bound, we must ensure that the inputs to the dot product have a sufficiently small noise level. The smaller this noise is, the slower the previous bootstrapping will be. Therefore, the larger the 2norm is, the slower the computation will be.

How are the parameters optimized

The optimization prioritizes security and correctness. This means that the security level (or the probability of correctness) could, in practice, be a bit higher than the level which is requested by the user.

In the simplest case, the optimizer performs an exhaustive search in the full parameter space and selects the best solution. While the space to explore is huge, exact lower bound cuts are used to avoid exploring regions which are guaranteed to not contain an optimal point. This makes the process both fast and exhaustive. This case is called mono-parameter, where all parameters are shared by the whole computation graph.

In more complex cases, the optimizer iteratively performs an exhaustive search, with lower bound cuts in a wide subspace of the full parameter space, until it converges to a locally optimal solution. Since the wide subspace is large and multi-dimensional, it should not be trapped in a poor locally optimal solution. The more complex case is called multi-parameter, where different calculus operations have tailored parameters.

How can I determine, understand, and explore crypto-parameters

One can have a look at reference crypto-parameters for each security level (but for a given correctness). This provides insight between the calcululs content (i.e. maximum precision, maximum dot 2-norm, etc.,) and the cost.

Then one can manually explore crypto-parameters space using a CLI tool.

Citing

If you use this tool in your work, please cite:

Bergerat, Loris and Boudi, Anas and Bourgerie, Quentin and Chillotti, Ilaria and Ligier, Damien and Orfila Jean-Baptiste and Tap, Samuel, Parameter Optimization and Larger Precision for (T)FHE, Journal of Cryptology, 2023, Volume 36

A pre-print is available as Cryptology ePrint Archive Paper 2022/704

MLIR FHE dialects

Introduction

Compilation of a Python program starts with Concrete's Python frontend, which first traces and transforms it and then converts it into an intermediate representation (IR) that is further processed by Concrete Compiler. This IR is based on the MLIR subproject of the LLVM compiler infrastructure. This document provides an overview of Concrete's FHE-specific representations based on the MLIR framework.

In contrast to traditional infrastructure for compilers, the set of operations and data types that constitute the IR, as well as the level of abstraction that the IR represents, are not fixed in MLIR and can easily be extended. All operations and data types are grouped into dialects, with each dialect representing a specific domain or a specific level of abstraction. Mixing operations and types from different dialects within the same IR is allowed and even encouraged, with all dialects--builtin or developed as an extension--being first-class citizens.

Concrete compiler takes advantage of these concepts by defining a set of dialects, capable of representing an FHE program from an abstract specification that is independent of the actual cryptosystem down to a program that can easily be mapped to function calls of a cryptographic library. The dialects for the representation of an FHE program are:

The FHELinalg Dialect (documentation, source)
The FHE Dialect (documentation, source)
The TFHE Dialect (documentation, source)
The Concrete Dialect (documentation, source)
and for debugging purposes, the Tracing Dialect (documentation, source).

In addition, the project further defines two dialects that help expose dynamic task-parallelism and static data-flow graphs in order to benefit from multi-core, multi-accelerator and distributed systems. These are:

The RT Dialect (documentation, source) and
The SDFG Dialect (documentation, source).

The figure below illustrates the relationship between the dialects and their embedding into the compilation pipeline.

The following sections focus on the FHE-related dialects, i.e., on the FHELinalg Dialect, the FHE Dialect, the TFHE Dialect and the Concrete Dialect.

The FHE and FHELinalg Dialects: An abstract specification of an FHE program

The top part of the figure shows the components which are involved in the generation of the initial IR, ending with the step labelled MLIR translation. When the initial IR is passed on to Concrete Compiler through its Python bindings, all FHE-related operations are specified using either the FHE or FHELinalg Dialect. Both of these dialects provide operations and data types for the abstract specification of an FHE program, completely independently of a cryptosystem. At this point, the IR simply indicates whether an operand is encrypted (via the type FHE.eint<n>, where n stands for the precision in bits) and what operations are applied to encrypted values. Plaintext values simply use MLIR's builtin integer type in (e.g., i3 or i64).

The FHE Dialect provides scalar operations on encrypted integers, such as additions (FHE.add_eint) or multiplications (FHE.mul_eint), while the FHELinalg Dialect offers operations on tensors of encrypted integers, e.g., matrix products (FHELinalg.matmul_eint_eint) or convolutions (FHELinalg.conv2d).

In a first lowering step of the pipeline, all FHELinalg operations are lowered to operations from MLIR's builtin Linalg Dialect using scalar operations from the FHE Dialect. Consider the following example, which consists of a function that performs a multiplication of a matrix of encrypted integers and a matrix of cleartext values:

func.func @main(%arg0: tensor<4x3x!FHE.eint<2>>, %arg1: tensor<3x2xi3>) -> tensor<4x2x!FHE.eint<2>> {
  %0 = "FHELinalg.matmul_eint_int"(%arg0, %arg1) : (tensor<4x3x!FHE.eint<2>>, tensor<3x2xi3>) -> tensor<4x2x!FHE.eint<2>>
  return %0 : tensor<4x2x!FHE.eint<2>>
}

Upon conversion, the FHELinalg.matmul operation is converted to a linalg.generic operation whose body contains a scalar multiplication (FHE.mul_eint_int) and a scalar addition (FHE.add_eint_int):

#map = affine_map<(d0, d1, d2) -> (d0, d2)>
#map1 = affine_map<(d0, d1, d2) -> (d2, d1)>
#map2 = affine_map<(d0, d1, d2) -> (d0, d1)>

func.func @main(%arg0: tensor<4x3x!FHE.eint<2>>, %arg1: tensor<3x2xi3>) -> tensor<4x2x!FHE.eint<2>> {
  %0 = "FHE.zero_tensor"() : () -> tensor<4x2x!FHE.eint<2>>
  %1 = linalg.generic {indexing_maps = [#map, #map1, #map2], iterator_types = ["parallel", "parallel", "reduction"]} ins(%arg0, %arg1 : tensor<4x3x!FHE.eint<2>>, tensor<3x2xi3>) outs(%0 : tensor<4x2x!FHE.eint<2>>) {
  ^bb0(%in: !FHE.eint<2>, %in_0: i3, %out: !FHE.eint<2>):
    %2 = "FHE.mul_eint_int"(%in, %in_0) : (!FHE.eint<2>, i3) -> !FHE.eint<2>
    %3 = "FHE.add_eint"(%out, %2) : (!FHE.eint<2>, !FHE.eint<2>) -> !FHE.eint<2>
    linalg.yield %3 : !FHE.eint<2>
  } -> tensor<4x2x!FHE.eint<2>>
  return %1 : tensor<4x2x!FHE.eint<2>>
}

This is then further lowered to a nest of loops from MLIR's SCF Dialect, implementing the parallel and reduction dimensions from the linalg.generic operation above:

func.func @main(%arg0: tensor<4x3x!FHE.eint<2>>, %arg1: tensor<3x2xi3>) -> tensor<4x2x!FHE.eint<2>> {
  %c0 = arith.constant 0 : index
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c2 = arith.constant 2 : index
  %c3 = arith.constant 3 : index
  %0 = "FHE.zero_tensor"() : () -> tensor<4x2x!FHE.eint<2>>
  %1 = scf.for %arg2 = %c0 to %c4 step %c1 iter_args(%arg3 = %0) -> (tensor<4x2x!FHE.eint<2>>) {
    %2 = scf.for %arg4 = %c0 to %c2 step %c1 iter_args(%arg5 = %arg3) -> (tensor<4x2x!FHE.eint<2>>) {
      %3 = scf.for %arg6 = %c0 to %c3 step %c1 iter_args(%arg7 = %arg5) -> (tensor<4x2x!FHE.eint<2>>) {
        %extracted = tensor.extract %arg0[%arg2, %arg6] : tensor<4x3x!FHE.eint<2>>
        %extracted_0 = tensor.extract %arg1[%arg6, %arg4] : tensor<3x2xi3>
        %extracted_1 = tensor.extract %arg7[%arg2, %arg4] : tensor<4x2x!FHE.eint<2>>
        %4 = "FHE.mul_eint_int"(%extracted, %extracted_0) : (!FHE.eint<2>, i3) -> !FHE.eint<2>
        %5 = "FHE.add_eint"(%extracted_1, %4) : (!FHE.eint<2>, !FHE.eint<2>) -> !FHE.eint<2>
        %inserted = tensor.insert %5 into %arg7[%arg2, %arg4] : tensor<4x2x!FHE.eint<2>>
        scf.yield %inserted : tensor<4x2x!FHE.eint<2>>
      }
      scf.yield %3 : tensor<4x2x!FHE.eint<2>>
    }
    scf.yield %2 : tensor<4x2x!FHE.eint<2>>
  }
  return %1 : tensor<4x2x!FHE.eint<2>>
}

The TFHE Dialect: Binding to the TFHE cryptosystem and parametrization

In order to obtain an executable program at the end of the compilation pipeline, the abstract specification of the FHE program must at some point be bound to a specific cryptosystem. This is the role of the TFHE Dialect, whose purpose is:

to indicate operations to be carried out using an implementation of the TFHE cryptosystem
to parametrize the cryptosystem with key sizes, and
to provide a mapping between keys and encrypted values

When lowering the IR based on the FHE Dialect to the TFHE Dialect, the compiler first generates a generic form, in which FHE operations are lowered to TFHE operations and where values are converted to unparametrized TFHE.glwe values. The unparametrized form TFHE.glwe<sk?> simply indicates that a TFHE.glwe value is to be used, but without any indication of the cryptographic parameters and the actual key.

The IR below shows the example program after lowering to unparametrized TFHE:

func.func @main(%arg0: tensor<4x3x!TFHE.glwe<sk?>>, %arg1: tensor<3x2xi3>) -> tensor<4x2x!TFHE.glwe<sk?>> {
  %c0 = arith.constant 0 : index
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c2 = arith.constant 2 : index
  %c3 = arith.constant 3 : index
  %0 = "TFHE.zero_tensor"() : () -> tensor<4x2x!TFHE.glwe<sk?>>
  %1 = scf.for %arg2 = %c0 to %c4 step %c1 iter_args(%arg3 = %0) -> (tensor<4x2x!TFHE.glwe<sk?>>) {
    %2 = scf.for %arg4 = %c0 to %c2 step %c1 iter_args(%arg5 = %arg3) -> (tensor<4x2x!TFHE.glwe<sk?>>) {
      %3 = scf.for %arg6 = %c0 to %c3 step %c1 iter_args(%arg7 = %arg5) -> (tensor<4x2x!TFHE.glwe<sk?>>) {
        %extracted = tensor.extract %arg0[%arg2, %arg6] : tensor<4x3x!TFHE.glwe<sk?>>
        %extracted_0 = tensor.extract %arg1[%arg6, %arg4] : tensor<3x2xi3>
        %extracted_1 = tensor.extract %arg7[%arg2, %arg4] : tensor<4x2x!TFHE.glwe<sk?>>
        %4 = arith.extsi %extracted_0 : i3 to i64
        %5 = "TFHE.mul_glwe_int"(%extracted, %4) : (!TFHE.glwe<sk?>, i64) -> !TFHE.glwe<sk?>
        %6 = "TFHE.add_glwe"(%extracted_1, %5) : (!TFHE.glwe<sk?>, !TFHE.glwe<sk?>) -> !TFHE.glwe<sk?>
        %inserted = tensor.insert %6 into %arg7[%arg2, %arg4] : tensor<4x2x!TFHE.glwe<sk?>>
        scf.yield %inserted : tensor<4x2x!TFHE.glwe<sk?>>
      }
      scf.yield %3 : tensor<4x2x!TFHE.glwe<sk?>>
    }
    scf.yield %2 : tensor<4x2x!TFHE.glwe<sk?>>
  }
  return %1 : tensor<4x2x!TFHE.glwe<sk?>>
}

All operations from the FHE dialect have been replaced with corresponding operations from the TFHE Dialect.

During subsequent parametrization, the compiler can either use a set of default parameters or can obtain a set of parameters from Concrete's optimizer. Either way, an additional pass injects the parameters into the IR, replacing all TFHE.glwe<sk?> instances with TFHE.glwe<i,d,n>, where i is a sequential identifier for a key, d the number of GLWE dimensions and n the size of the GLWE polynomial.

The result of such a parametrization for the example is given below:

func.func @main(%arg0: tensor<4x3x!TFHE.glwe<sk<0,1,512>>>, %arg1: tensor<3x2xi3>) -> tensor<4x2x!TFHE.glwe<sk<0,1,512>>> {
  %c0 = arith.constant 0 : index
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c2 = arith.constant 2 : index
  %c3 = arith.constant 3 : index
  %0 = "TFHE.zero_tensor"() : () -> tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
  %1 = scf.for %arg2 = %c0 to %c4 step %c1 iter_args(%arg3 = %0) -> (tensor<4x2x!TFHE.glwe<sk<0,1,512>>>) {
    %2 = scf.for %arg4 = %c0 to %c2 step %c1 iter_args(%arg5 = %arg3) -> (tensor<4x2x!TFHE.glwe<sk<0,1,512>>>) {
      %3 = scf.for %arg6 = %c0 to %c3 step %c1 iter_args(%arg7 = %arg5) -> (tensor<4x2x!TFHE.glwe<sk<0,1,512>>>) {
        %extracted = tensor.extract %arg0[%arg2, %arg6] : tensor<4x3x!TFHE.glwe<sk<0,1,512>>>
        %extracted_0 = tensor.extract %arg1[%arg6, %arg4] : tensor<3x2xi3>
        %extracted_1 = tensor.extract %arg7[%arg2, %arg4] : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
        %4 = arith.extsi %extracted_0 : i3 to i64
        %5 = "TFHE.mul_glwe_int"(%extracted, %4) : (!TFHE.glwe<sk<0,1,512>>, i64) -> !TFHE.glwe<sk<0,1,512>>
        %6 = "TFHE.add_glwe"(%extracted_1, %5) : (!TFHE.glwe<sk<0,1,512>>, !TFHE.glwe<sk<0,1,512>>) -> !TFHE.glwe<sk<0,1,512>>
        %inserted = tensor.insert %6 into %arg7[%arg2, %arg4] : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
        scf.yield %inserted : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
      }
      scf.yield %3 : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
    }
    scf.yield %2 : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
  }
  return %1 : tensor<4x2x!TFHE.glwe<sk<0,1,512>>>
}

In this parametrization, a single key with the ID 0 is used, with a single dimension and a polynomial of size 512.

The Concrete Dialect: Preparing bindings with a crypto library

In the next step of the pipeline, operations and types are lowered to the Concrete Dialect. This dialect provides operations, which are implemented by one of Concrete's backend libraries, but still abstracts from any technical details required for interaction with an actual library. The goal is to maintain a high-level representation with value-based semantics and actual operations instead of buffer semantics and library calls, while ensuring that all operations an effectively be lowered to a library call later in the pipeline. However, the abstract types from TFHE are already lowered to tensors of integers with a suitable shape that will hold the binary data of the encrypted values.

The result of the lowering of the example to the Concrete Dialect is shown below:

func.func @main(%arg0: tensor<4x3x513xi64>, %arg1: tensor<3x2xi3>) -> tensor<4x2x513xi64> {
  %c0 = arith.constant 0 : index
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c2 = arith.constant 2 : index
  %c3 = arith.constant 3 : index
  %generated = tensor.generate  {
  ^bb0(%arg2: index, %arg3: index, %arg4: index):
    %c0_i64 = arith.constant 0 : i64
    tensor.yield %c0_i64 : i64
  } : tensor<4x2x513xi64>
  %0 = scf.for %arg2 = %c0 to %c4 step %c1 iter_args(%arg3 = %generated) -> (tensor<4x2x513xi64>) {
    %1 = scf.for %arg4 = %c0 to %c2 step %c1 iter_args(%arg5 = %arg3) -> (tensor<4x2x513xi64>) {
      %2 = scf.for %arg6 = %c0 to %c3 step %c1 iter_args(%arg7 = %arg5) -> (tensor<4x2x513xi64>) {
        %extracted_slice = tensor.extract_slice %arg0[%arg2, %arg6, 0] [1, 1, 513] [1, 1, 1] : tensor<4x3x513xi64> to tensor<513xi64>
        %extracted = tensor.extract %arg1[%arg6, %arg4] : tensor<3x2xi3>
        %extracted_slice_0 = tensor.extract_slice %arg7[%arg2, %arg4, 0] [1, 1, 513] [1, 1, 1] : tensor<4x2x513xi64> to tensor<513xi64>
        %3 = arith.extsi %extracted : i3 to i64
        %4 = "Concrete.mul_cleartext_lwe_tensor"(%extracted_slice, %3) : (tensor<513xi64>, i64) -> tensor<513xi64>
        %5 = "Concrete.add_lwe_tensor"(%extracted_slice_0, %4) : (tensor<513xi64>, tensor<513xi64>) -> tensor<513xi64>
        %inserted_slice = tensor.insert_slice %5 into %arg7[%arg2, %arg4, 0] [1, 1, 513] [1, 1, 1] : tensor<513xi64> into tensor<4x2x513xi64>
        scf.yield %inserted_slice : tensor<4x2x513xi64>
      }
      scf.yield %2 : tensor<4x2x513xi64>
    }
    scf.yield %1 : tensor<4x2x513xi64>
  }
  return %0 : tensor<4x2x513xi64>
}

Bufferization and emitting library calls

The remaining stages of the pipeline are rather technical. Before any binding to an actual Concrete backend library, the compiler first invokes MLIR's bufferization infrastructure to convert the value-based IR into an IR with buffer semantics. In particular, this means that keys and encrypted values are no longer abstract values in a mathematical sense, but values backed by a memory location that holds the actual data. This form of IR is then suitable for a pass emitting actual library calls that implement the corresponding operations from the Concrete Dialect for a specific backend.

The result for the example is given below:

func.func @main(%arg0: memref<4x3x513xi64, strided<[?, ?, ?], offset: ?>>, %arg1: memref<3x2xi3, strided<[?, ?], offset: ?>>, %arg2: !Concrete.context) -> memref<4x2x513xi64> {
  %c0_i64 = arith.constant 0 : i64
  call @_dfr_start(%c0_i64, %arg2) : (i64, !Concrete.context) -> ()
  %c0 = arith.constant 0 : index
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c2 = arith.constant 2 : index
  %c513 = arith.constant 513 : index
  %c0_i64_0 = arith.constant 0 : i64
  %c3 = arith.constant 3 : index
  %alloc = memref.alloc() {alignment = 64 : i64} : memref<4x2x513xi64>
  scf.for %arg3 = %c0 to %c4 step %c1 {
    scf.for %arg4 = %c0 to %c2 step %c1 {
      scf.for %arg5 = %c0 to %c513 step %c1 {
        memref.store %c0_i64_0, %alloc[%arg3, %arg4, %arg5] : memref<4x2x513xi64>
      }
    }
  }
  scf.for %arg3 = %c0 to %c4 step %c1 {
    scf.for %arg4 = %c0 to %c2 step %c1 {
      %subview = memref.subview %alloc[%arg3, %arg4, 0] [1, 1, 513] [1, 1, 1] : memref<4x2x513xi64> to memref<513xi64, strided<[1], offset: ?>>
      scf.for %arg5 = %c0 to %c3 step %c1 {
        %subview_1 = memref.subview %arg0[%arg3, %arg5, 0] [1, 1, 513] [1, 1, 1] : memref<4x3x513xi64, strided<[?, ?, ?], offset: ?>> to memref<513xi64, strided<[?], offset: ?>>
        %0 = memref.load %arg1[%arg5, %arg4] : memref<3x2xi3, strided<[?, ?], offset: ?>>
        %1 = arith.extsi %0 : i3 to i64
        %alloc_2 = memref.alloc() {alignment = 64 : i64} : memref<513xi64>
        %cast = memref.cast %alloc_2 : memref<513xi64> to memref<?xi64, #map>
        %cast_3 = memref.cast %subview_1 : memref<513xi64, strided<[?], offset: ?>> to memref<?xi64, #map>
        func.call @memref_mul_cleartext_lwe_ciphertext_u64(%cast, %cast_3, %1) : (memref<?xi64, #map>, memref<?xi64, #map>, i64) -> ()
        %alloc_4 = memref.alloc() {alignment = 64 : i64} : memref<513xi64>
        %cast_5 = memref.cast %alloc_4 : memref<513xi64> to memref<?xi64, #map>
        %cast_6 = memref.cast %subview : memref<513xi64, strided<[1], offset: ?>> to memref<?xi64, #map>
        %cast_7 = memref.cast %alloc_2 : memref<513xi64> to memref<?xi64, #map>
        func.call @memref_add_lwe_ciphertexts_u64(%cast_5, %cast_6, %cast_7) : (memref<?xi64, #map>, memref<?xi64, #map>, memref<?xi64, #map>) -> ()
        memref.dealloc %alloc_2 : memref<513xi64>
        memref.copy %alloc_4, %subview : memref<513xi64> to memref<513xi64, strided<[1], offset: ?>>
        memref.dealloc %alloc_4 : memref<513xi64>
      }
    }
  }
  call @_dfr_stop(%c0_i64) : (i64) -> ()
  return %alloc : memref<4x2x513xi64>
}

At this stage, the IR is only composed of operations from builtin Dialects and thus amenable to lowering to LLVM-IR using the lowering passes provided by MLIR.

Tracing dialect

Tracing dialect A dialect to print program values at runtime.

Operation definition

`Tracing.trace_ciphertext` (::mlir::concretelang::Tracing::TraceCiphertextOp)

Prints a ciphertext.

Attributes:

Attribute

MLIR Type

Description

Operands:

Operand

Description

`Tracing.trace_message` (::mlir::concretelang::Tracing::TraceMessageOp)

Prints a message.

Attributes:

Attribute

MLIR Type

Description

`Tracing.trace_plaintext` (::mlir::concretelang::Tracing::TracePlaintextOp)

Prints a plaintext.

Attributes:

Attribute

MLIR Type

Description

Operands:

Operand

Description

SDFG dialect

Dialect for the construction of static data flow graphs A dialect for the construction of static data flow graphs. The data flow graph is composed of a set of processes, connected through data streams. Special streams allow for data to be injected into and to be retrieved from the data flow graph.

Operation definition

`SDFG.get` (::mlir::concretelang::SDFG::Get)

Retrieves a data element from a stream

Retrieves a single data element from the specified stream (i.e., an instance of the element type of the stream).

Example:

"SDFG.get" (%stream) : (!SDFG.stream<1024xi64>) -> (tensor<1024xi64>)

Operands:

Operand

Description

stream

An SDFG data stream

Results:

Result

Description

data

any type

`SDFG.init` (::mlir::concretelang::SDFG::Init)

Initializes the streaming framework

Initializes the streaming framework. This operation must be performed before control reaches any other operation from the dialect.

Example:

"SDFG.init" : () -> !SDFG.dfg

Results:

Result

Description

«unnamed»

An SDFG data flow graph

`SDFG.make_process` (::mlir::concretelang::SDFG::MakeProcess)

Creates a new SDFG process

Creates a new SDFG process and connects it to the input and output streams.

Example:

%in0 = "SDFG.make_stream" { type = #SDFG.stream_kind<host_to_device> }(%dfg) : (!SDFG.dfg) -> !SDFG.stream<tensor<1024xi64>>
%in1 = "SDFG.make_stream" { type = #SDFG.stream_kind<host_to_device> }(%dfg) : (!SDFG.dfg) -> !SDFG.stream<tensor<1024xi64>>
%out = "SDFG.make_stream" { type = #SDFG.stream_kind<device_to_host> }(%dfg) : (!SDFG.dfg) -> !SDFG.stream<tensor<1024xi64>>
"SDFG.make_process" { type = #SDFG.process_kind<add_eint> }(%dfg, %in0, %in1, %out) :
  (!SDFG.dfg, !SDFG.stream<tensor<1024xi64>>, !SDFG.stream<tensor<1024xi64>>, !SDFG.stream<tensor<1024xi64>>) -> ()

Attributes:

Attribute

MLIR Type

Description

type

::mlir::concretelang::SDFG::ProcessKindAttr

Process kind

Operands:

Operand

Description

dfg

An SDFG data flow graph

streams

An SDFG data stream

`SDFG.make_stream` (::mlir::concretelang::SDFG::MakeStream)

Returns a new SDFG stream

Returns a new SDFG stream, transporting data either between processes on the device, from the host to the device or from the device to the host. All streams are typed, allowing data to be read / written through SDFG.get and SDFG.put only using the stream's type.

Example:

"SDFG.make_stream" { name = "stream", type = #SDFG.stream_kind<host_to_device> }(%dfg)
  : (!SDFG.dfg) -> !SDFG.stream<tensor<1024xi64>>

Attributes:

Attribute

MLIR Type

Description

name

::mlir::StringAttr

string attribute

type

::mlir::concretelang::SDFG::StreamKindAttr

Stream kind

Operands:

Operand

Description

dfg

An SDFG data flow graph

Results:

Result

Description

«unnamed»

An SDFG data stream

`SDFG.put` (::mlir::concretelang::SDFG::Put)

Writes a data element to a stream

Writes the input operand to the specified stream. The operand's type must meet the element type of the stream.

Example:

"SDFG.put" (%stream, %data) : (!SDFG.stream<1024xi64>, tensor<1024xi64>) -> ()

Operands:

Operand

Description

stream

An SDFG data stream

data

any type

`SDFG.shutdown` (::mlir::concretelang::SDFG::Shutdown)

Shuts down the streaming framework

Shuts down the streaming framework. This operation must be performed after any other operation from the dialect.

Example:

"SDFG.shutdown" (%dfg) : !SDFG.dfg

Operands:

Operand

Description

dfg

An SDFG data flow graph

`SDFG.start` (::mlir::concretelang::SDFG::Start)

Finalizes the creation of an SDFG and starts execution of its processes

Finalizes the creation of an SDFG and starts execution of its processes. Any creation of streams and processes must take place before control reaches this operation.

Example:

"SDFG.start"(%dfg) : !SDFG.dfg

Operands:

Operand

Description

dfg

An SDFG data flow graph

Attribute definition

ProcessKindAttr

Process kind

Syntax:

#SDFG.process_kind<
  ::mlir::concretelang::SDFG::ProcessKind   # value
>

Parameters:

Parameter

C++ type

Description

value

::mlir::concretelang::SDFG::ProcessKind

an enum of type ProcessKind

StreamKindAttr

Stream kind

Syntax:

#SDFG.stream_kind<
  ::mlir::concretelang::SDFG::StreamKind   # value
>

Parameters:

Parameter

C++ type

Description

value

::mlir::concretelang::SDFG::StreamKind

an enum of type StreamKind

Type definition

DFGType

An SDFG data flow graph

Syntax: !SDFG.dfg

A handle to an SDFG data flow graph

StreamType

An SDFG data stream

An SDFG stream to connect SDFG processes.

Parameters:

Parameter

C++ type

Description

elementType

Type

Call FHE circuits from other languages

After doing a compilation, we end up with a couple of artifacts, including crypto parameters and a binary file containing the executable circuit. In order to be able to encrypt and run the circuit properly, we need to know how to interpret these artifacts, and there are a couple of utility functions which can be used to load them. These utility functions can be accessed through a variety of languages, including Python and C++.

Demo

We will use a really simple example for a demo, but the same steps can be done for any other circuit. example.mlir will contain the MLIR below:

func.func @main(%arg0: tensor<4x4x!FHE.eint<6>>, %arg1: tensor<4x2xi7>) -> tensor<4x2x!FHE.eint<6>> {
   %0 = "FHELinalg.matmul_eint_int"(%arg0, %arg1): (tensor<4x4x!FHE.eint<6>>, tensor<4x2xi7>) -> (tensor<4x2x!FHE.eint<6>>)
   %tlu = arith.constant dense<[40, 13, 20, 62, 47, 41, 46, 30, 59, 58, 17, 4, 34, 44, 49, 5, 10, 63, 18, 21, 33, 45, 7, 14, 24, 53, 56, 3, 22, 29, 1, 39, 48, 32, 38, 28, 15, 12, 52, 35, 42, 11, 6, 43, 0, 16, 27, 9, 31, 51, 36, 37, 55, 57, 54, 2, 8, 25, 50, 23, 61, 60, 26, 19]> : tensor<64xi64>
   %result = "FHELinalg.apply_lookup_table"(%0, %tlu): (tensor<4x2x!FHE.eint<6>>, tensor<64xi64>) -> (tensor<4x2x!FHE.eint<6>>)
   return %result: tensor<4x2x!FHE.eint<6>>
}

You can use the concretecompiler binary to compile this MLIR program. Same can be done with concrete-python, as we only need the compilation artifacts at the end.

$ concretecompiler --action=compile -o python-demo example.mlir

You should be able to see artifacts listed in the python-demo directory

$ ls python-demo/
client_parameters.concrete.params.json  compilation_feedback.json  fhecircuit-client.h  sharedlib.so  staticlib.a

Now we want to use the Python bindings in order to call the compiled circuit.

from concrete.compiler import (ClientSupport, LambdaArgument, LibrarySupport)

The main struct to manage compilation artifacts is LibrarySupport. You will have to create one with the path you used during compilation, then load the result of the compilation

lib_support = LibrarySupport.new("/path/to/your/python-demo/")
compilation_result = lib_support.reload()

Using the compilation result, you can load the server lambda (the entrypoint to the executable compiled circuit) as well as the client parameters (containing crypto parameters)

server_lambda = lib_support.load_server_lambda(compilation_result)
client_params = lib_support.load_client_parameters(compilation_result)

The client parameters will serve the client to generate keys and encrypt arguments for the circuit

client_support = ClientSupport.new()
key_set = client_support.key_set(client_params)
args = [
	LambdaArgument.from_tensor_u8([1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4], [4, 4]),
	LambdaArgument.from_tensor_u8([1, 2, 1, 2, 1, 2, 1, 2], [4, 2])
]
encrypted_args = client_support.encrypt_arguments(client_params, key_set, args)

Only evaluation keys are required for the execution of the circuit. You can execute the circuit on the encrypted arguments via server_lambda_call

eval_keys = key_set.get_evaluation_keys()
encrypted_result = lib_support.server_call(server_lambda, encrypted_args, eval_keys)

At this point you have the encrypted result and can decrypt it using the keyset which holds the secret key

result_arg = client_support.decrypt_result(client_params, key_set, encrypted_result)
print("result tensor dims: {}".format(result_arg.n_values()))
print("result tensor data: {}".format(result_arg.get_values()))

There is also a couple of tests in test_compilation.py that can show how to both compile and run a circuit between a client and server using serialization.

FHE dialect

High Level Fully Homomorphic Encryption dialect A dialect for representation of high level operation on fully homomorphic ciphertext.

Operation definition

`FHE.add_eint_int` (::mlir::concretelang::FHE::AddEintIntOp)

Adds an encrypted integer and a clear integer

The clear integer must have at most one more bit than the encrypted integer and the result must have the same width and the same signedness as the encrypted integer.

Example:

// ok
"FHE.add_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.eint<2>
"FHE.add_eint_int"(%a, %i) : (!FHE.esint<2>, i3) -> !FHE.esint<2>

// error
"FHE.add_eint_int"(%a, %i) : (!FHE.eint<2>, i4) -> !FHE.eint<2>
"FHE.add_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.eint<3>
"FHE.add_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.esint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

b

integer

Results:

Result

Description

«unnamed»

`FHE.add_eint` (::mlir::concretelang::FHE::AddEintOp)

Adds two encrypted integers

The encrypted integers and the result must have the same width and the same signedness.

Example:

// ok
"FHE.add_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<2>)
"FHE.add_eint"(%a, %b): (!FHE.esint<2>, !FHE.esint<2>) -> (!FHE.esint<2>)

// error
"FHE.add_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<3>) -> (!FHE.eint<2>)
"FHE.add_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<3>)
"FHE.add_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.esint<2>)
"FHE.add_eint"(%a, %b): (!FHE.esint<2>, !FHE.eint<2>) -> (!FHE.eint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

b

Results:

Result

Description

«unnamed»

`FHE.apply_lookup_table` (::mlir::concretelang::FHE::ApplyLookupTableEintOp)

Applies a clear lookup table to an encrypted integer

The width of the result can be different than the width of the operand. The lookup table must be a tensor of size 2^p where p is the width of the encrypted integer.

Example:

// ok
"FHE.apply_lookup_table"(%a, %lut): (!FHE.eint<2>, tensor<4xi64>) -> (!FHE.eint<2>)
"FHE.apply_lookup_table"(%a, %lut): (!FHE.eint<2>, tensor<4xi64>) -> (!FHE.eint<3>)
"FHE.apply_lookup_table"(%a, %lut): (!FHE.eint<3>, tensor<4xi64>) -> (!FHE.eint<2>)

// error
"FHE.apply_lookup_table"(%a, %lut): (!FHE.eint<2>, tensor<8xi64>) -> (!FHE.eint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

lut

tensor of integer values

Results:

Result

Description

«unnamed»

`FHE.and` (::mlir::concretelang::FHE::BoolAndOp)

Applies an AND gate to two encrypted boolean values

Example:

"FHE.and"(%a, %b): (!FHE.ebool, !FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

left

An encrypted boolean

right

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.nand` (::mlir::concretelang::FHE::BoolNandOp)

Applies a NAND gate to two encrypted boolean values

Example:

"FHE.nand"(%a, %b): (!FHE.ebool, !FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

left

An encrypted boolean

right

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.not` (::mlir::concretelang::FHE::BoolNotOp)

Applies a NOT gate to an encrypted boolean value

Example:

"FHE.not"(%a): (!FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

value

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.or` (::mlir::concretelang::FHE::BoolOrOp)

Applies an OR gate to two encrypted boolean values

Example:

"FHE.or"(%a, %b): (!FHE.ebool, !FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

left

An encrypted boolean

right

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.xor` (::mlir::concretelang::FHE::BoolXorOp)

Applies an XOR gate to two encrypted boolean values

Example:

"FHE.xor"(%a, %b): (!FHE.ebool, !FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

left

An encrypted boolean

right

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.from_bool` (::mlir::concretelang::FHE::FromBoolOp)

Cast a boolean to an unsigned integer

Examples:

"FHE.from_bool"(%x) : (!FHE.ebool) -> !FHE.eint<1>
"FHE.from_bool"(%x) : (!FHE.ebool) -> !FHE.eint<2>
"FHE.from_bool"(%x) : (!FHE.ebool) -> !FHE.eint<4>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted unsigned integer

`FHE.gen_gate` (::mlir::concretelang::FHE::GenGateOp)

Applies a truth table based on two boolean inputs

Truth table must be a tensor of four boolean values.

Example:

// ok
"FHE.gen_gate"(%a, %b, %ttable): (!FHE.ebool, !FHE.ebool, tensor<4xi64>) -> (!FHE.ebool)

// error
"FHE.gen_gate"(%a, %b, %ttable): (!FHE.ebool, !FHE.ebool, tensor<7xi64>) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

left

An encrypted boolean

right

An encrypted boolean

truth_table

tensor of integer values

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.lsb` (::mlir::concretelang::FHE::LsbEintOp)

Extract the lowest significant bit at a given precision.

This operation extracts the lsb of a ciphertext in a specific precision.

Extracting the lsb with the smallest precision:

 // Checking if even or odd
 %even = "FHE.lsb"(%a): (!FHE.eint<4>) -> (!FHE.eint<1>)

Usually when you extract the lsb bit, you also need to extract the next one.
In that case you first need to clear the first lsb of the input to be able to reduce its precision and extract the next one.
To be able to clear the lsb just extracted, you can get it in the original precision.

Example:
```mlir
 // Extracting the first lsb with original precision
 %lsb_0 = "FHE.lsb"(%input): (!FHE.eint<4>) -> (!FHE.eint<4>)
 // Clearing the first lsb from original input
 %input_lsb0_cleared = "FHE.sub_eint"(%input, %lsb_0) : (!FHE.eint<4>, !FHE.eint<4>) -> (!FHE.eint<4>)
 // Reducing the precision of the input
 %input_3b = "FHE.reinterpret_precision(%input) : (!FHE.eint<4>) -> !FHE.eint<3>
 // Now, we can do it again with the second lsb
 %lsb_1 = "FHE.lsb"(%input_3b): (!FHE.eint<3>) -> (!FHE.eint<3>)
 ...
 // later if you need %b_lsb at same position as in the input
 %lsb_1_at_input_position = "FHE.reinterpret_precision(%b_lsb)" : (!FHE.eint<3>) -> !FHE.eint<4>
 // that way you can recombine the extracted bits
 %input_mod_4 = "FHE.add_eint"(%lsb_0, %lsb_1_at_input_position) : (!FHE.eint<4>, !FHE.eint<4>) -> (!FHE.eint<4>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

«unnamed»

`FHE.max_eint` (::mlir::concretelang::FHE::MaxEintOp)

Retrieve the maximum of two encrypted integers.

Retrieve the maximum of two encrypted integers using the formula, 'max(x, y) == max(x - y, 0) + y'. The input and output types should be the same.

If `x - y`` inside the max overflows or underflows, the behavior is undefined. To support the full range, you should increase the bit-width by 1 manually.

Example:

// ok
"FHE.max_eint"(%x, %y) : (!FHE.eint<2>, !FHE.eint<2>) -> !FHE.eint<2>
"FHE.max_eint"(%x, %y) : (!FHE.esint<3>, !FHE.esint<3>) -> !FHE.esint<3>

// error
"FHE.max_eint"(%x, %y) : (!FHE.eint<2>, !FHE.eint<3>) -> !FHE.eint<2>
"FHE.max_eint"(%x, %y) : (!FHE.eint<2>, !FHE.eint<2>) -> !FHE.esint<2>
"FHE.max_eint"(%x, %y) : (!FHE.esint<2>, !FHE.eint<2>) -> !FHE.eint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

x

y

Results:

Result

Description

«unnamed»

`FHE.mul_eint_int` (::mlir::concretelang::FHE::MulEintIntOp)

Multiply an encrypted integer with a clear integer

The clear integer must have one more bit than the encrypted integer and the result must have the same width and the same signedness as the encrypted integer.

Example:

// ok
"FHE.mul_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.eint<2>
"FHE.mul_eint_int"(%a, %i) : (!FHE.esint<2>, i3) -> !FHE.esint<2>

// error
"FHE.mul_eint_int"(%a, %i) : (!FHE.eint<2>, i4) -> !FHE.eint<2>
"FHE.mul_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.eint<3>
"FHE.mul_eint_int"(%a, %i) : (!FHE.eint<2>, i3) -> !FHE.esint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

b

integer

Results:

Result

Description

«unnamed»

`FHE.mul_eint` (::mlir::concretelang::FHE::MulEintOp)

Multiplies two encrypted integers

The encrypted integers and the result must have the same width and signedness. Also, due to the current implementation, one supplementary bit of width must be provided, in addition to the number of bits needed to encode the largest output value.

Example:

// ok
"FHE.mul_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<2>)
"FHE.mul_eint"(%a, %b): (!FHE.eint<3>, !FHE.eint<3>) -> (!FHE.eint<3>)
"FHE.mul_eint"(%a, %b): (!FHE.esint<3>, !FHE.esint<3>) -> (!FHE.esint<3>)

// error
"FHE.mul_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<3>) -> (!FHE.eint<2>)
"FHE.mul_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<3>)
"FHE.mul_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.esint<2>)
"FHE.mul_eint"(%a, %b): (!FHE.esint<2>, !FHE.eint<2>) -> (!FHE.eint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

rhs

lhs

Results:

Result

Description

«unnamed»

`FHE.mux` (::mlir::concretelang::FHE::MuxOp)

Multiplexer for two encrypted boolean inputs, based on an encrypted condition

Example:

"FHE.mux"(%cond, %c1, %c2): (!FHE.ebool, !FHE.ebool, !FHE.ebool) -> (!FHE.ebool)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

cond

An encrypted boolean

c1

An encrypted boolean

c2

An encrypted boolean

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.neg_eint` (::mlir::concretelang::FHE::NegEintOp)

Negates an encrypted integer

The result must have the same width and the same signedness as the encrypted integer.

Example:

// ok
"FHE.neg_eint"(%a): (!FHE.eint<2>) -> (!FHE.eint<2>)
"FHE.neg_eint"(%a): (!FHE.esint<2>) -> (!FHE.esint<2>)

// error
"FHE.neg_eint"(%a): (!FHE.eint<2>) -> (!FHE.eint<3>)
"FHE.neg_eint"(%a): (!FHE.eint<2>) -> (!FHE.esint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

Results:

Result

Description

«unnamed»

`FHE.reinterpret_precision` (::mlir::concretelang::FHE::ReinterpretPrecisionEintOp)

Reinterpret the ciphertext with a different precision.

Changing the precision of a ciphertext. It changes both the precision, the value, and in certain cases the correctness of the ciphertext.

Changing to - a bigger precision is always safe. This is equivalent to a shift left for the value. - a smaller precision is only safe if you clear the lowest bits that are discarded. If not, you can assume small errors on the next TLU. This is equivalent to a shift right for the value.

Example:

 // assuming %a is stored as 4bits but can be stored with only 2bits
 // we can reduce its storage precision
 %shifted_a = "FHE.mul_eint_int"(%a, %c_4): (!FHE.eint<4>) -> (!FHE.eint<4>)
 %a_small_precision = "FHE.reinterpret_precision"(%shifted_a, %lsb) : (!FHE.eint<4>) -> (!FHE.eint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

«unnamed»

`FHE.round` (::mlir::concretelang::FHE::RoundEintOp)

Rounds a ciphertext to a smaller precision.

Assuming a ciphertext whose message is implemented over p bits, this operation rounds it to fit to q bits with p>q.

Example:

 // ok
 "FHE.round"(%a): (!FHE.eint<6>) -> (!FHE.eint<5>)
 "FHE.round"(%a): (!FHE.eint<5>) -> (!FHE.eint<3>)
 "FHE.round"(%a): (!FHE.eint<3>) -> (!FHE.eint<2>)
 "FHE.round"(%a): (!FHE.esint<3>) -> (!FHE.esint<2>)

// error
 "FHE.round"(%a): (!FHE.eint<6>) -> (!FHE.eint<6>)
 "FHE.round"(%a): (!FHE.eint<4>) -> (!FHE.eint<5>)
 "FHE.round"(%a): (!FHE.eint<4>) -> (!FHE.esint<5>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

«unnamed»

`FHE.sub_eint_int` (::mlir::concretelang::FHE::SubEintIntOp)

Subtract a clear integer from an encrypted integer

The clear integer must have one more bit than the encrypted integer and the result must have the same width and the same signedness as the encrypted integer.

Example:

// ok
"FHE.sub_eint_int"(%i, %a) : (!FHE.eint<2>, i3) -> !FHE.eint<2>
"FHE.sub_eint_int"(%i, %a) : (!FHE.esint<2>, i3) -> !FHE.esint<2>

// error
"FHE.sub_eint_int"(%i, %a) : (!FHE.eint<2>, i4) -> !FHE.eint<2>
"FHE.sub_eint_int"(%i, %a) : (!FHE.eint<2>, i3) -> !FHE.eint<3>
"FHE.sub_eint_int"(%i, %a) : (!FHE.eint<2>, i3) -> !FHE.esint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

b

integer

Results:

Result

Description

«unnamed»

`FHE.sub_eint` (::mlir::concretelang::FHE::SubEintOp)

Subtract an encrypted integer from an encrypted integer

The encrypted integers and the result must have the same width and the same signedness.

Example:

// ok
"FHE.sub_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<2>)
"FHE.sub_eint"(%a, %b): (!FHE.esint<2>, !FHE.esint<2>) -> (!FHE.esint<2>)

// error
"FHE.sub_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<3>) -> (!FHE.eint<2>)
"FHE.sub_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.eint<3>)
"FHE.sub_eint"(%a, %b): (!FHE.eint<2>, !FHE.esint<2>) -> (!FHE.esint<2>)
"FHE.sub_eint"(%a, %b): (!FHE.eint<2>, !FHE.eint<2>) -> (!FHE.esint<2>)

Traits: AlwaysSpeculatableImplTrait

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

b

Results:

Result

Description

«unnamed»

`FHE.sub_int_eint` (::mlir::concretelang::FHE::SubIntEintOp)

Subtract an encrypted integer from a clear integer

The clear integer must have one more bit than the encrypted integer and the result must have the same width and the same signedness as the encrypted integer.

Example:

// ok
"FHE.sub_int_eint"(%i, %a) : (i3, !FHE.eint<2>) -> !FHE.eint<2>
"FHE.sub_int_eint"(%i, %a) : (i3, !FHE.esint<2>) -> !FHE.esint<2>

// error
"FHE.sub_int_eint"(%i, %a) : (i4, !FHE.eint<2>) -> !FHE.eint<2>
"FHE.sub_int_eint"(%i, %a) : (i3, !FHE.eint<2>) -> !FHE.eint<3>
"FHE.sub_int_eint"(%i, %a) : (i3, !FHE.eint<2>) -> !FHE.esint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryIntEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

integer

b

Results:

Result

Description

«unnamed»

`FHE.to_bool` (::mlir::concretelang::FHE::ToBoolOp)

Cast an unsigned integer to a boolean

The input must be of width one or two. Two being the current representation of an encrypted boolean, leaving one bit for the carry.

Examples:

// ok
"FHE.to_bool"(%x) : (!FHE.eint<1>) -> !FHE.ebool
"FHE.to_bool"(%x) : (!FHE.eint<2>) -> !FHE.ebool

// error
"FHE.to_bool"(%x) : (!FHE.eint<3>) -> !FHE.ebool

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

An encrypted unsigned integer

Results:

Result

Description

«unnamed»

An encrypted boolean

`FHE.to_signed` (::mlir::concretelang::FHE::ToSignedOp)

Cast an unsigned integer to a signed one

The result must have the same width as the input.

The behavior is undefined on overflow/underflow.

Examples:

// ok
"FHE.to_signed"(%x) : (!FHE.eint<2>) -> !FHE.esint<2>

// error
"FHE.to_signed"(%x) : (!FHE.eint<2>) -> !FHE.esint<3>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

An encrypted unsigned integer

Results:

Result

Description

«unnamed»

An encrypted signed integer

`FHE.to_unsigned` (::mlir::concretelang::FHE::ToUnsignedOp)

Cast a signed integer to an unsigned one

The result must have the same width as the input.

The behavior is undefined on overflow/underflow.

Examples:

// ok
"FHE.to_unsigned"(%x) : (!FHE.esint<2>) -> !FHE.eint<2>

// error
"FHE.to_unsigned"(%x) : (!FHE.esint<2>) -> !FHE.eint<3>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

An encrypted signed integer

Results:

Result

Description

«unnamed»

An encrypted unsigned integer

`FHE.zero` (::mlir::concretelang::FHE::ZeroEintOp)

Returns a trivial encrypted integer of 0

Example:

"FHE.zero"() : () -> !FHE.eint<2>
"FHE.zero"() : () -> !FHE.esint<2>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results:

Result

Description

out

`FHE.zero_tensor` (::mlir::concretelang::FHE::ZeroTensorOp)

Creates a new tensor with all elements initialized to an encrypted zero.

Creates a new tensor with the shape specified in the result type and initializes its elements with an encrypted zero.

Example:

%tensor = "FHE.zero_tensor"() : () -> tensor<5x!FHE.eint<4>>
%tensor = "FHE.zero_tensor"() : () -> tensor<5x!FHE.esint<4>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results:

Result

Description

tensor

Type definition

EncryptedBooleanType

An encrypted boolean

Syntax: !FHE.ebool

An encrypted boolean.

EncryptedSignedIntegerType

An encrypted signed integer

An encrypted signed integer with width bits to performs FHE Operations.

Examples:

!FHE.esint<7>
!FHE.esint<6>

Parameters:

Parameter

C++ type

Description

width

unsigned

EncryptedUnsignedIntegerType

An encrypted unsigned integer

An encrypted unsigned integer with width bits to performs FHE Operations.

Examples:

!FHE.eint<7>
!FHE.eint<6>

Parameters:

Parameter

C++ type

Description

width

unsigned

TFHE dialect

High Level Fully Homomorphic Encryption dialect A dialect for representation of high level operation on fully homomorphic ciphertext.

Operation definition

`TFHE.batched_add_glwe_cst_int` (::mlir::concretelang::TFHE::ABatchedAddGLWECstIntOp)

Batched version of AddGLWEIntOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertext

A GLWE ciphertext

plaintexts

1D tensor of integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_add_glwe_int_cst` (::mlir::concretelang::TFHE::ABatchedAddGLWEIntCstOp)

Batched version of AddGLWEIntOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

plaintext

integer

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_add_glwe_int` (::mlir::concretelang::TFHE::ABatchedAddGLWEIntOp)

Batched version of AddGLWEIntOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

plaintexts

1D tensor of integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_add_glwe` (::mlir::concretelang::TFHE::ABatchedAddGLWEOp)

Batched version of AddGLWEOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts_a

1D tensor of A GLWE ciphertext values

ciphertexts_b

1D tensor of A GLWE ciphertext values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.add_glwe_int` (::mlir::concretelang::TFHE::AddGLWEIntOp)

Returns the sum of a clear integer and an lwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

A GLWE ciphertext

b

integer

Results:

Result

Description

«unnamed»

A GLWE ciphertext

`TFHE.add_glwe` (::mlir::concretelang::TFHE::AddGLWEOp)

Returns the sum of two lwe ciphertexts

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

A GLWE ciphertext

b

A GLWE ciphertext

Results:

Result

Description

«unnamed»

A GLWE ciphertext

`TFHE.batched_bootstrap_glwe` (::mlir::concretelang::TFHE::BatchedBootstrapGLWEOp)

Batched version of KeySwitchGLWEOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

key

::mlir::concretelang::TFHE::GLWEBootstrapKeyAttr

An attribute representing bootstrap key.

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_keyswitch_glwe` (::mlir::concretelang::TFHE::BatchedKeySwitchGLWEOp)

Batched version of KeySwitchGLWEOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

key

::mlir::concretelang::TFHE::GLWEKeyswitchKeyAttr

An attribute representing keyswitch key.

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_mapped_bootstrap_glwe` (::mlir::concretelang::TFHE::BatchedMappedBootstrapGLWEOp)

Batched version of KeySwitchGLWEOp which also batches the lookup table

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

key

::mlir::concretelang::TFHE::GLWEBootstrapKeyAttr

An attribute representing bootstrap key.

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

lookup_table

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_mul_glwe_cst_int` (::mlir::concretelang::TFHE::BatchedMulGLWECstIntOp)

Batched version of MulGLWECstIntOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertext

A GLWE ciphertext

cleartexts

1D tensor of integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_mul_glwe_int_cst` (::mlir::concretelang::TFHE::BatchedMulGLWEIntCstOp)

Batched version of MulGLWEIntCstOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

cleartext

integer

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_mul_glwe_int` (::mlir::concretelang::TFHE::BatchedMulGLWEIntOp)

Batched version of MulGLWEIntOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

cleartexts

1D tensor of integer values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.batched_neg_glwe` (::mlir::concretelang::TFHE::BatchedNegGLWEOp)

Batched version of NegGLWEOp

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertexts

1D tensor of A GLWE ciphertext values

Results:

Result

Description

result

1D tensor of A GLWE ciphertext values

`TFHE.bootstrap_glwe` (::mlir::concretelang::TFHE::BootstrapGLWEOp)

Programmable bootstraping of a GLWE ciphertext with a lookup table

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

key

::mlir::concretelang::TFHE::GLWEBootstrapKeyAttr

An attribute representing bootstrap key.

Operands:

Operand

Description

ciphertext

A GLWE ciphertext

lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

A GLWE ciphertext

`TFHE.encode_expand_lut_for_bootstrap` (::mlir::concretelang::TFHE::EncodeExpandLutForBootstrapOp)

Encode and expand a lookup table so that it can be used for a bootstrap.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

outputBits

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

input_lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`TFHE.encode_lut_for_crt_woppbs` (::mlir::concretelang::TFHE::EncodeLutForCrtWopPBSOp)

Encode and expand a lookup table so that it can be used for a wop pbs.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

crtBits

::mlir::ArrayAttr

64-bit integer array attribute

modulusProduct

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

input_lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`TFHE.encode_plaintext_with_crt` (::mlir::concretelang::TFHE::EncodePlaintextWithCrtOp)

Encodes a plaintext by decomposing it on a crt basis.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

mods

::mlir::ArrayAttr

64-bit integer array attribute

modsProd

::mlir::IntegerAttr

64-bit signless integer attribute

Operands:

Operand

Description

input

64-bit signless integer

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`TFHE.keyswitch_glwe` (::mlir::concretelang::TFHE::KeySwitchGLWEOp)

Change the encryption parameters of a glwe ciphertext by applying a keyswitch

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

key

::mlir::concretelang::TFHE::GLWEKeyswitchKeyAttr

An attribute representing keyswitch key.

Operands:

Operand

Description

ciphertext

A GLWE ciphertext

Results:

Result

Description

result

A GLWE ciphertext

`TFHE.mul_glwe_int` (::mlir::concretelang::TFHE::MulGLWEIntOp)

Returns the product of a clear integer and an lwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

A GLWE ciphertext

b

integer

Results:

Result

Description

«unnamed»

A GLWE ciphertext

`TFHE.neg_glwe` (::mlir::concretelang::TFHE::NegGLWEOp)

Negates a glwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: BatchableOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

A GLWE ciphertext

Results:

Result

Description

«unnamed»

A GLWE ciphertext

`TFHE.sub_int_glwe` (::mlir::concretelang::TFHE::SubGLWEIntOp)

Substracts an integer and a GLWE ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

a

integer

b

A GLWE ciphertext

Results:

Result

Description

«unnamed»

A GLWE ciphertext

`TFHE.wop_pbs_glwe` (::mlir::concretelang::TFHE::WopPBSGLWEOp)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

ksk

::mlir::concretelang::TFHE::GLWEKeyswitchKeyAttr

An attribute representing keyswitch key.

bsk

::mlir::concretelang::TFHE::GLWEBootstrapKeyAttr

An attribute representing bootstrap key.

pksk

::mlir::concretelang::TFHE::GLWEPackingKeyswitchKeyAttr

An attribute representing Wop Pbs key.

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

cbsLevels

::mlir::IntegerAttr

32-bit signless integer attribute

cbsBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

ciphertexts

lookupTable

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

`TFHE.zero` (::mlir::concretelang::TFHE::ZeroGLWEOp)

Returns a trivial encryption of 0

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results:

Result

Description

out

A GLWE ciphertext

`TFHE.zero_tensor` (::mlir::concretelang::TFHE::ZeroTensorGLWEOp)

Returns a tensor containing trivial encryptions of 0

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results:

Result

Description

tensor

Attribute definition

GLWEBootstrapKeyAttr

An attribute representing bootstrap key.

Syntax:

#TFHE.bsk<
  mlir::concretelang::TFHE::GLWESecretKey,   # inputKey
  mlir::concretelang::TFHE::GLWESecretKey,   # outputKey
  int,   # polySize
  int,   # glweDim
  int,   # levels
  int,   # baseLog
  int   # index
>

Parameters:

Parameter

C++ type

Description

inputKey

mlir::concretelang::TFHE::GLWESecretKey

outputKey

mlir::concretelang::TFHE::GLWESecretKey

polySize

int

glweDim

int

levels

int

baseLog

int

index

int

GLWEKeyswitchKeyAttr

An attribute representing keyswitch key.

Syntax:

#TFHE.ksk<
  mlir::concretelang::TFHE::GLWESecretKey,   # inputKey
  mlir::concretelang::TFHE::GLWESecretKey,   # outputKey
  int,   # levels
  int,   # baseLog
  int   # index
>

Parameters:

Parameter

C++ type

Description

inputKey

mlir::concretelang::TFHE::GLWESecretKey

outputKey

mlir::concretelang::TFHE::GLWESecretKey

levels

int

baseLog

int

index

int

GLWEPackingKeyswitchKeyAttr

An attribute representing Wop Pbs key.

Syntax:

#TFHE.pksk<
  mlir::concretelang::TFHE::GLWESecretKey,   # inputKey
  mlir::concretelang::TFHE::GLWESecretKey,   # outputKey
  int,   # outputPolySize
  int,   # innerLweDim
  int,   # glweDim
  int,   # levels
  int,   # baseLog
  int   # index
>

Parameters:

Parameter

C++ type

Description

inputKey

mlir::concretelang::TFHE::GLWESecretKey

outputKey

mlir::concretelang::TFHE::GLWESecretKey

outputPolySize

int

innerLweDim

int

glweDim

int

levels

int

baseLog

int

index

int

Type definition

GLWECipherTextType

A GLWE ciphertext

An GLWE cipher text

Parameters:

Parameter

C++ type

Description

key

mlir::concretelang::TFHE::GLWESecretKey

API

Modules

concrete.compiler: Compiler submodule.
concrete.compiler.client_parameters: Client parameters.
concrete.compiler.client_support: Client support.
concrete.compiler.compilation_context: CompilationContext.
concrete.compiler.compilation_feedback: Compilation feedback.
concrete.compiler.compilation_options: CompilationOptions.
concrete.compiler.evaluation_keys: EvaluationKeys.
concrete.compiler.key_set: KeySet.
concrete.compiler.key_set_cache: KeySetCache.
concrete.compiler.lambda_argument: LambdaArgument.
concrete.compiler.library_compilation_result: LibraryCompilationResult.
concrete.compiler.library_lambda: LibraryLambda.
concrete.compiler.library_support: LibrarySupport.
concrete.compiler.parameter: Parameter.
concrete.compiler.public_arguments: PublicArguments.
concrete.compiler.public_result: PublicResult.
concrete.compiler.server_circuit: ServerCircuit.
concrete.compiler.server_program: ServerProgram.
concrete.compiler.simulated_value_decrypter: SimulatedValueDecrypter.
concrete.compiler.simulated_value_exporter: SimulatedValueExporter.
concrete.compiler.utils: Common utils for the compiler submodule.
concrete.compiler.value: Value.
concrete.compiler.value_decrypter: ValueDecrypter.
concrete.compiler.value_exporter: ValueExporter.
concrete.compiler.wrapper: Wrapper for native Cpp objects.
concrete.fhe: Concrete.
concrete.fhe.compilation: Glue the compilation process together.
concrete.fhe.compilation.artifacts: Declaration of DebugArtifacts class.
concrete.fhe.compilation.circuit: Declaration of Circuit class.
concrete.fhe.compilation.client: Declaration of Client class.
concrete.fhe.compilation.compiler: Declaration of Compiler class.
concrete.fhe.compilation.configuration: Declaration of Configuration class.
concrete.fhe.compilation.decorators: Declaration of circuit and compiler decorators.
concrete.fhe.compilation.keys: Declaration of Keys class.
concrete.fhe.compilation.module: Declaration of FheModule classes.
concrete.fhe.compilation.module_compiler: Declaration of MultiCompiler class.
concrete.fhe.compilation.server: Declaration of Server class.
concrete.fhe.compilation.specs: Declaration of ClientSpecs class.
concrete.fhe.compilation.utils: Declaration of various functions and constants related to compilation.
concrete.fhe.compilation.value: Declaration of Value class.
concrete.fhe.dtypes: Define available data types and their semantics.
concrete.fhe.dtypes.base: Declaration of BaseDataType abstract class.
concrete.fhe.dtypes.float: Declaration of Float class.
concrete.fhe.dtypes.integer: Declaration of Integer class.
concrete.fhe.dtypes.utils: Declaration of various functions and constants related to data types.
concrete.fhe.extensions: Provide additional features that are not present in numpy.
concrete.fhe.extensions.array: Declaration of array function, to simplify creation of encrypted arrays.
concrete.fhe.extensions.bits: Bit extraction extensions.
concrete.fhe.extensions.convolution: Tracing and evaluation of convolution.
concrete.fhe.extensions.hint: Declaration of hinting extensions, to provide more information to Concrete.
concrete.fhe.extensions.identity: Declaration of identity extension.
concrete.fhe.extensions.maxpool: Tracing and evaluation of maxpool.
concrete.fhe.extensions.multivariate: Declaration of multivariate extension.
concrete.fhe.extensions.ones: Declaration of ones and one functions, to simplify creation of encrypted ones.
concrete.fhe.extensions.relu: Declaration of relu extension.
concrete.fhe.extensions.round_bit_pattern: Declaration of round_bit_pattern function, to provide an interface for rounded table lookups.
concrete.fhe.extensions.table: Declaration of LookupTable class.
concrete.fhe.extensions.tag: Declaration of tag context manager, to allow tagging certain nodes.
concrete.fhe.extensions.truncate_bit_pattern: Declaration of truncate_bit_pattern extension.
concrete.fhe.extensions.univariate: Declaration of univariate function.
concrete.fhe.extensions.zeros: Declaration of zeros and zero functions, to simplify creation of encrypted zeros.
concrete.fhe.internal.
concrete.fhe.internal.utils: Declaration of various functions and constants related to the entire project.
concrete.fhe.mlir: Provide computation graph to mlir functionality.
concrete.fhe.mlir.context: Declaration of Context class.
concrete.fhe.mlir.conversion: Declaration of ConversionType and Conversion classes.
concrete.fhe.mlir.converter: Declaration of Converter class.
concrete.fhe.mlir.processors: All graph processors.
concrete.fhe.mlir.processors.assign_bit_widths: Declaration of AssignBitWidths graph processor.
concrete.fhe.mlir.processors.check_integer_only: Declaration of CheckIntegerOnly graph processor.
concrete.fhe.mlir.processors.process_rounding: Declaration of ProcessRounding graph processor.
concrete.fhe.mlir.utils: Declaration of various functions and constants related to MLIR conversion.
concrete.fhe.representation: Define structures used to represent computation.
concrete.fhe.representation.evaluator: Declaration of various Evaluator classes, to make graphs picklable.
concrete.fhe.representation.graph: Declaration of Graph class.
concrete.fhe.representation.node: Declaration of Node class.
concrete.fhe.representation.operation: Declaration of Operation enum.
concrete.fhe.representation.utils: Declaration of various functions and constants related to representation of computation.
concrete.fhe.tracing: Provide function to computation graph functionality.
concrete.fhe.tracing.tracer: Declaration of Tracer class.
concrete.fhe.tracing.typing: Declaration of type annotation.
concrete.fhe.values: Define the available values and their semantics.
concrete.fhe.values.scalar: Declaration of ClearScalar and EncryptedScalar wrappers.
concrete.fhe.values.tensor: Declaration of ClearTensor and EncryptedTensor wrappers.
concrete.fhe.values.value_description: Declaration of ValueDescription class.
concrete.fhe.version
concrete.lang: Concretelang python module
concrete.lang.dialects
concrete.lang.dialects.fhe: FHE dialect module
concrete.lang.dialects.fhelinalg: FHELinalg dialect module
concrete.lang.dialects.tracing: Tracing dialect module

Classes

client_parameters.ClientParameters: ClientParameters are public parameters used for key generation.
client_support.ClientSupport: Client interface for doing key generation and encryption.
compilation_context.CompilationContext: Support class for compilation context.
compilation_feedback.CircuitCompilationFeedback: CircuitCompilationFeedback is a set of hint computed by the compiler engine for a circuit.
compilation_feedback.ProgramCompilationFeedback: CompilationFeedback is a set of hint computed by the compiler engine.
compilation_options.CompilationOptions: CompilationOptions holds different flags and options of the compilation process.
evaluation_keys.EvaluationKeys: EvaluationKeys required for execution.
key_set.KeySet: KeySet stores the different keys required for an encrypted computation.
key_set_cache.KeySetCache: KeySetCache is a cache for KeySet to avoid generating similar keys multiple times.
lambda_argument.LambdaArgument: LambdaArgument holds scalar or tensor values.
library_compilation_result.LibraryCompilationResult: LibraryCompilationResult holds the result of the library compilation.
library_lambda.LibraryLambda: LibraryLambda reference a compiled library and can be ran using LibrarySupport.
library_support.LibrarySupport: Support class for library compilation and execution.
parameter.Parameter: An FHE parameter.
public_arguments.PublicArguments: PublicArguments holds encrypted and plain arguments, as well as public materials.
public_result.PublicResult: PublicResult holds the result of an encrypted execution and can be decrypted using ClientSupport.
server_circuit.ServerCircuit: ServerCircuit references a circuit that can be called for execution and simulation.
server_program.ServerProgram: ServerProgram references compiled circuit objects.
simulated_value_decrypter.SimulatedValueDecrypter: A helper class to decrypt Values.
simulated_value_exporter.SimulatedValueExporter: A helper class to create Values.
value.Value: An encrypted/clear value which can be scalar/tensor.
value_decrypter.ValueDecrypter: A helper class to decrypt Values.
value_exporter.ValueExporter: A helper class to create Values.
wrapper.WrapperCpp: Wrapper base class for native Cpp objects.
artifacts.DebugArtifacts: DebugArtifacts class, to export information about the compilation process for single function.
artifacts.FunctionDebugArtifacts: An object containing debug artifacts for a certain function in an fhe module.
artifacts.ModuleDebugArtifacts: An object containing debug artifacts for an fhe module.
circuit.Circuit: Circuit class, to combine computation graph, mlir, client and server into a single object.
client.Client: Client class, which can be used to manage keys, encrypt arguments and decrypt results.
compiler.Compiler: Compiler class, to glue the compilation pipeline.
compiler.EncryptionStatus: EncryptionStatus enum, to represent encryption status of parameters.
configuration.ApproximateRoundingConfig: Controls the behavior of approximate rounding.
configuration.BitwiseStrategy: BitwiseStrategy, to specify implementation preference for bitwise operations.
configuration.ComparisonStrategy: ComparisonStrategy, to specify implementation preference for comparisons.
configuration.Configuration: Configuration class, to allow the compilation process to be customized.
configuration.Exactness.
configuration.MinMaxStrategy: MinMaxStrategy, to specify implementation preference for minimum and maximum operations.
configuration.MultiParameterStrategy: MultiParamStrategy, to set optimization strategy for multi-parameter.
configuration.MultivariateStrategy: MultivariateStrategy, to specify implementation preference for multivariate operations.
configuration.ParameterSelectionStrategy: ParameterSelectionStrategy, to set optimization strategy.
decorators.Compilable: Compilable class, to wrap a function and provide methods to trace and compile it.
keys.Keys: Keys class, to manage generate/reuse keys.
module.ExecutionRt: Runtime object class for execution.
module.FheFunction: Fhe function class, allowing to run or simulate one function of an fhe module.
module.FheModule: Fhe module class, to combine computation graphs, mlir, runtime objects into a single object.
module.SimulationRt: Runtime object class for simulation.
module_compiler.DebugManager: A debug manager, allowing streamlined debugging.
module_compiler.FunctionDef: An object representing the definition of a function as used in an fhe module.
module_compiler.ModuleCompiler: Compiler class for multiple functions, to glue the compilation pipeline.
server.Server: Server class, which can be used to perform homomorphic computation.
specs.ClientSpecs: ClientSpecs class, to create Client objects.
value.Value: Value class, to store scalar or tensor values which can be encrypted or clear.
base.BaseDataType: BaseDataType abstract class, to form a basis for data types.
float.Float: Float class, to represent floating point numbers.
integer.Integer: Integer class, to represent integers.
bits.Bits: Bits class, to provide indexing into the bits of integers.
round_bit_pattern.Adjusting: Adjusting class, to be used as early stop signal during adjustment.
round_bit_pattern.AutoRounder: AutoRounder class, to optimize for number of msbs to keep druing round bit pattern operation.
table.LookupTable: LookupTable class, to provide a way to do direct table lookups.
truncate_bit_pattern.Adjusting: Adjusting class, to be used as early stop signal during adjustment.
truncate_bit_pattern.AutoTruncator: AutoTruncator class, to optimize for the number of msbs to keep during truncate operation.
context.Context: Context class, to perform operations on conversions.
conversion.Conversion: Conversion class, to store MLIR operations with additional information.
conversion.ConversionType: ConversionType class, to make it easier to work with MLIR types.
converter.Converter: Converter class, to convert a computation graph to MLIR.
assign_bit_widths.AdditionalConstraints: AdditionalConstraints class to customize bit-width assignment step easily.
assign_bit_widths.AssignBitWidths: AssignBitWidths graph processor, to assign proper bit-widths to be compatible with FHE.
check_integer_only.CheckIntegerOnly: CheckIntegerOnly graph processor, to make sure the graph only contains integer nodes.
process_rounding.ProcessRounding: ProcessRounding graph processor, to analyze rounding and support regular operations on it.
utils.Comparison: Comparison enum, to store the result comparison in 2-bits as there are three possible outcomes.
utils.HashableNdarray: HashableNdarray class, to use numpy arrays in dictionaries.
evaluator.ConstantEvaluator: ConstantEvaluator class, to evaluate Operation.Constant nodes.
evaluator.GenericEvaluator: GenericEvaluator class, to evaluate Operation.Generic nodes.
evaluator.GenericTupleEvaluator: GenericEvaluator class, to evaluate Operation.Generic nodes where args are packed in a tuple.
evaluator.InputEvaluator: InputEvaluator class, to evaluate Operation.Input nodes.
graph.Graph: Graph class, to represent computation graphs.
graph.GraphProcessor: GraphProcessor base class, to define the API for a graph processing pipeline.
graph.MultiGraphProcessor: MultiGraphProcessor base class, to define the API for a multiple graph processing pipeline.
node.Node: Node class, to represent computation in a computation graph.
operation.Operation: Operation enum, to distinguish nodes within a computation graph.
tracer.Annotation: Base annotation for direct definition.
tracer.ScalarAnnotation: Base scalar annotation for direct definition.
tracer.TensorAnnotation: Base tensor annotation for direct definition.
tracer.Tracer: Tracer class, to create computation graphs from python functions.
typing.f32: Scalar f32 annotation.
typing.f64: Scalar f64 annotation.
typing.int1: Scalar int1 annotation.
typing.int10: Scalar int10 annotation.
typing.int11: Scalar int11 annotation.
typing.int12: Scalar int12 annotation.
typing.int13: Scalar int13 annotation.
typing.int14: Scalar int14 annotation.
typing.int15: Scalar int15 annotation.
typing.int16: Scalar int16 annotation.
typing.int17: Scalar int17 annotation.
typing.int18: Scalar int18 annotation.
typing.int19: Scalar int19 annotation.
typing.int2: Scalar int2 annotation.
typing.int20: Scalar int20 annotation.
typing.int21: Scalar int21 annotation.
typing.int22: Scalar int22 annotation.
typing.int23: Scalar int23 annotation.
typing.int24: Scalar int24 annotation.
typing.int25: Scalar int25 annotation.
typing.int26: Scalar int26 annotation.
typing.int27: Scalar int27 annotation.
typing.int28: Scalar int28 annotation.
typing.int29: Scalar int29 annotation.
typing.int3: Scalar int3 annotation.
typing.int30: Scalar int30 annotation.
typing.int31: Scalar int31 annotation.
typing.int32: Scalar int32 annotation.
typing.int33: Scalar int33 annotation.
typing.int34: Scalar int34 annotation.
typing.int35: Scalar int35 annotation.
typing.int36: Scalar int36 annotation.
typing.int37: Scalar int37 annotation.
typing.int38: Scalar int38 annotation.
typing.int39: Scalar int39 annotation.
typing.int4: Scalar int4 annotation.
typing.int40: Scalar int40 annotation.
typing.int41: Scalar int41 annotation.
typing.int42: Scalar int42 annotation.
typing.int43: Scalar int43 annotation.
typing.int44: Scalar int44 annotation.
typing.int45: Scalar int45 annotation.
typing.int46: Scalar int46 annotation.
typing.int47: Scalar int47 annotation.
typing.int48: Scalar int48 annotation.
typing.int49: Scalar int49 annotation.
typing.int5: Scalar int5 annotation.
typing.int50: Scalar int50 annotation.
typing.int51: Scalar int51 annotation.
typing.int52: Scalar int52 annotation.
typing.int53: Scalar int53 annotation.
typing.int54: Scalar int54 annotation.
typing.int55: Scalar int55 annotation.
typing.int56: Scalar int56 annotation.
typing.int57: Scalar int57 annotation.
typing.int58: Scalar int58 annotation.
typing.int59: Scalar int59 annotation.
typing.int6: Scalar int6 annotation.
typing.int60: Scalar int60 annotation.
typing.int61: Scalar int61 annotation.
typing.int62: Scalar int62 annotation.
typing.int63: Scalar int63 annotation.
typing.int64: Scalar int64 annotation.
typing.int7: Scalar int7 annotation.
typing.int8: Scalar int8 annotation.
typing.int9: Scalar int9 annotation.
typing.tensor: Tensor annotation.
typing.uint1: Scalar uint1 annotation.
typing.uint10: Scalar uint10 annotation.
typing.uint11: Scalar uint11 annotation.
typing.uint12: Scalar uint12 annotation.
typing.uint13: Scalar uint13 annotation.
typing.uint14: Scalar uint14 annotation.
typing.uint15: Scalar uint15 annotation.
typing.uint16: Scalar uint16 annotation.
typing.uint17: Scalar uint17 annotation.
typing.uint18: Scalar uint18 annotation.
typing.uint19: Scalar uint19 annotation.
typing.uint2: Scalar uint2 annotation.
typing.uint20: Scalar uint20 annotation.
typing.uint21: Scalar uint21 annotation.
typing.uint22: Scalar uint22 annotation.
typing.uint23: Scalar uint23 annotation.
typing.uint24: Scalar uint24 annotation.
typing.uint25: Scalar uint25 annotation.
typing.uint26: Scalar uint26 annotation.
typing.uint27: Scalar uint27 annotation.
typing.uint28: Scalar uint28 annotation.
typing.uint29: Scalar uint29 annotation.
typing.uint3: Scalar uint3 annotation.
typing.uint30: Scalar uint30 annotation.
typing.uint31: Scalar uint31 annotation.
typing.uint32: Scalar uint32 annotation.
typing.uint33: Scalar uint33 annotation.
typing.uint34: Scalar uint34 annotation.
typing.uint35: Scalar uint35 annotation.
typing.uint36: Scalar uint36 annotation.
typing.uint37: Scalar uint37 annotation.
typing.uint38: Scalar uint38 annotation.
typing.uint39: Scalar uint39 annotation.
typing.uint4: Scalar uint4 annotation.
typing.uint40: Scalar uint40 annotation.
typing.uint41: Scalar uint41 annotation.
typing.uint42: Scalar uint42 annotation.
typing.uint43: Scalar uint43 annotation.
typing.uint44: Scalar uint44 annotation.
typing.uint45: Scalar uint45 annotation.
typing.uint46: Scalar uint46 annotation.
typing.uint47: Scalar uint47 annotation.
typing.uint48: Scalar uint48 annotation.
typing.uint49: Scalar uint49 annotation.
typing.uint5: Scalar uint5 annotation.
typing.uint50: Scalar uint50 annotation.
typing.uint51: Scalar uint51 annotation.
typing.uint52: Scalar uint52 annotation.
typing.uint53: Scalar uint53 annotation.
typing.uint54: Scalar uint54 annotation.
typing.uint55: Scalar uint55 annotation.
typing.uint56: Scalar uint56 annotation.
typing.uint57: Scalar uint57 annotation.
typing.uint58: Scalar uint58 annotation.
typing.uint59: Scalar uint59 annotation.
typing.uint6: Scalar uint6 annotation.
typing.uint60: Scalar uint60 annotation.
typing.uint61: Scalar uint61 annotation.
typing.uint62: Scalar uint62 annotation.
typing.uint63: Scalar uint63 annotation.
typing.uint64: Scalar uint64 annotation.
typing.uint7: Scalar uint7 annotation.
typing.uint8: Scalar uint8 annotation.
typing.uint9: Scalar uint9 annotation.
value_description.ValueDescription: ValueDescription class, to combine data type, shape, and encryption status into a single object.

Functions

compiler.init_dfr: Initialize dataflow parallelization.
compiler.round_trip: Parse the MLIR input, then return it back.
compilation_feedback.tag_from_location: Extract tag of the operation from its location.
utils.lookup_runtime_lib: Try to find the absolute path to the runtime library.
decorators.circuit: Provide a direct interface for compilation of single circuit programs.
decorators.compiler: Provide an easy interface for the compilation of single-circuit programs.
decorators.function: Provide an easy interface to define a function within an fhe module.
decorators.module: Provide an easy interface for the compilation of multi functions modules.
utils.add_nodes_from_to: Add nodes from from_nodes to to_nodes, to all_nodes.
utils.check_subgraph_fusibility: Determine if a subgraph can be fused.
utils.convert_subgraph_to_subgraph_node: Convert a subgraph to Operation.Generic node.
utils.find_closest_integer_output_nodes: Find the closest upstream integer output nodes to a set of start nodes in a graph.
utils.find_float_subgraph_with_unique_terminal_node: Find a subgraph with float computations that end with an integer output.
utils.find_single_lca: Find the single lowest common ancestor of a list of nodes.
utils.find_tlu_subgraph_with_multiple_variable_inputs_that_has_a_single_common_ancestor: Find a subgraph with a tlu computation that has multiple variable inputs where all variable inputs share a common ancestor.
utils.friendly_type_format: Convert a type to a string. Remove package name and class/type keywords.
utils.fuse: Fuse appropriate subgraphs in a graph to a single Operation.Generic node.
utils.get_terminal_size: Get the terminal size.
utils.inputset: Generate a random inputset.
utils.is_single_common_ancestor: Determine if a node is the single common ancestor of a list of nodes.
utils.validate_input_args: Validate input arguments.
utils.combine_dtypes: Get the 'BaseDataType' that can represent a set of 'BaseDataType's.
array.array: Create an encrypted array from either encrypted or clear values.
bits.bits: Extract bits of integers.
convolution.conv: Trace and evaluate convolution operations.
hint.hint: Hint the compilation process about properties of a value.
identity.identity: Apply identity function to x.
maxpool.maxpool: Evaluate or trace MaxPool operation.
multivariate.multivariate: Wrap a multivariate function so that it is traced into a single generic node.
ones.one: Create an encrypted scalar with the value of one.
ones.ones: Create an encrypted array of ones.
ones.ones_like: Create an encrypted array of ones with the same shape as another array.
relu.relu: Rectified linear unit extension.
round_bit_pattern.round_bit_pattern: Round the bit pattern of an integer.
tag.tag: Introduce a new tag to the tag stack.
truncate_bit_pattern.truncate_bit_pattern: Round the bit pattern of an integer.
univariate.univariate: Wrap a univariate function so that it is traced into a single generic node.
zeros.zero: Create an encrypted scalar with the value of zero.
zeros.zeros: Create an encrypted array of zeros.
zeros.zeros_like: Create an encrypted array of zeros with the same shape as another array.
utils.assert_that: Assert a condition.
utils.unreachable: Raise a RuntimeError to indicate unreachable code is entered.
utils.construct_deduplicated_tables: Construct lookup tables for each cell of the input for an Operation.Generic node.
utils.construct_table: Construct the lookup table for an Operation.Generic node.
utils.construct_table_multivariate: Construct the lookup table for a multivariate node.
utils.flood_replace_none_values: Use flooding algorithm to replace None values.
utils.format_constant: Get the textual representation of a constant.
utils.format_indexing_element: Format an indexing element.
scalar.clear_scalar_builder: Build a clear scalar value.
scalar.encrypted_scalar_builder: Build an encrypted scalar value.
scalar.clear_scalar_builder: Build a clear scalar value.
scalar.encrypted_scalar_builder: Build an encrypted scalar value.
tensor.clear_tensor_builder: Build a clear tensor value.
tensor.encrypted_tensor_builder: Build an encrypted tensor value.
tensor.clear_tensor_builder: Build a clear tensor value.
tensor.encrypted_tensor_builder: Build an encrypted tensor value.

FHELinalg dialect

High Level Fully Homomorphic Encryption Linalg dialect A dialect for representation of high level linalg operations on fully homomorphic ciphertexts.

Operation definition

`FHELinalg.add_eint_int` (::mlir::concretelang::FHELinalg::AddEintIntOp)

Returns a tensor that contains the addition of a tensor of encrypted integers and a tensor of clear integers.

Performs an addition following the broadcasting rules between a tensor of encrypted integers and a tensor of clear integers. The width of the clear integers must be less than or equal to the width of encrypted integers.

Examples:

// Returns the term-by-term addition of `%a0` with `%a1`
"FHELinalg.add_eint_int"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4xi5>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term addition of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.add_eint_int"(%a0, %a1) : (tensor<4x1x4x!FHE.eint<4>>, tensor<1x4x4xi5>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the addition of a 3x3 matrix of encrypted integers and a 3x1 matrix (a column) of integers.
//
// [1,2,3]   [1]   [2,3,4]
// [4,5,6] + [2] = [6,7,8]
// [7,8,9]   [3]   [10,11,12]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.add_eint_int"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x1xi5>) -> tensor<3x3x!FHE.eint<4>>

// Returns the addition of a 3x3 matrix of encrypted integers and a 1x3 matrix (a line) of integers.
//
// [1,2,3]             [2,4,6]
// [4,5,6] + [1,2,3] = [5,7,9]
// [7,8,9]             [8,10,12]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.add_eint_int"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<1x3xi5>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 is missing of operand #2.
"FHELinalg.add_eint_int(%a0, %a1)" : (tensor<3x4x!FHE.eint<4>>, tensor<3xi5>) -> tensor<4x4x4x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEintInt, TensorBroadcastingRules

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.add_eint` (::mlir::concretelang::FHELinalg::AddEintOp)

Returns a tensor that contains the addition of two tensor of encrypted integers.

Performs an addition following the broadcasting rules between two tensors of encrypted integers. The width of the encrypted integers must be equal.

Examples:

// Returns the term-by-term addition of `%a0` with `%a1`
"FHELinalg.add_eint"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4x!FHE.eint<4>>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term addition of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.add_eint"(%a0, %a1) : (tensor<4x1x4x!FHE.eint<4>>, tensor<1x4x4x!FHE.eint<4>>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the addition of a 3x3 matrix of encrypted integers and a 3x1 matrix (a column) of encrypted integers.
//
// [1,2,3]   [1]   [2,3,4]
// [4,5,6] + [2] = [6,7,8]
// [7,8,9]   [3]   [10,11,12]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.add_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x1x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Returns the addition of a 3x3 matrix of encrypted integers and a 1x3 matrix (a line) of encrypted integers.
//
// [1,2,3]             [2,4,6]
// [4,5,6] + [1,2,3] = [5,7,9]
// [7,8,9]             [8,10,12]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.add_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<1x3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 of operand #2 is missing.
"FHELinalg.add_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEint, TensorBroadcastingRules

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.apply_lookup_table` (::mlir::concretelang::FHELinalg::ApplyLookupTableEintOp)

Returns a tensor that contains the result of the lookup on a table.

For each encrypted index, performs a lookup table of clear integers.

// The result of this operation, is a tensor that contains the result of a lookup table.
// i.e. %res[i, ..., k] = %lut[%t[i, ..., k]]
%res = FHELinalg.apply_lookup_table(%t, %lut): tensor<DNx...xD1x!FHE.eint<$p>>, tensor<D2^$pxi64> -> tensor<DNx...xD1x!FHE.eint<$p>>

The %lut argument must be a tensor with one dimension, where its dimension is 2^p where p is the width of the encrypted integers.

Examples:


// Returns the lookup of 3x3 matrix of encrypted indices of with 2 on a table of size 4=2² of clear integers.
//
// [0,1,2]                 [1,3,5]
// [3,0,1] lut [1,3,5,7] = [7,1,3]
// [2,3,0]                 [5,7,1]
"FHELinalg.apply_lookup_table"(%t, %lut) : (tensor<3x3x!FHE.eint<2>>, tensor<4xi64>) -> tensor<3x3x!FHE.eint<3>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

t

lut

Results:

Result

Description

«unnamed»

`FHELinalg.apply_mapped_lookup_table` (::mlir::concretelang::FHELinalg::ApplyMappedLookupTableEintOp)

Returns a tensor that contains the result of the lookup on a table, using a different lookup table for each element, specified by a map.

Performs for each encrypted index a lookup table of clear integers. Multiple lookup tables are passed, and the application of lookup tables is performed following the broadcasting rules. The precise lookup is specified by a map.

// The result of this operation, is a tensor that contains the result of the lookup on different tables.
// i.e. %res[i, ..., k] = %luts[ %map[i, ..., k] ][ %t[i, ..., k] ]
%res = FHELinalg.apply_mapped_lookup_table(%t, %luts, %map): tensor<DNx...xD1x!FHE.eint<$p>>, tensor<DM x ^$p>, tensor<DNx...xD1xindex> -> tensor<DNx...xD1x!FHE.eint<$p>>

Examples:


// Returns the lookup of 3x2 matrix of encrypted indices of width 2 on a vector of 2 tables of size 4=2^2 of clear integers.
//
// [0,1]                                 [0, 1] = [1,2]
// [3,0] lut [[1,3,5,7], [0,2,4,6]] with [0, 1] = [7,0]
// [2,3]                                 [0, 1] = [5,6]
"FHELinalg.apply_mapped_lookup_table"(%t, %luts, %map) : (tensor<3x2x!FHE.eint<2>>, tensor<2x4xi64>, tensor<3x2xindex>) -> tensor<3x2x!FHE.eint<3>>

Others examples: // [0,1] [1, 0] = [3,2] // [3,0] lut [[1,3,5,7], [0,2,4,6]] with [0, 1] = [7,0] // [2,3] [1, 0] = [4,7]

// [0,1] [0, 0] = [1,3] // [3,0] lut [[1,3,5,7], [0,2,4,6]] with [1, 1] = [6,0] // [2,3] [1, 0] = [4,7]

// [0,1] [0] = [1,3] // [3,0] lut [[1,3,5,7], [0,2,4,6]] with [1] = [6,0] // [2,3] [0] = [5,7]

// [0,1] = [1,2] // [3,0] lut [[1,3,5,7], [0,2,4,6]] with [0, 1] = [7,0] // [2,3] = [5,6]

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

t

luts

map

Results:

Result

Description

«unnamed»

`FHELinalg.apply_multi_lookup_table` (::mlir::concretelang::FHELinalg::ApplyMultiLookupTableEintOp)

Returns a tensor that contains the result of the lookup on a table, using a different lookup table for each element.

Performs for each encrypted index a lookup table of clear integers. Multiple lookup tables are passed, and the application of lookup tables is performed following the broadcasting rules.

// The result of this operation, is a tensor that contains the result of the lookup on different tables.
// i.e. %res[i, ..., k] = [ %luts[i][%t[i]], ..., %luts[k][%t[k]] ]
%res = FHELinalg.apply_multi_lookup_table(%t, %lut): tensor<DNx...xD1x!FHE.eint<$p>>, tensor<DMx...xD1xD2^$pxi64> -> tensor<DNx...xD1x!FHE.eint<$p>>

The %luts argument should be a tensor with M dimension, where the first M-1 dimensions are broadcastable with the N dimensions of the encrypted tensor, and where the last dimension dimension is equal to 2^p where p is the width of the encrypted integers.

Examples:


// Returns the lookup of 3x2 matrix of encrypted indices of width 2 on a vector of 2 tables of size 4=2² of clear integers.
// The tables are broadcasted along the first dimension of the tensor.
//
// [0,1]                            = [1,2]
// [3,0] lut [[1,3,5,7], [0,2,4,6]] = [7,0]
// [2,3]                            = [5,6]
"FHELinalg.apply_multi_lookup_table"(%t, %luts) : (tensor<3x2x!FHE.eint<2>>, tensor<2x4xi64>) -> tensor<3x2x!FHE.eint<3>>


// Returns the lookup of a vector of 3 encrypted indices of width 2 on a vector of 3 tables of size 4=2² of clear integers.
//
// [3,0,1] lut [[1,3,5,7], [0,2,4,6], [1,2,3,4]] = [7,0,2]
"FHELinalg.apply_multi_lookup_table"(%t, %luts) : (tensor<3x!FHE.eint<2>>, tensor<3x4xi64>) -> tensor<3x!FHE.eint<3>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

t

luts

Results:

Result

Description

«unnamed»

`FHELinalg.broadcast` (::mlir::concretelang::FHELinalg::BroadcastOp)

Broadcasts a tensor to a shape.

Broadcasting is used for expanding certain dimensions of a tensor or adding new dimensions to it at the beginning.

An example could be broadcasting a tensor with shape <1x2x1x4x1> to a tensor of shape <6x1x2x3x4x5>.

In this example:

last dimension of the input (1) is expanded to (5)
the dimension before that (4) is kept
the dimension before that (1) is expanded to (3)
the dimension before that (2) is kept
the dimension before that (1) is kept
a new dimension (6) is added to the beginning

See https://numpy.org/doc/stable/user/basics.broadcasting.html#general-broadcasting-rules for the semantics of broadcasting.

Examples:

"FHELinalg.broadcast"(%t) : (tensor<1xindex>) -> tensor<3xindex>
//
// broadcast([5]) = [5, 5, 5]
//

"FHELinalg.broadcast"(%t) : (tensor<1xindex>) -> tensor<3x2xindex>
//
// broadcast([5]) = [[5, 5], [5, 5], [5, 5]]
//

"FHELinalg.broadcast"(%t) : (tensor<2xindex>) -> tensor<3x2xindex>
//
// broadcast([2, 6]) = [[2, 6], [2, 6], [2, 6]]
//

"FHELinalg.broadcast"(%t) : (tensor<3x1xindex>) -> tensor<3x2xindex>
//
// broadcast([[1], [2], [3]]) = [[1, 1], [2, 2], [3, 3]]
//

"FHELinalg.broadcast"(%t) : (tensor<2xindex>) -> tensor<2x3x2xindex>
//
// broadcast([2, 6]) = [[[2, 6], [2, 6], [2, 6]], [[2, 6], [2, 6], [2, 6]]]
//

"FHELinalg.broadcast"(%t) : (tensor<3x1xindex>) -> tensor<2x3x2xindex>
//
// broadcast([[1], [2], [3]]) = [[[1, 1], [2, 2], [3, 3]], [[1, 1], [2, 2], [3, 3]]]
//

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

output

`FHELinalg.concat` (::mlir::concretelang::FHELinalg::ConcatOp)

Concatenates a sequence of tensors along an existing axis.

Concatenates several tensors along a given axis.

Examples:

"FHELinalg.concat"(%a, %b) { axis = 0 } : (tensor<3x3x!FHE.eint<4>>, tensor<3x3x!FHE.eint<4>>) -> tensor<6x3x!FHE.eint<4>>
//
//        ( [1,2,3]  [1,2,3] )   [1,2,3]
// concat ( [4,5,6], [4,5,6] ) = [4,5,6]
//        ( [7,8,9]  [7,8,9] )   [7,8,9]
//                               [1,2,3]
//                               [4,5,6]
//                               [7,8,9]
//

"FHELinalg.concat"(%a, %b) { axis = 1 } : (tensor<3x3x!FHE.eint<4>>, tensor<3x3x!FHE.eint<4>>) -> tensor<3x6x!FHE.eint<4>>
//
//        ( [1,2,3]  [1,2,3] )   [1,2,3,1,2,3]
// concat ( [4,5,6], [4,5,6] ) = [4,5,6,4,5,6]
//        ( [7,8,9]  [7,8,9] )   [7,8,9,7,8,9]
//

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

axis

::mlir::IntegerAttr

64-bit signless integer attribute

Operands:

Operand

Description

ins

Results:

Result

Description

out

`FHELinalg.conv2d` (::mlir::concretelang::FHELinalg::Conv2dOp)

Returns the 2D convolution of a tensor in the form NCHW with weights in the form FCHW

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

padding

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

strides

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

dilations

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

group

::mlir::IntegerAttr

64-bit signless integer attribute

Operands:

Operand

Description

input

weight

bias

Results:

Result

Description

«unnamed»

`FHELinalg.dot_eint_int` (::mlir::concretelang::FHELinalg::Dot)

Returns the encrypted dot product between a vector of encrypted integers and a vector of clean integers.

Performs a dot product between a vector of encrypted integers and a vector of clear integers.

Examples:

// Returns the dot product of `%a0` with `%a1`
"FHELinalg.dot_eint_int"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4xi5>) -> !FHE.eint<4>

Traits: AlwaysSpeculatableImplTrait

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

out

`FHELinalg.dot_eint_eint` (::mlir::concretelang::FHELinalg::DotEint)

Returns the encrypted dot product between two vectors of encrypted integers.

Performs a dot product between two vectors of encrypted integers.

Examples:

// Returns the dot product of `%a0` with `%a1`
"FHELinalg.dot_eint_eint"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4x!FHE.eint<4>>) -> !FHE.eint<4>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

out

`FHELinalg.fancy_assign` (::mlir::concretelang::FHELinalg::FancyAssignOp)

Assigns a tensor into another tensor at a tensor of indices.

Examples:

"FHELinalg.fancy_assign"(%t, %i, %a) : (tensor<5x!FHE.eint<16>>, tensor<3xindex>, tensor<3x!FHE.eint<16>>) -> tensor<5x!FHE.eint<16>>
//
// fancy_assign([10, 20, 30, 40, 50], [3, 1, 2], [1000, 2000, 3000]) = [10, 2000, 3000, 1000, 50]
//

"FHELinalg.fancy_assign"(%t, %i, %a) : (tensor<5x!FHE.eint<16>>, tensor<2x2xindex>, tensor<2x2x!FHE.eint<16>>) -> tensor<5x!FHE.eint<16>>
//
// fancy_assign([10, 20, 30, 40, 50], [[3, 1], [2, 0]], [[1000, 2000], [3000, 4000]]) = [4000, 2000, 3000, 1000, 50]
//

"FHELinalg.fancy_assign"(%t, %i, %a) : (tensor<2x3x!FHE.eint<16>>, tensor<3x2xindex>, tensor<3x!FHE.eint<16>>) -> tensor<2x3x!FHE.eint<16>>
//
// fancy_assign([[11, 12, 13], [21, 22, 23]], [[1, 0], [0, 2], [0, 0]], [1000, 2000, 3000]) = [[3000, 2000, 13], [1000, 22, 23]]
//

"FHELinalg.fancy_assign"(%t, %i, %a) : (tensor<3x3x!FHE.eint<16>>, tensor<2x3x2xindex>, tensor<2x3x!FHE.eint<16>>) -> tensor<3x3x!FHE.eint<16>>
//
// fancy_assign(
//     [[11, 12, 13], [21, 22, 23], [31, 32, 33]],
//     [[[1, 0], [0, 2], [0, 0]], [[2, 0], [1, 1], [2, 1]]],
//     [[1000, 2000, 3000], [4000, 5000, 6000]]
// ) = [[3000, 2000, 13], [1000, 5000, 23], [4000, 6000, 33]]
//

Notes:

Assigning to the same output position results in undefined behavior.

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

indices

values

Results:

Result

Description

output

`FHELinalg.fancy_index` (::mlir::concretelang::FHELinalg::FancyIndexOp)

Index into a tensor using a tensor of indices.

Examples:

"FHELinalg.fancy_index"(%t, %i) : (tensor<5x!FHE.eint<6>>, tensor<3xindex>) -> tensor<3x!FHE.eint<6>>
//
// fancy_index([10, 20, 30, 40, 50], [3, 1, 2]) = [40, 20, 30]
//

"FHELinalg.fancy_index"(%t, %i) : (tensor<5x!FHE.eint<6>>, tensor<3x2xindex>) -> tensor<3x2x!FHE.eint<6>>
//
// fancy_index([10, 20, 30, 40, 50], [[3, 1], [2, 2], [0, 4]]) = [[40, 20], [30, 30], [10, 50]]
//

"FHELinalg.fancy_index"(%t, %i) : (tensor<2x3x!FHE.eint<6>>, tensor<3x2xindex>) -> tensor<3x!FHE.eint<6>>
//
// fancy_index([[11, 12, 13], [21, 22, 23]], [[1, 0], [0, 2], [0, 0]]) = [21, 13, 11]
//

"FHELinalg.fancy_index"(%t, %i) : (tensor<3x3x!FHE.eint<6>>, tensor<2x3x2xindex>) -> tensor<2x3x!FHE.eint<6>>
//
// fancy_index([[11, 12, 13], [21, 22, 23], [31, 32, 33]], [[[1, 0], [0, 2], [0, 0]], [[2, 0], [1, 1], [2, 1]]]) = [[21, 13, 11], [31, 22, 32]]
//

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

indices

Results:

Result

Description

output

`FHELinalg.from_element` (::mlir::concretelang::FHELinalg::FromElementOp)

Creates a tensor with a single element.

"FHELinalg.from_element"(%a) : (Type) -> tensor<1xType>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

«unnamed»

any type

Results:

Result

Description

«unnamed»

`FHELinalg.lsb` (::mlir::concretelang::FHELinalg::LsbEintOp)

Extract the lowest significant bit at a given precision.

This operation extracts the lsb of a ciphertext tensor in a specific precision.

Extracting only 1 bit:

 // ok
 %lsb = "FHE.lsb"(%a): (tensor<1x!FHE.eint<4>)) -> (tensor<1x!FHE.eint<1>>)

If you need to clear the lsb of the original ciphertext, you should extract to the same precision as the ciphertext.
If you need to extract several bits, you can extract sequentially using explicit bitwidth change and bit clearing.

Example:
```mlir
 // ok
 %a_lsb = "FHELinalg.lsb"(%a): (tensor<1x!FHE.eint<4>)) -> (tensor<1x!FHE.eint<4>))
 %a_lsb_cleared = "FHELinalg.sub_eint"(%a, %lsb) : (tensor<1x!FHE.eint<4>), tensor<1x!FHE.eint<4>)) -> (tensor<1x!FHE.eint<4>))
 %b = %a : tensor<1x!FHE.eint<3>>
 // now you can extract the next lsb from %b
 %b_lsb = "FHELinalg.lsb"(%b): (tensor<1x!FHE.eint<3>>) -> (tensor<1x!FHE.eint<3>>)
 // later if you need %b_lsb at the original position
 %b_lsb_as_in_a = %b_lsb : tensor<1x!FHE.eint<3>>

Traits: AlwaysSpeculatableImplTrait, TensorUnaryEint

Interfaces: ConditionallySpeculatable, ConstantNoise, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

output

`FHELinalg.matmul_eint_eint` (::mlir::concretelang::FHELinalg::MatMulEintEintOp)

Returns a tensor that contains the result of the matrix multiplication of a matrix of encrypted integers and a second matrix of encrypted integers.

Performs a matrix multiplication of a matrix of encrypted integers and a second matrix of encrypted integers.

The behavior depends on the arguments in the following way:

- If both arguments are 2-D,
  they are multiplied like conventional matrices.

  e.g.,

  arg0: tensor<MxN> = [...]
  arg1: tensor<NxP> = [...]

  result: tensor<MxP> = [...]

- If the first argument is a vector (1-D),
  it is treated as a matrix with a single row and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the first dimension is removed from the result.

  e.g.,

  arg0: tensor<3> = [x, y, z]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  is treated as

  arg0: tensor<1x3> = [
      [x, y, z]
  ]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  and matrix multiplication is performed with the following form (1x3 @ 3xM -> 1xM)

  result: tensor<1xM> = [[_, _, ..., _, _]]

  finally, the first dimension is removed by definition so the result has the following form

  result: tensor<M>  = [_, _, ..., _, _]

- If the second argument is 1-D,
  it is treated as a matrix with a single column and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the last dimension is removed from the result.

  e.g.,

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3> = [x, y, z]

  is treated as

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3x1> = [
    [x],
    [y],
    [z],
  ]

  and matrix multiplication is performed with the following form (Mx3 @ 3x1 -> Mx1)

  result: tensor<Mx1> = [
    [_],
    [_],
      ...,
    [_],
    [_],
  ]

  finally, the last dimension is removed by definition so the result has the following form

  result: tensor<M> = [_, _, _]

- If either argument is N-D where N > 2,
  the operation is treated as a collection of matrices residing in the last two indices and broadcasted accordingly.

  arg0: tensor<Kx1MxN> = [...]
  arg1: tensor<LxNxP> = [...]

  result: tensor<KxLxMxP> = [...]

"FHELinalg.matmul_eint_eint(%a, %b) : (tensor<MxNx!FHE.eint<p>>, tensor<NxPx!FHE.eint<p>'>) -> tensor<MxPx!FHE.eint<p>>"
"FHELinalg.matmul_eint_eint(%a, %b) : (tensor<KxLxMxNx!FHE.eint<p>>, tensor<KxLxNxPx!FHE.eint<p>'>) -> tensor<KxLxMxPx!FHE.eint<p>>"
"FHELinalg.matmul_eint_eint(%a, %b) : (tensor<MxNx!FHE.eint<p>>, tensor<Nx!FHE.eint<p>'>) -> tensor<Mx!FHE.eint<p>>"
"FHELinalg.matmul_eint_eint(%a, %b) : (tensor<Nx!FHE.eint<p>>, tensor<NxPx!FHE.eint<p>'>) -> tensor<Px!FHE.eint<p>>"

Examples:

// Returns the matrix multiplication of a 3x2 matrix of encrypted integers and a 2x3 matrix of integers.
//         [ 1, 2, 3]
//         [ 2, 3, 4]
//       *
// [1,2]   [ 5, 8,11]
// [3,4] = [11,18,25]
// [5,6]   [17,28,39]
//
"FHELinalg.matmul_eint_eint"(%a, %b) : (tensor<3x2x!FHE.eint<6>>, tensor<2x3x!FHE.eint<6>>) -> tensor<3x3x!FHE.eint<12>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEint

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.matmul_eint_int` (::mlir::concretelang::FHELinalg::MatMulEintIntOp)

Returns a tensor that contains the result of the matrix multiplication of a matrix of encrypted integers and a matrix of clear integers.

Performs a matrix multiplication of a matrix of encrypted integers and a matrix of clear integers. The width of the clear integers must be less than or equal to the width of encrypted integers.

The behavior depends on the arguments in the following way:

- If both arguments are 2-D,
  they are multiplied like conventional matrices.

  e.g.,

  arg0: tensor<MxN> = [...]
  arg1: tensor<NxP> = [...]

  result: tensor<MxP> = [...]

- If the first argument is a vector (1-D),
  it is treated as a matrix with a single row and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the first dimension is removed from the result.

  e.g.,

  arg0: tensor<3> = [x, y, z]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  is treated as

  arg0: tensor<1x3> = [
      [x, y, z]
  ]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  and matrix multiplication is performed with the following form (1x3 @ 3xM -> 1xM)

  result: tensor<1xM> = [[_, _, ..., _, _]]

  finally, the first dimension is removed by definition so the result has the following form

  result: tensor<M>  = [_, _, ..., _, _]

- If the second argument is 1-D,
  it is treated as a matrix with a single column and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the last dimension is removed from the result.

  e.g.,

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3> = [x, y, z]

  is treated as

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3x1> = [
    [x],
    [y],
    [z],
  ]

  and matrix multiplication is performed with the following form (Mx3 @ 3x1 -> Mx1)

  result: tensor<Mx1> = [
    [_],
    [_],
      ...,
    [_],
    [_],
  ]

  finally, the last dimension is removed by definition so the result has the following form

  result: tensor<M> = [_, _, _]

- If either argument is N-D where N > 2,
  the operation is treated as a collection of matrices residing in the last two indices and broadcasted accordingly.

  arg0: tensor<Kx1MxN> = [...]
  arg1: tensor<LxNxP> = [...]

  result: tensor<KxLxMxP> = [...]

"FHELinalg.matmul_eint_int(%a, %b) : (tensor<MxNx!FHE.eint<p>>, tensor<NxPxip'>) -> tensor<MxPx!FHE.eint<p>>"
"FHELinalg.matmul_eint_int(%a, %b) : (tensor<KxLxMxNx!FHE.eint<p>>, tensor<KxLxNxPxip'>) -> tensor<KxLxMxPx!FHE.eint<p>>"
"FHELinalg.matmul_eint_int(%a, %b) : (tensor<MxNx!FHE.eint<p>>, tensor<Nxip'>) -> tensor<Mx!FHE.eint<p>>"
"FHELinalg.matmul_eint_int(%a, %b) : (tensor<Nx!FHE.eint<p>>, tensor<NxPxip'>) -> tensor<Px!FHE.eint<p>>"

Examples:

// Returns the matrix multiplication of a 3x2 matrix of encrypted integers and a 2x3 matrix of integers.
//         [ 1, 2, 3]
//         [ 2, 3, 4]
//       *
// [1,2]   [ 5, 8,11]
// [3,4] = [11,18,25]
// [5,6]   [17,28,39]
//
"FHELinalg.matmul_eint_int"(%a, %b) : (tensor<3x2x!FHE.eint<6>>, tensor<2x3xi7>) -> tensor<3x3x!FHE.eint<6>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEintInt

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.matmul_int_eint` (::mlir::concretelang::FHELinalg::MatMulIntEintOp)

Returns a tensor that contains the result of the matrix multiplication of a matrix of clear integers and a matrix of encrypted integers.

Performs a matrix multiplication of a matrix of clear integers and a matrix of encrypted integers. The width of the clear integers must be less than or equal to the width of encrypted integers.

The behavior depends on the arguments in the following way:

- If both arguments are 2-D,
  they are multiplied like conventional matrices.

  e.g.,

  arg0: tensor<MxN> = [...]
  arg1: tensor<NxP> = [...]

  result: tensor<MxP> = [...]

- If the first argument is a vector (1-D),
  it is treated as a matrix with a single row and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the first dimension is removed from the result.

  e.g.,

  arg0: tensor<3> = [x, y, z]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  is treated as

  arg0: tensor<1x3> = [
      [x, y, z]
  ]
  arg1: tensor<3xM> = [
      [_, _, ..., _, _],
      [_, _, ..., _, _],
      [_, _, ..., _, _],
  ]

  and matrix multiplication is performed with the following form (1x3 @ 3xM -> 1xM)

  result: tensor<1xM> = [[_, _, ..., _, _]]

  finally, the first dimension is removed by definition so the result has the following form

  result: tensor<M>  = [_, _, ..., _, _]

- If the second argument is 1-D,
  it is treated as a matrix with a single column and standard matrix multiplication is performed.

  After standard matrix multiplication,
  the last dimension is removed from the result.

  e.g.,

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3> = [x, y, z]

  is treated as

  arg0: tensor<Mx3> = [
      [_, _, _],
      [_, _, _],
      ...,
      [_, _, _],
      [_, _, _],
  ]
  arg1: tensor<3x1> = [
    [x],
    [y],
    [z],
  ]

  and matrix multiplication is performed with the following form (Mx3 @ 3x1 -> Mx1)

  result: tensor<Mx1> = [
    [_],
    [_],
      ...,
    [_],
    [_],
  ]

  finally, the last dimension is removed by definition so the result has the following form

  result: tensor<M> = [_, _, _]

- If either argument is N-D where N > 2,
  the operation is treated as a collection of matrices residing in the last two indices and broadcasted accordingly.

  arg0: tensor<Kx1MxN> = [...]
  arg1: tensor<LxNxP> = [...]

  result: tensor<KxLxMxP> = [...]

"FHELinalg.matmul_int_eint(%a, %b) : (tensor<MxNxip'>, tensor<NxPxFHE.eint<p>>) -> tensor<MxPx!FHE.eint<p>>"
"FHELinalg.matmul_int_eint(%a, %b) : (tensor<KxLxMxNxip'>, tensor<KxLxNxPxFHE.eint<p>>) -> tensor<KxLxMxPx!FHE.eint<p>>"
"FHELinalg.matmul_int_eint(%a, %b) : (tensor<MxNxip'>, tensor<NxFHE.eint<p>>) -> tensor<Mx!FHE.eint<p>>"
"FHELinalg.matmul_int_eint(%a, %b) : (tensor<Nxip'>, tensor<NxPxFHE.eint<p>>) -> tensor<Px!FHE.eint<p>>"

Examples:

// Returns the matrix multiplication of a 3x2 matrix of clear integers and a 2x3 matrix of encrypted integers.
//         [ 1, 2, 3]
//         [ 2, 3, 4]
//       *
// [1,2]   [ 5, 8,11]
// [3,4] = [11,18,25]
// [5,6]   [17,28,39]
//
"FHELinalg.matmul_int_eint"(%a, %b) : (tensor<3x2xi7>, tensor<2x3x!FHE.eint<6>>) -> tensor<3x3x!FHE.eint<6>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryIntEint

Interfaces: Binary, BinaryIntEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.maxpool2d` (::mlir::concretelang::FHELinalg::Maxpool2dOp)

Returns the 2D maxpool of a tensor in the form NCHW

Interfaces: UnaryEint

Attributes:

Attribute

MLIR Type

Description

kernel_shape

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

strides

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

dilations

::mlir::DenseIntElementsAttr

64-bit signless integer elements attribute

Operands:

Operand

Description

input

Results:

Result

Description

«unnamed»

`FHELinalg.mul_eint_int` (::mlir::concretelang::FHELinalg::MulEintIntOp)

Returns a tensor that contains the multiplication of a tensor of encrypted integers and a tensor of clear integers.

Performs a multiplication following the broadcasting rules between a tensor of encrypted integers and a tensor of clear integers. The width of the clear integers must be less than or equal to the width of encrypted integers.

Examples:

// Returns the term-by-term multiplication of `%a0` with `%a1`
"FHELinalg.mul_eint_int"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4xi5>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term multiplication of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.mul_eint_int"(%a0, %a1) : (tensor<4x1x4x!FHE.eint<4>>, tensor<1x4x4xi5>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the multiplication of a 3x3 matrix of encrypted integers and a 3x1 matrix (a column) of integers.
//
// [1,2,3]   [1]   [1,2,3]
// [4,5,6] * [2] = [8,10,18]
// [7,8,9]   [3]   [21,24,27]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.mul_eint_int"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x1xi5>) -> tensor<3x3x!FHE.eint<4>>

// Returns the multiplication of a 3x3 matrix of encrypted integers and a 1x3 matrix (a line) of integers.
//
// [1,2,3]             [2,4,6]
// [4,5,6] * [1,2,3] = [5,7,9]
// [7,8,9]             [8,10,12]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.mul_eint_int"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<1x3xi5>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 is missing of operand #2.
"FHELinalg.mul_eint_int"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3xi5>) -> tensor<3x3x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEintInt, TensorBroadcastingRules

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.mul_eint` (::mlir::concretelang::FHELinalg::MulEintOp)

Returns a tensor that contains the multiplication of two tensor of encrypted integers.

Performs an addition following the broadcasting rules between two tensors of encrypted integers. The width of the encrypted integers must be equal.

Examples:

// Returns the term-by-term multiplication of `%a0` with `%a1`
"FHELinalg.mul_eint"(%a0, %a1) : (tensor<4x!FHE.eint<8>>, tensor<4x!FHE.eint<8>>) -> tensor<4x!FHE.eint<8>>

// Returns the term-by-term multiplication of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.mul_eint"(%a0, %a1) : (tensor<4x1x4x!FHE.eint<8>>, tensor<1x4x4x!FHE.eint<8>>) -> tensor<4x4x4x!FHE.eint<8>>

// Returns the multiplication of a 3x3 matrix of encrypted integers and a 3x1 matrix (a column) of encrypted integers.
//
// [1,2,3]   [1]   [1,2,3]
// [4,5,6] * [2] = [8,10,12]
// [7,8,9]   [3]   [21,24,27]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.mul_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<8>>, tensor<3x1x!FHE.eint<8>>) -> tensor<3x3x!FHE.eint<8>>

// Returns the multiplication of a 3x3 matrix of encrypted integers and a 1x3 matrix (a line) of encrypted integers.
//
// [1,2,3]             [1,4,9]
// [4,5,6] * [1,2,3] = [4,10,18]
// [7,8,9]             [7,16,27]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.mul_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<8>>, tensor<1x3x!FHE.eint<8>>) -> tensor<3x3x!FHE.eint<8>>

// Same behavior as the previous one, but as the dimension #2 of operand #2 is missing.
"FHELinalg.mul_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<8>>, tensor<3x!FHE.eint<8>>) -> tensor<3x3x!FHE.eint<8>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEint, TensorBroadcastingRules

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.neg_eint` (::mlir::concretelang::FHELinalg::NegEintOp)

Returns a tensor that contains the negation of a tensor of encrypted integers.

Performs a negation to a tensor of encrypted integers.

Examples:

// Returns the term-by-term negation of `%a0`
"FHELinalg.neg_eint"(%a0) : (tensor<3x3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>
//
//        ( [1,2,3] )   [31,30,29]
// negate ( [4,5,6] ) = [28,27,26]
//        ( [7,8,9] )   [25,24,23]
//
// The negation is computed as `2**(p+1) - a` where p=4 here.

Traits: AlwaysSpeculatableImplTrait, TensorUnaryEint

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

«unnamed»

`FHELinalg.reinterpret_precision` (::mlir::concretelang::FHELinalg::ReinterpretPrecisionEintOp)

Reinterpret the ciphertext tensor with a different precision.

It's a reinterpretation cast which changes only the precision. On CRT represention, it does nothing. On Native representation, it moves the message/noise further forward, effectively changing the precision. Changing to - a bigger precision is safe, as the crypto-parameters are chosen such that only zeros will come from the noise part. This is equivalent to a shift left for the value - a smaller precision is only safe if you clear the lowest message bits first. If not, you can assume small errors with high probability and frequent bigger errors, which can be contained to small errors using margins. This is equivalent to a shift right for the value

Example:

 // assuming a is encoded as 4bits but can be stored in 2bits
 // we can obtain a to a smaller 2 bits precision
 %shifted_a = "FHELinalg.mul_eint_intlsb"(%a, %c_4): (tensor<1x!FHE.eint<4>>) -> (tensor<1x!FHE.eint<2>>)
 %a_small_precision = "FHELinalg.reinterpret_precision"(%shifted_a, %lsb) : (tensor<1x!FHE.eint<4>>) -> (tensor<1x!FHE.eint<2>>)

Traits: AlwaysSpeculatableImplTrait, TensorUnaryEint

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

output

`FHELinalg.round` (::mlir::concretelang::FHELinalg::RoundOp)

Rounds a tensor of ciphertexts into a smaller precision.

  Assuming a ciphertext whose message is implemented over `p` bits, this
  operation rounds it to fit to `q` bits where `p>q`.

  Example:
  ```mlir
  // ok
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<6>>) -> (tensor<3x!FHE.eint<5>>)
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<5>>) -> (tensor<3x!FHE.eint<3>>)
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<3>>) -> (tensor<3x!FHE.eint<2>>)
  "FHELinalg.round"(%a): (tensor<3x!FHE.esint<3>>) -> (tensor<3x!FHE.esint<2>>)

  // error
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<6>>) -> (tensor<3x!FHE.eint<6>>)
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<4>>) -> (tensor<3x!FHE.eint<5>>)
  "FHELinalg.round"(%a): (tensor<3x!FHE.eint<4>>) -> (tensor<3x!FHE.esint<2>>)


Traits: AlwaysSpeculatableImplTrait, TensorUnaryEint

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

#### Operands:

| Operand | Description |
| :-----: | ----------- |
| `input` | 

#### Results:

| Result | Description |
| :----: | ----------- |
| `output` | 

### `FHELinalg.sub_eint_int` (::mlir::concretelang::FHELinalg::SubEintIntOp)

Returns a tensor that contains the subtraction of a tensor of clear integers from a tensor of encrypted integers.

Performs a subtraction following the broadcasting rules between a tensor of clear integers from a tensor of encrypted integers.
The width of the clear integers must be less than or equal to the width of encrypted integers.

Examples:
```mlir
// Returns the term-by-term subtraction of `%a0` with `%a1`
"FHELinalg.sub_eint_int"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4xi5>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term subtraction of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.sub_eint_int"(%a0, %a1) : (tensor<1x4x4x!FHE.eint<4>>, tensor<4x1x4xi5>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 3x1 matrix (a column) of encrypted integers.
//
// [1,2,3]   [1]   [0,2,3]
// [4,5,6] - [2] = [2,3,4]
// [7,8,9]   [3]   [4,5,6]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_eint_int"(%a0, %a1) : (tensor<3x1x!FHE.eint<4>>, tensor<3x3xi5>) -> tensor<3x3x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 1x3 matrix (a line) of encrypted integers.
//
// [1,2,3]             [0,0,0]
// [4,5,6] - [1,2,3] = [3,3,3]
// [7,8,9]             [6,6,6]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_eint_int"(%a0, %a1) : (tensor<1x3x!FHE.eint<4>>, tensor<3x3xi5>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 is missing of operand #2.
"FHELinalg.sub_eint_int"(%a0, %a1) : (tensor<3x!FHE.eint<4>>, tensor<3x3xi5>) -> tensor<3x3x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEintInt, TensorBroadcastingRules

Interfaces: Binary, BinaryEintInt, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.sub_eint` (::mlir::concretelang::FHELinalg::SubEintOp)

Returns a tensor that contains the subtraction of two tensor of encrypted integers.

Performs an subtraction following the broadcasting rules between two tensors of encrypted integers. The width of the encrypted integers must be equal.

Examples:

// Returns the term-by-term subtraction of `%a0` with `%a1`
"FHELinalg.sub_eint"(%a0, %a1) : (tensor<4x!FHE.eint<4>>, tensor<4x!FHE.eint<4>>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term subtraction of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.sub_eint"(%a0, %a1) : (tensor<4x1x4x!FHE.eint<4>>, tensor<1x4x4x!FHE.eint<4>>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 3x1 matrix (a column) of encrypted integers.
//
// [1,2,3]   [1]   [0,2,3]
// [4,5,6] - [2] = [2,3,4]
// [7,8,9]   [3]   [4,5,6]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x1x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 1x3 matrix (a line) of encrypted integers.
//
// [1,2,3]             [0,0,0]
// [4,5,6] - [1,2,3] = [3,3,3]
// [7,8,9]             [6,6,6]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<1x3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 of operand #2 is missing.
"FHELinalg.sub_eint"(%a0, %a1) : (tensor<3x3x!FHE.eint<4>>, tensor<3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryEint, TensorBroadcastingRules

Interfaces: BinaryEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.sub_int_eint` (::mlir::concretelang::FHELinalg::SubIntEintOp)

Returns a tensor that contains the subtraction of a tensor of clear integers and a tensor of encrypted integers.

Performs a subtraction following the broadcasting rules between a tensor of clear integers and a tensor of encrypted integers. The width of the clear integers must be less than or equal to the width of encrypted integers.

Examples:

// Returns the term-by-term subtraction of `%a0` with `%a1`
"FHELinalg.sub_int_eint"(%a0, %a1) : (tensor<4xi5>, tensor<4x!FHE.eint<4>>) -> tensor<4x!FHE.eint<4>>

// Returns the term-by-term subtraction of `%a0` with `%a1`, where dimensions equal to one are stretched.
"FHELinalg.sub_int_eint"(%a0, %a1) : (tensor<4x1x4xi5>, tensor<1x4x4x!FHE.eint<4>>) -> tensor<4x4x4x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 3x1 matrix (a column) of encrypted integers.
//
// [1,2,3]   [1]   [0,2,3]
// [4,5,6] - [2] = [2,3,4]
// [7,8,9]   [3]   [4,5,6]
//
// The dimension #1 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_int_eint"(%a0, %a1) : (tensor<3x3xi5>, tensor<3x1x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Returns the subtraction of a 3x3 matrix of integers and a 1x3 matrix (a line) of encrypted integers.
//
// [1,2,3]             [0,0,0]
// [4,5,6] - [1,2,3] = [3,3,3]
// [7,8,9]             [6,6,6]
//
// The dimension #2 of operand #2 is stretched as it is equal to 1.
"FHELinalg.sub_int_eint"(%a0, %a1) : (tensor<3x3xi5>, tensor<1x3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

// Same behavior as the previous one, but as the dimension #2 is missing of operand #2.
"FHELinalg.sub_int_eint"(%a0, %a1) : (tensor<3x3xi5>, tensor<3x!FHE.eint<4>>) -> tensor<3x3x!FHE.eint<4>>

Traits: AlwaysSpeculatableImplTrait, TensorBinaryIntEint, TensorBroadcastingRules

Interfaces: Binary, BinaryIntEint, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

rhs

Results:

Result

Description

«unnamed»

`FHELinalg.sum` (::mlir::concretelang::FHELinalg::SumOp)

Returns the sum of elements of a tensor of encrypted integers along specified axes.

Attributes:

keep_dims: boolean = false whether to keep the rank of the tensor after the sum operation if true, reduced axes will have the size of 1
axes: I64ArrayAttr = [] list of dimension to perform the sum along think of it as the dimensions to reduce (see examples below to get an intuition)

Examples:

// Returns the sum of all elements of `%a0`
"FHELinalg.sum"(%a0) : (tensor<3x3x!FHE.eint<4>>) -> !FHE.eint<4>
//
//     ( [1,2,3] )
// sum ( [4,5,6] ) = 45
//     ( [7,8,9] )
//

// Returns the sum of all elements of `%a0` along columns
"FHELinalg.sum"(%a0) { axes = [0] } : (tensor<3x2x!FHE.eint<4>>) -> tensor<2x!FHE.eint<4>>
//
//     ( [1,2] )
// sum ( [3,4] ) = [9, 12]
//     ( [5,6] )
//

// Returns the sum of all elements of `%a0` along columns while preserving dimensions
"FHELinalg.sum"(%a0) { axes = [0], keep_dims = true } : (tensor<3x2x!FHE.eint<4>>) -> tensor<1x2x!FHE.eint<4>>
//
//     ( [1,2] )
// sum ( [3,4] ) = [[9, 12]]
//     ( [5,6] )
//

// Returns the sum of all elements of `%a0` along rows
"FHELinalg.sum"(%a0) { axes = [1] } : (tensor<3x2x!FHE.eint<4>>) -> tensor<3x!FHE.eint<4>>
//
//     ( [1,2] )
// sum ( [3,4] ) = [3, 7, 11]
//     ( [5,6] )
//

// Returns the sum of all elements of `%a0` along rows while preserving dimensions
"FHELinalg.sum"(%a0) { axes = [1], keep_dims = true } : (tensor<3x2x!FHE.eint<4>>) -> tensor<3x1x!FHE.eint<4>>
//
//     ( [1,2] )   [3]
// sum ( [3,4] ) = [7]
//     ( [5,6] )   [11]
//

Traits: AlwaysSpeculatableImplTrait, TensorUnaryEint

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

axes

::mlir::ArrayAttr

64-bit integer array attribute

keep_dims

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

tensor

Results:

Result

Description

out

`FHELinalg.to_signed` (::mlir::concretelang::FHELinalg::ToSignedOp)

Cast an unsigned integer tensor to a signed one

Cast an unsigned integer tensor to a signed one. The result must have the same width and the same shape as the input.

The behavior is undefined on overflow/underflow.

Examples:

// ok
"FHELinalg.to_signed"(%x) : (tensor<3x2x!FHE.eint<2>>) -> tensor<3x2x!FHE.esint<2>>

// error
"FHELinalg.to_signed"(%x) : (tensor<3x2x!FHE.eint<2>>) -> tensor<3x2x!FHE.esint<3>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

output

`FHELinalg.to_unsigned` (::mlir::concretelang::FHELinalg::ToUnsignedOp)

Cast a signed integer tensor to an unsigned one

Cast a signed integer tensor to an unsigned one. The result must have the same width and the same shape as the input.

The behavior is undefined on overflow/underflow.

Examples:

// ok
"FHELinalg.to_unsigned"(%x) : (tensor<3x2x!FHE.esint<2>>) -> tensor<3x2x!FHE.eint<2>>

// error
"FHELinalg.to_unsigned"(%x) : (tensor<3x2x!FHE.esint<2>>) -> tensor<3x2x!FHE.eint<3>>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

input

Results:

Result

Description

output

`FHELinalg.transpose` (::mlir::concretelang::FHELinalg::TransposeOp)

Returns a tensor that contains the transposition of the input tensor.

Performs a transpose operation on an N-dimensional tensor.

Attributes:

axes: I64ArrayAttr = [] list of dimension to perform the transposition contains a permutation of [0,1,..,N-1] where N is the number of axes think of it as a way to rearrange axes (see the example below)

"FHELinalg.transpose"(%a) : (tensor<n0xn1x...xnNxType>) -> tensor<nNx...xn1xn0xType>

Examples:

// Transpose the input tensor
// [1,2]    [1, 3, 5]
// [3,4] => [2, 4, 6]
// [5,6]
//
"FHELinalg.transpose"(%a) : (tensor<3x2xi7>) -> tensor<2x3xi7>

"FHELinalg.transpose"(%a) { axes = [1, 3, 0, 2] } : (tensor<2x3x4x5xi7>) -> tensor<3x5x2x4xi7>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), UnaryEint

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

axes

::mlir::ArrayAttr

64-bit integer array attribute

Operands:

Operand

Description

tensor

any type

Results:

Result

Description

«unnamed»

any type

Concrete dialect

Low Level Fully Homomorphic Encryption dialect A dialect for representation of low level operation on fully homomorphic ciphertext.

Operation definition

`Concrete.add_lwe_buffer` (::mlir::concretelang::Concrete::AddLweBufferOp)

Returns the sum of 2 lwe ciphertexts

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

lhs

1D memref of 64-bit signless integer values

rhs

1D memref of 64-bit signless integer values

`Concrete.add_lwe_tensor` (::mlir::concretelang::Concrete::AddLweTensorOp)

Returns the sum of 2 lwe ciphertexts

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

1D tensor of 64-bit signless integer values

rhs

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.add_plaintext_lwe_buffer` (::mlir::concretelang::Concrete::AddPlaintextLweBufferOp)

Returns the sum of a clear integer and an lwe ciphertext

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

lhs

1D memref of 64-bit signless integer values

rhs

64-bit signless integer

`Concrete.add_plaintext_lwe_tensor` (::mlir::concretelang::Concrete::AddPlaintextLweTensorOp)

Returns the sum of a clear integer and an lwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

1D tensor of 64-bit signless integer values

rhs

64-bit signless integer

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.batched_add_lwe_buffer` (::mlir::concretelang::Concrete::BatchedAddLweBufferOp)

Batched version of AddLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

lhs

2D memref of 64-bit signless integer values

rhs

2D memref of 64-bit signless integer values

`Concrete.batched_add_lwe_tensor` (::mlir::concretelang::Concrete::BatchedAddLweTensorOp)

Batched version of AddLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

2D tensor of 64-bit signless integer values

rhs

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_add_plaintext_cst_lwe_buffer` (::mlir::concretelang::Concrete::BatchedAddPlaintextCstLweBufferOp)

Batched version of AddPlaintextLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

lhs

2D memref of 64-bit signless integer values

rhs

64-bit signless integer

`Concrete.batched_add_plaintext_cst_lwe_tensor` (::mlir::concretelang::Concrete::BatchedAddPlaintextCstLweTensorOp)

Batched version of AddPlaintextLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

2D tensor of 64-bit signless integer values

rhs

64-bit signless integer

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_add_plaintext_lwe_buffer` (::mlir::concretelang::Concrete::BatchedAddPlaintextLweBufferOp)

Batched version of AddPlaintextLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

lhs

2D memref of 64-bit signless integer values

rhs

1D memref of 64-bit signless integer values

`Concrete.batched_add_plaintext_lwe_tensor` (::mlir::concretelang::Concrete::BatchedAddPlaintextLweTensorOp)

Batched version of AddPlaintextLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

2D tensor of 64-bit signless integer values

rhs

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_bootstrap_lwe_buffer` (::mlir::concretelang::Concrete::BatchedBootstrapLweBufferOp)

Batched version of BootstrapLweOp, which performs the same operation on multiple elements

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

input_ciphertext

2D memref of 64-bit signless integer values

lookup_table

1D memref of 64-bit signless integer values

`Concrete.batched_bootstrap_lwe_tensor` (::mlir::concretelang::Concrete::BatchedBootstrapLweTensorOp)

Batched version of BootstrapLweOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

input_ciphertext

2D tensor of 64-bit signless integer values

lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_keyswitch_lwe_buffer` (::mlir::concretelang::Concrete::BatchedKeySwitchLweBufferOp)

Batched version of KeySwitchLweOp, which performs the same operation on multiple elements

Attributes:

Attribute

MLIR Type

Description

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_in

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_out

::mlir::IntegerAttr

32-bit signless integer attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

ciphertext

2D memref of 64-bit signless integer values

`Concrete.batched_keyswitch_lwe_tensor` (::mlir::concretelang::Concrete::BatchedKeySwitchLweTensorOp)

Batched version of KeySwitchLweOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_in

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_out

::mlir::IntegerAttr

32-bit signless integer attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

ciphertext

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_mapped_bootstrap_lwe_buffer` (::mlir::concretelang::Concrete::BatchedMappedBootstrapLweBufferOp)

Batched, mapped version of BootstrapLweOp, which performs the same operation on multiple elements

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

input_ciphertext

2D memref of 64-bit signless integer values

lookup_table_vector

2D memref of 64-bit signless integer values

`Concrete.batched_mapped_bootstrap_lwe_tensor` (::mlir::concretelang::Concrete::BatchedMappedBootstrapLweTensorOp)

Batched, mapped version of BootstrapLweOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

input_ciphertext

2D tensor of 64-bit signless integer values

lookup_table_vector

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_mul_cleartext_cst_lwe_buffer` (::mlir::concretelang::Concrete::BatchedMulCleartextCstLweBufferOp)

Batched version of MulCleartextLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

lhs

2D memref of 64-bit signless integer values

rhs

64-bit signless integer

`Concrete.batched_mul_cleartext_cst_lwe_tensor` (::mlir::concretelang::Concrete::BatchedMulCleartextCstLweTensorOp)

Batched version of MulCleartextLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

2D tensor of 64-bit signless integer values

rhs

64-bit signless integer

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_mul_cleartext_lwe_buffer` (::mlir::concretelang::Concrete::BatchedMulCleartextLweBufferOp)

Batched version of MulCleartextLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

lhs

2D memref of 64-bit signless integer values

rhs

1D memref of 64-bit signless integer values

`Concrete.batched_mul_cleartext_lwe_tensor` (::mlir::concretelang::Concrete::BatchedMulCleartextLweTensorOp)

Batched version of MulCleartextLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

2D tensor of 64-bit signless integer values

rhs

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.batched_negate_lwe_buffer` (::mlir::concretelang::Concrete::BatchedNegateLweBufferOp)

Batched version of NegateLweBufferOp, which performs the same operation on multiple elements

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

ciphertext

2D memref of 64-bit signless integer values

`Concrete.batched_negate_lwe_tensor` (::mlir::concretelang::Concrete::BatchedNegateLweTensorOp)

Batched version of NegateLweTensorOp, which performs the same operation on multiple elements

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertext

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.bootstrap_lwe_buffer` (::mlir::concretelang::Concrete::BootstrapLweBufferOp)

Bootstraps a LWE ciphertext with a GLWE trivial encryption of the lookup table

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

input_ciphertext

1D memref of 64-bit signless integer values

lookup_table

1D memref of 64-bit signless integer values

`Concrete.bootstrap_lwe_tensor` (::mlir::concretelang::Concrete::BootstrapLweTensorOp)

Bootstraps an LWE ciphertext with a GLWE trivial encryption of the lookup table

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

inputLweDim

::mlir::IntegerAttr

32-bit signless integer attribute

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

glweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

input_ciphertext

1D tensor of 64-bit signless integer values

lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.encode_expand_lut_for_bootstrap_buffer` (::mlir::concretelang::Concrete::EncodeExpandLutForBootstrapBufferOp)

Encode and expand a lookup table so that it can be used for a bootstrap

Attributes:

Attribute

MLIR Type

Description

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

outputBits

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

input_lookup_table

1D memref of 64-bit signless integer values

`Concrete.encode_expand_lut_for_bootstrap_tensor` (::mlir::concretelang::Concrete::EncodeExpandLutForBootstrapTensorOp)

Encode and expand a lookup table so that it can be used for a bootstrap

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

polySize

::mlir::IntegerAttr

32-bit signless integer attribute

outputBits

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

input_lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.encode_lut_for_crt_woppbs_buffer` (::mlir::concretelang::Concrete::EncodeLutForCrtWopPBSBufferOp)

Encode and expand a lookup table so that it can be used for a crt wop pbs

Attributes:

Attribute

MLIR Type

Description

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

crtBits

::mlir::ArrayAttr

64-bit integer array attribute

modulusProduct

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

input_lookup_table

1D memref of 64-bit signless integer values

`Concrete.encode_lut_for_crt_woppbs_tensor` (::mlir::concretelang::Concrete::EncodeLutForCrtWopPBSTensorOp)

Encode and expand a lookup table so that it can be used for a wop pbs

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

crtBits

::mlir::ArrayAttr

64-bit integer array attribute

modulusProduct

::mlir::IntegerAttr

32-bit signless integer attribute

isSigned

::mlir::BoolAttr

bool attribute

Operands:

Operand

Description

input_lookup_table

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

`Concrete.encode_plaintext_with_crt_buffer` (::mlir::concretelang::Concrete::EncodePlaintextWithCrtBufferOp)

Encodes a plaintext by decomposing it on a crt basis

Attributes:

Attribute

MLIR Type

Description

mods

::mlir::ArrayAttr

64-bit integer array attribute

modsProd

::mlir::IntegerAttr

64-bit signless integer attribute

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

input

64-bit signless integer

`Concrete.encode_plaintext_with_crt_tensor` (::mlir::concretelang::Concrete::EncodePlaintextWithCrtTensorOp)

Encodes a plaintext by decomposing it on a crt basis

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

mods

::mlir::ArrayAttr

64-bit integer array attribute

modsProd

::mlir::IntegerAttr

64-bit signless integer attribute

Operands:

Operand

Description

input

64-bit signless integer

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.keyswitch_lwe_buffer` (::mlir::concretelang::Concrete::KeySwitchLweBufferOp)

Performs a keyswitching operation on an LWE ciphertext

Attributes:

Attribute

MLIR Type

Description

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_in

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_out

::mlir::IntegerAttr

32-bit signless integer attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

ciphertext

1D memref of 64-bit signless integer values

`Concrete.keyswitch_lwe_tensor` (::mlir::concretelang::Concrete::KeySwitchLweTensorOp)

Performs a keyswitching operation on an LWE ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

level

::mlir::IntegerAttr

32-bit signless integer attribute

baseLog

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_in

::mlir::IntegerAttr

32-bit signless integer attribute

lwe_dim_out

::mlir::IntegerAttr

32-bit signless integer attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

ciphertext

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.mul_cleartext_lwe_buffer` (::mlir::concretelang::Concrete::MulCleartextLweBufferOp)

Returns the product of a clear integer and a lwe ciphertext

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

lhs

1D memref of 64-bit signless integer values

rhs

64-bit signless integer

`Concrete.mul_cleartext_lwe_tensor` (::mlir::concretelang::Concrete::MulCleartextLweTensorOp)

Returns the product of a clear integer and a lwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

lhs

1D tensor of 64-bit signless integer values

rhs

64-bit signless integer

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.negate_lwe_buffer` (::mlir::concretelang::Concrete::NegateLweBufferOp)

Negates an lwe ciphertext

Operands:

Operand

Description

result

1D memref of 64-bit signless integer values

ciphertext

1D memref of 64-bit signless integer values

`Concrete.negate_lwe_tensor` (::mlir::concretelang::Concrete::NegateLweTensorOp)

Negates an lwe ciphertext

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands:

Operand

Description

ciphertext

1D tensor of 64-bit signless integer values

Results:

Result

Description

result

1D tensor of 64-bit signless integer values

`Concrete.wop_pbs_crt_lwe_buffer` (::mlir::concretelang::Concrete::WopPBSCRTLweBufferOp)

Attributes:

Attribute

MLIR Type

Description

bootstrapLevel

::mlir::IntegerAttr

32-bit signless integer attribute

bootstrapBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

keyswitchLevel

::mlir::IntegerAttr

32-bit signless integer attribute

keyswitchBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchInputLweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchoutputPolynomialSize

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchLevel

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

circuitBootstrapLevel

::mlir::IntegerAttr

32-bit signless integer attribute

circuitBootstrapBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

pkskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

result

2D memref of 64-bit signless integer values

ciphertext

2D memref of 64-bit signless integer values

lookup_table

2D memref of 64-bit signless integer values

`Concrete.wop_pbs_crt_lwe_tensor` (::mlir::concretelang::Concrete::WopPBSCRTLweTensorOp)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Attribute

MLIR Type

Description

bootstrapLevel

::mlir::IntegerAttr

32-bit signless integer attribute

bootstrapBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

keyswitchLevel

::mlir::IntegerAttr

32-bit signless integer attribute

keyswitchBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchInputLweDimension

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchoutputPolynomialSize

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchLevel

::mlir::IntegerAttr

32-bit signless integer attribute

packingKeySwitchBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

circuitBootstrapLevel

::mlir::IntegerAttr

32-bit signless integer attribute

circuitBootstrapBaseLog

::mlir::IntegerAttr

32-bit signless integer attribute

crtDecomposition

::mlir::ArrayAttr

64-bit integer array attribute

kskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

bskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

pkskIndex

::mlir::IntegerAttr

32-bit signless integer attribute

Operands:

Operand

Description

ciphertext

2D tensor of 64-bit signless integer values

lookupTable

2D tensor of 64-bit signless integer values

Results:

Result

Description

result

2D tensor of 64-bit signless integer values

Type definition

ContextType

A runtime context

Syntax: !Concrete.context

An abstract runtime context to pass contextual value, like public keys, ...

2.7

Welcome

Get started

Build with Concrete

Explore more

Explanations

Support channels

Developers

Get Started

What is Concrete?

Installation

Using PyPI

Using Docker

Compatibility

Supported operations

Supported Python operators.

Supported NumPy functions.

Supported ndarray methods.

Supported ndarray properties.

Limitations

Control flow constraints

Type constraints

Bit width constraints

Terminology

Core features

Overview

Operations on encrypted values

Noise and Bootstrap

Probability of Error

Function evaluation

PBS management

Development Workflow

Development

Deployment

Table lookups (basics)

Performance

Direct TLU

Multi TLU

Transparent TLU

TLU on the most significant bits

Advanced features

Bit extraction

Limitations

Performance Considerations

A Chain of Individual Bit Extractions

Reuse of Intermediate Extracted Bits

TLUs of 1b input precision

Compilation

Combining compiled functions

With composition

With modules

Single inputs / outputs

Multi inputs / outputs

Iterations

Runtime optimization

Current limitations

Key-related options for faster execution

Multi parameters

Compression

Reusing arguments

Common errors

1. Could not find a version that satisfies the requirement concrete-python (from versions: none)

2. Only integers are supported

3. No parameters found

4. Too long inputs for table looup

5. Impossible to fuse multiple-nodes

6. Function is not supported

7. Branching is not allowed

Execution / Analysis

Simulation

Overflow Detection in Simulation

Debugging and artifact

Compiler debug and verbose modes

Debug artifacts

Automatic export.

environment.txt

requirements.txt

function.txt

parameters.txt

1.initial.graph.txt

Supported `ndarray` methods.

Supported `ndarray` properties.