TL;DR: To handle large integers in FHE, a common approach is to decompose an integer into several small pieces, called digits, and perform computations based on them. One such approach is the radix-based approach, which decomposes a large integer into digits in base $B$ and carries out arithmetic on those digits via polynomial operations. However, after arithmetic operations, the resulting representation is no longer unique, which makes it difficult to directly perform non-arithmetic operations such as comparison or bitwise operations. The process of restoring such a disturbed digit representation back to its unique form is commonly called digit carry, and this step inherently requires non-arithmetic processing. In this post, we introduce a two-step homomorphic digit carry algorithm over CKKS. Our algorithm restores the digit representation to its unique form using $O(\log k)$ bootstrappings.

Introduction

Recently, the FHE community has shown growing interest in homomorphically evaluating integers of various sizes, ranging from machine-word-sized integers to RSA moduli. Surprisingly, 64-bit arithmetic appears quite simple from the plaintext perspective, much like multiplying two long long variables. In FHE, however, this is not straightforward, because the noise growth typically scales with the message size. Consequently, most existing approaches either maintain a sufficiently large gap between the message and the noise or decompose the message into smaller pieces and express the overall arithmetic through those pieces.

The radix-based approach represents a plaintext integer in base $B$. Once decomposed in this way, an integer can be viewed as a polynomial whose coefficients are its digits, and the original integer is recovered by evaluating that polynomial at $X=B$. As a result, arithmetic on radix-decomposed integers can naturally be carried out through polynomial arithmetic. The key advantage of this approach is that the digit representation still preserves much of the structure of the underlying integer. For example, to compare two integers, one can examine their digits sequentially from the most significant digit to the least significant one. In this sense, radix representations are highly flexible, since they leave room for extending arithmetic to non-arithmetic operations such as comparison.

The main challenge is that while polynomial arithmetic preserves the value of the represented integer, it does not preserve the uniqueness of its digit representation. After arithmetic operations, digit values may exceed their normal range, which in turn causes additional noise growth. More importantly, once the digit representation is no longer unique, non-arithmetic operations such as comparison can no longer be performed directly. Therefore, radix-based approaches must restore the non-unique digit representation to its unique form through digit carry.

This carry procedure, however, has remained a major bottleneck, since it inherently requires remainder computation and must process the digits sequentially. Although [1, 2] achieved homomorphic digit carry using discrete CKKS, the number of required bootstrappings remained linear in the plaintext bit-length $k$. This naturally leads to the following question: can this linear cost be reduced further?

Notation. Throughout this post, we adopt the following notation for clarity. We denote homomorphic arithmetic operations between ciphertexts simply as $+,-,\times$. In addition, we denote the rotation operation by $\rho_r$, which rotates a ciphertext to the left by $r$ positions. If $r$ is negative, this corresponds to a right rotation.

Key idea: reducing carry in base $B$ to carry in base $2$.

Our key idea for reducing the complexity of the carry algorithm is the following:

If every digit is smaller than $2B-1$, then carry propagation on a radix-$B$ digit vector behaves exactly like carry propagation in binary.

To see why, recall that in base-$B$ carry, if the $i$-th digit $z_i$ is at least $B$, we propagate \(y_i = Q_B(z_i)\) to the next digit, where $Q_B(z_i)$ denotes the quotient of \(z_i\) divided by $B$. The difficulty is that once \(y_i\) is added to the $(i+1)$-th digit, the carry propagated to the $(i+2)$-th digit becomes $ Q_B(z_{i+1} + y_i), $ so the carry process becomes inherently sequential.

However, if every digit is smaller than $2B-1$, then a much simpler structure emerges. In this case, $Q_B(z_i)$ can be at most $1$. Consequently, $z_{i+1}+y_i$ is also at most $2B-1$, and therefore the carry propagated to the next digit is again at most $1$. Intuitively, this makes radix-$B$ carry behave like binary carry, where each position propagates only a single carry bit.

At this point, our problem boils down to the following two tasks:

1. Homomorphically reducing each digit so that it is smaller than \(2B-1\).
2. Designing a carry algorithm for digit vectors whose entries are all smaller than \(2B-1\).

2-step carry algorithm

Polynomial arithmetic. Since CKKS supports SIMD-style parallel operations across slots, a different method is needed to realize polynomial arithmetic. We simply use the DFT to evaluate polynomials in Fourier form, and then apply the iDFT to recover the result in coefficient form.

When the plaintext modulus is \(\mathbb{Z}_{B^k}\), a single integer is packed into \(2k\) slots: the first \(k\) slots contain its radix-\(B\) digits, while the remaining \(k\) slots are padded with zeros. This zero-padding is introduced to avoid cyclic shifts. Accordingly, after the iDFT step, the lower \(k\) slots are masked out and reset to zero.

Let the number of CKKS slots be \(N/2\), and assume that \(2k \mid (N/2)\). Then a single ciphertext can store a total of \(N/4k\) integers, where the packing is obtained by simply concatenating digit vectors of length \(2k\).

Modular reduction in CKKS. Modular reduction, as discussed in [3, 4], is a key operation in our construction. At a high level, this algorithm first transforms a slot-encoded CKKS ciphertext into coefficient encoding, reduces it modulo the base modulus \(q_0\), and then applies bootstrapping to recover a slot-encoded CKKS ciphertext.

The interesting point is that if the ciphertext scaling at level \(q_0\) is adjusted to \(q_0/B\), then the resulting ciphertext has exactly the same form as a coefficient-encoded BFV ciphertext with plaintext modulus \(B\). Consequently, the message naturally undergoes the operation \([\cdot]_B\), while requiring only a single bootstrapping. For convenience, we denote the modular reduction algorithm with respect to \(B\) by \(\mathsf{Mod}_B\).

Functional bootstrapping in CKKS. Functional bootstrapping [3, 5] in discrete CKKS enables the evaluation of a look-up table (LUT) function, denoted as $\mathsf{LUT}$, simultaneously with the bootstrapping of a ciphertext.

We denote the functional bootstrapping operation in CKKS by $\mathsf{CKKS.FBT}(\cdot,~\mathsf{LUT} = \cdot)$, where the first argument is the ciphertext to be bootstrapped and the second argument specifies the LUT function.

Homomorphic digit reduction

After arithmetic operations, we repeatedly invoke \(\mathsf{Mod}_B\) to reduce the digit size. Let the input digit vector be

Here, we omit the last \(k\) slots for simplicity.

Applying \(\mathsf{Mod}_B\) yields

Moreover, since \(Q_B = \frac{\mathsf{id}-\mathsf{Mod}_B}{B},\) we can additionally obtain, at the cost of one extra multiplication level,

Now, by rotating \(\mathsf{ct}_{Q}\) one position to the right and adding it to \(\mathsf{ct}_{\mathsf{mod}}\), we obtain another digit vector representing the same integer. If \(\|\vec z\|_{\infty}=U\), then the infinity norm of the resulting digit vector is bounded by \(B + Q_B(U) = B + O(U/B).\)

We call this entire procedure LazyCarry.

For the unique digit representations of two integers, no digit reduction is needed after addition. In contrast, after multiplication, invoking LazyCarry \(O(\log k)\) times suffices to reduce all digit values below \(2B-1\).

In practice, for \(B=16\), multiplying two integers in unique digit representation requires only 2 to 4 bootstrappings to reduce all digit values below \(2B-1\), for bit-lengths ranging from 16 bits to 2048 bits. If a larger base \(B\) is chosen, this number can be reduced even further.

Repeated iterations of LazyCarry reduce the digit size rapidly, making it possible to continue arithmetic operations once the digits become sufficiently small. This is in the same spirit as [2].

Homomorphic digit carry

We now take a closer look at the carry behavior of digit vectors whose entries are all smaller than \(2B-1\). The figure illustrates the case \(B=16\) and \(k=4\): the top shows carry propagation in base \(B\), while the bottom shows the corresponding carry behavior after reduction to binary.

Under this constraint, whenever the \(i\)-th digit propagates a value to the next digit, the \(i\)-th digit decreases by \(B\) and the \((i+1)\)-th digit increases by \(1\). This is exactly the same behavior observed in the binary-reduced representation.

Therefore, if we can obtain a ciphertext encrypting a vector $\vec c$ whose entries indicate whether each digit propagates a carry to the next position—encoded as $1$ for true and $0$ for false—then the unique carried representation of the original digit vector $\vec z$ can be computed as follows :

For example, in the figure, $\vec c = (1,1,1,0)$.

Reduction from a radix-\(B\) representation to a binary representation is performed via a LUT operation. The binary reduction is determined by the range of each digit; more precisely, we define

It remains to design a function that determines, in the binary-reduced representation, whether a given digit propagates a value to the next position.

We begin with the two-digit case \(z_1,z_2\), and design a function that determines whether \(z_2\) propagates a carry to the next digit.

If \(z_2=0\), then even if \(z_1=2\) and propagates a carry into \(z_2\), the resulting value is still smaller than \(2\), and hence the output is \(0\). If \(z_2=2\), then for the same reason the output is always \(1\), regardless of the value of \(z_1\). The only nontrivial case is \(z_2=1\). In that case, the output depends on \(z_1\): if \(z_1=2\), the output should be \(1\); if \(z_1=0\), it should be \(0\); and if \(z_1=1\), the output depends on the previous digit. In the two-digit example, this case evaluates to \(0\).

Motivated by this observation, we design a bivariate function \(f(x,y)\) that returns \(0\) if carry propagation is false, \(2\) if it is true, and \(1\) if the result is not yet determined:

We then extend this to a \(k\)-digit vector \((z_1,\dots,z_k)\). The question of whether \(z_k\) propagates a carry to the next position (the case \(i<k\) will be discussed shortly) can be expressed recursively using rotations via the function \(f_k\):

At first glance, evaluating \(f_k\) appears to require \(k\) sequential calls to \(f\). However, observing that the structure of \(f\) is determined by its second argument, one can show that

Since the digits \(z_1,\dots,z_k\) are stored across multiple slots, this allows us to evaluate \(f_k\) using only \(\log k\) invocations of \(f\).

For the \(i\)-th digit with \(i\le k\), the first \(k-i\) slots correspond to zero-padded slots from the previous integer. Hence it suffices to evaluate

since zeros do not affect the carry behavior at all. The figure below illustrates the evaluation of $f_k$ for $k = 4$.

After evaluating \(f_k\), the positions that propagate a carry contain the value \(2\), while the remaining positions contain \(0\) or \(1\). We then evaluate a mapping function \(\tau\) that converts these values into \(1\) and \(0\), respectively. Finally, by applying \(\tau\) and evaluating Equation (1), the carry procedure is completed. We call this overall procedure LazyCarry-to-Carry.

Whole algorithm description

The overall procedure of our two-step homomorphic carry algorithm is as follows.
Let $\mathsf{ct}$ be a ciphertext that requires digit carry propagation.
We assume that an upper bound on the corresponding digit vector of $\mathsf{ct}$ can be estimated.
Given this bound, let $t$ denote the number of times the LazyCarry algorithm is applied to ensure that each digit becomes smaller than $2B - 1$.

For example, consider a 64-bit multiplication with parameters $(B,k) = (2^4, 16)$.
When multiplying two unique digit representations, the resulting upper bound is given by \(k(B-1)^2 = 3600.\) In this case, two iterations of LazyCarry are sufficient.

1. Repeat LazyCarry $t$ times : \(\mathsf{ct}_{\mathsf{lazycarry}} \gets \mathsf{LazyCarry}^{(t)}(\mathsf{ct})\)

2. Evaluate the look-up table $\phi$ via functional bootstrapping : \(\mathsf{ct}_{\mathsf{bin}} \gets \mathsf{CKKS.FBT}(\mathsf{ct}_{\mathsf{lazycarry}}, \mathsf{LUT}=\phi)\)

3. Evaluate $f_k$ : For $i=0$ to $\log(k)$ do {\(\mathsf{ct}_{\mathsf{bin}} \gets \text{evaluate } f(\rho_{-2^i}(\mathsf{ct}_{\mathsf{bin}}), \mathsf{ct}_{\mathsf{bin}})\)}

4. Evaluate $\tau$ : \(\mathsf{ct}' \gets \tau(\mathsf{ct}_{\mathsf{bin}})\)

5. Return \(\mathsf{ct}_{\mathsf{out}} \gets \mathsf{ct}_{\mathsf{lazycarry}} - B\cdot \mathsf{ct}' + \rho_{-1}(\mathsf{ct}')\)

Our algorithm performs (t) bootstrappings in Step 1, one bootstrapping in Step 2, and additional bootstrappings in Step 3. The extra bootstrappings in Step 3 arise in two cases: (1) when the remaining multiplicative depth is insufficient to evaluate the function (f_k), or (2) when bootstrapping is required for noise management. Despite these additional calls, the total number of bootstrappings remains modest in practice. The exact number of bootstrapping calls is reported in the Conclusion section.

Other integer operations

Because the digit vector can be restored to its unique representation, one can further design non-arithmetic operations such as comparison and conditional subtraction. Moreover, by using the bit-extraction technique of [5], each digit can be decomposed into bits, thereby enabling bitwise operations as well. These non-arithmetic operations can in turn be used to homomorphically implement reduction techniques such as folding and Montgomery reduction, thereby supporting computation not only over prime-power moduli but also over more general moduli. Although we would have liked to discuss these non-arithmetic operations in this post as well, we refer the interested reader to the paper for further details.

Conclusion

All experiments were conducted on an AMD Ryzen 9 7900X 12-Core Processor with 125 GB RAM, running Ubuntu 20.04, using a single thread. We used the Lattigo library, a representative RNS-CKKS library, for our implementation.

We evaluated multiplication operations for bit-lengths ranging from 16 bits to 2048 bits. In the third column, (a+b) indicates that (a) bootstrappings were used in LazyCarry and (b) bootstrappings were used in LazyCarry-to-Carry.

To be completely honest, a single multiplication still took a considerable amount of time. Even though our method processes many integers at once, the total runtime is by no means small.

At first glance, BFV may appear more attractive, as homomorphic multiplication can be performed simply by invoking the scheme’s native multiplication primitive. However, the main bottleneck of BFV lies in bootstrapping, whose runtime may exceed that of our entire multiplication procedure depending on the plaintext modulus. Therefore, a fair comparison should not be based solely on raw multiplication speed, but rather should account for the cost of BFV bootstrapping.

For instance, according to Table 4 in [6], BFV bootstrapping with a plaintext modulus of approximately 234 bits at $N = 2^{17}$ takes about 392 seconds. In contrast, our proposed framework enables subsequent computations after a single additional CKKS bootstrapping (approximately 12 seconds).

From an amortized perspective, a more careful comparison is also needed, since the number of available BFV slots depends on the plaintext modulus.

For DM/CGGI, by contrast, our method consistently shows better amortized performance. Interestingly, at the time of writing, our single-thread benchmark on the same machine showed that TFHE-rs required 77.5 seconds for 128-bit multiplication, whereas our method took 57.4 seconds. This indicates that from 128 bits onward, our method outperforms TFHE-rs not only in amortized throughput but also in latency.

Finally, we conclude by introducing a paper for readers interested in related work [7]. While our work focuses on algorithms for performing carry homomorphically, the work introduced below is particularly impressive in that it avoids performing carry altogether.

References

[1] Kim, J. “Efficient Homomorphic Integer Computer from CKKS.” TCHES 2025.

[2] Kim, J. “Faster Homomorphic Integer Computer.” Cryptology ePrint Archive, Paper 2025/1440, 2025.

[3] Alexandru, A., Kim, A., and Polyakov, Y. “General Functional Bootstrapping using CKKS.” CRYPTO 2025.

[4] Kim, J. and Noh, T. “Modular Reduction in CKKS.” CIC 2025.

[5] Bae, Y., Kim, J., Stehlé, D., and Suvanto, E. “Bootstrapping Small Integers with CKKS.” ASIACRYPT 2024.

[6] Kim, J., Seo, J., and Song, Y. “Simpler and Faster BFV Bootstrapping for Arbitrary Plaintext Modulus from CKKS.” CCS 2024.

[7] Brakerski, Z., Friedman, O., Golan, D., Gurny, A., Mutzari, D., and Sheinfeld, O. “REFHE: Fully Homomorphic ALU.” EUROCRYPT 2026.

• Written by Ignacio Cascudo (IMDEA Software Institute), Anamaria Costache (École Polytechnique), Daniele Cozzo (IMDEA Software Institute), Dario Fiore (IMDEA Software Institute), Antonio Guimarães (IMDEA Software Institute), Eduardo Soria-Vazquez (Technology Innovation Institute)
• Based on https://ia.cr/2025/286 (Crypto 2025)

TL;DR: Homomorphic Encryption (HE) enables computing over encrypted data but, by itself, provides no guarantees that the computation was honestly executed. One can build “Verifiable HE” (vHE) using SNARKs, but efficiently combining HE and SNARKs in practice is a major challenge. This work introduces a blueprint for building verifiable HE schemes and its efficient instantiation for CKKS. Our first step is to introduce a “proof-friendly” version of CKKS, which is more amenable to proof systems, while being only slightly slower than typical RNS CKKS implementations. We then show how the problem of proving correctness of computations for such proof-friendly HE schemes can be reduced to just two sets of arithmetic relations (containing equalities and inequalities). We show that if these are satisfied, it implies the correct execution of the HE evaluation. We design Polynomial Interactive Oracle Proofs (PIOPs) for efficiently proving these relations, and we show how they can be instantiated using standard proof components. Our final construction demonstrates the feasibility of building SNARKs for proving computation of full-fledged HE schemes, opening the path for building practical verifiable HE schemes.

Context

Homomorphic Encryption. Homomorphic Encryption (HE) is a type of encryption that allows to compute on encrypted data. This allows, amongst others, to outsource computations without compromising on privacy. It is a very powerful primitive, which enables many applications such as secure outsourced medical analysis, private set intersection, and so on. In recent years, Machine Learning (ML) applications have become ubiquitous. While this has opened up the door to many novel and powerful applications, this has also introduced privacy concerns. Indeed, ML applications inherently and very heavily rely on data - but this data can turn out to be sensitive, and users may rightly be weary of sharing their private data with companies. To the rescue comes HE, in the form of Privacy-Preserving Machine Learning (PPML)! With HE, we can now encrypt the data, and evaluate an ML model directly on encrypted data. The result can now be recovered in plaintext, but only by whoever holds the secret key.

Verifiable Homomorphic Encryption. A significant limitation of homomorphic encryption (HE) is that it works in the trusted model, where the entity that computes over the ciphertexts is assumed to behave honestly. In particular, we must assume that the computing party (from here on, we refer to this party as the server) performs exactly the operation it says it does, which in practice is a rather strong assumption. In reality, without an integrity mechanism on top of the computation, the server could follow any malicious strategy: it could for example bias the result, or perform a different computation entirely. Even more concerning, without integrity mechanisms in place, the server could take advantage of the malleability of HE ciphertexts and mount a key recovery attack. Therefore, a lack of integrity can potentially lead to serious privacy leaks!

SNARKs

Succinct proof systems (commonly referred to as SNARKs) are an important cryptographic primitive that allow to add integrity to computations. Informally, these are cryptographic proofs that allow a prover to convince a verifier that a statement is true. This is a very rich research field in and of itself, so for now, we can think of SNARKs as tools that allow us to prove a statement of the following kind: “Given a public circuit $C$ and an output $y$, I know an input $x$ such that $y=C(x)$.”

What makes SNARKs useful in practice are the following properties:

• Correctness: if the statement is true, then the verifier will accept the proof;
• Soundness: a cheating prover is not able to convince the verifier about a false statement, except with negligible probability;
• Succinctness: the proof is very short and verifying it should be fast, e.g. sublinear in the size of the computation.

Verifiable HE

It is natural then to combine SNARKs and HE to achieve both privacy and integrity in outsourcing computations. This approach, also known as Verifiable Homomorphic Encryption (vHE) does work in theory, because SNARKs can prove NP statements. Unfortunately, in practice this approach has several limitations for the prover efficiency.

1) HE ciphertexts are typically pairs of elements of the polynomial ring $R_q = \mathbb{Z}_q[X]/{(X^{N}+1)}$, whereas SNARKs typically work best on computations over large finite fields;

2) Virtually all HE schemes require so-called ciphertexts maintenance operations (such as rescaling). These operations entail non-algebraic operations, for instance real division and rounding. In contrast, SNARKs shine at proving algebraic statements. Even worse, operations like rescaling cause the underlying algebraic structure to change during the computation, something that cannot be easily processed by traditional SNARKs.

Naively, general-purpose SNARKs can prove ciphertext arithmetic and maintenance operations by emulating them. This is prohibitively expensive for the prover, as shown by a recent survey by Knabenhans, Viand, and Hithnawi [4].

This motivates the research line of designing SNARKs specifically tailored to HE operations.

In this blogpost, we introduce our recent result [1] that represents the state-of-the-art in this direction. Our work is a blueprint for constructing vHE schemes that can scale with large computations and have practical proving times.

The blueprint

The core contributions of our work are a blueprint for constructing practical vHE schemes in a modular way and its instantiation to the CKKS scheme. Such a framework consists of several building blocks that are carefully designed to be combined together to yield the final vHE scheme.

The first step in our blueprint is to take an HE scheme, and modify it in such a way that it becomes more “SNARK-friendly”. The aim is to make arithmetization easier – that is to say, we aim to make the operations of the HE scheme easily expressed in a language that can then be processed by the SNARK with small overhead. We call such a scheme “proof-friendly”. In practice, such a scheme must work over a single ring with specific algebraic structures that are necessary for the SNARKs to achieve soundness. In this work, we instantiate our blueprint using the CKKS scheme, introducing a proof-friendly variant of CKKS.

Once we have a proof-friendly HE scheme, a computation over its ciphertexts is processed according to the following steps:

• Translation: The arithmetization process translates the computation into an arithmetic circuit satisfiability relation over the ring, and a finite number of range check relations over the ring. This is the language our SNARK “speaks”.
• Proofs: These relations will be proved by specialized proof systems, in the form of Polynomial Interactive Oracle Proofs (PIOPs). PIOPs are proof systems where the interaction between the prover and verifier happens via polynomials: the statements are encoded by long polynomials and the proof consists in evaluating these over points chosen uniformly at random by the verifier. Importantly, PIOPs differ from SNARKs in that they are interactive, are not succinct (meaning that the proof is typically long, of the size of the statement) and soundness holds information-theoretically. A popular and practical way of realizing SNARKs, which we follow, consists in first designing PIOPs, and then compiling them into full-fledged SNARKs through cryptographic tools (we will talk about this in a moment). In our case, we need two PIOPs: one that is specialized to prove arithmetic statements over rings, and one specialized to prove range checks over rings.
• Cryptographic compiler: Finally, in order to compile these information-theoretic protocols into a SNARK we need one more tool, called a Polynomial commitment (PC) scheme. This is a primitive that allows the prover to commit to a large polynomial resulting in a short string, and to later prove evaluations of the committed polynomial. Polynomial commitment schemes are used to compile PIOPs into SNARKs: the long polynomials resulting from the prover PIOP are replaced by the short commitments.

Proof-friendly CKKS

We start by showing how we can build a proof-friendly version of CKKS which presents the characteristics described above while maintaining near state-of-the-art performance levels.

Setting up the ring

CKKS works over polynomial rings of the form $R_q := \mathbb{Z}_q[X]/(X^N+1)$. The first step is to set up the ring $R_q$ such that it will be easier to construct a SNARK over it. Remember, one of the properties a SNARK must satisfy is soundness: this says that if the statement is false, then the prover is only able to convince the verifier with negligible probability.

Naively, a way to achieve this is to just repeat the proof system as many times as needed, to amplify soundness error. However, this makes the proof much larger, and one might need many repetitions to achieve negligible soundness error. The alternative is to choose the ring $R_q$ in an appropriate way, so that no repetitions are needed.

The second requirement is, of course, efficiency. We want the prover to be fast while performing the CKKS operations. For that reason, as is typical in HE, we invoke the Chinese Remainder Theorem (CRT). Let $N$ be a power of two and $q:= \prod_{i=0}^L p_i$ for some integer $L$, such that each $p_i$ is a prime of the form $2aN/d + 1$ for some odd integer $a$ and suitable power-of-two value $d$. Then, for each $p_i$, the cyclotomic polynomial $X^N+1$ splits in \(\mathbb{Z}_{p_i}[X]\) into $k = N/d$ irreducible factors \(X^N + 1 = \prod_{j=0}^{k-1}(X^d - \zeta^{(2j+1)}),\) where \(\zeta\in\mathbb{Z}_{p_i}\) is a \(2N/d\)-th primitive root of unity. By the CRT, the ring \(R_{q}\) splits as

with each \(R_{i,j} = \mathbb{Z}_{p_i}[X]/(X^d - \zeta^{(2j+1)})\) being a field of size $p_i^d$.

The value $d$ will be chosen appropriately so as to guarantee soundness security. For brevity, we omit a detailed discussion on choosing the value $d$, but note that typical choices for $d$ would be $d=2$, or $d=4$. We refer to [1] for details on efficient arithmetic over the rings these choices entail.

Algorithms

Now that we have set up the underlying ring $R_q$, we are ready to describe the main algorithms for our proof-friendly CKKS. In more detail, we present a modified version of the CKKS scheme. At a high level, these modifications aim to get around of the hurdles which makes CKKS incompatible with SNARKs, namely the fact that the ring changes during the computation. In our version of CKKS, the algorithms will always work on the same underlying ring $R_q$. The trick that makes this possible is a modification of the CRT map underlying the RNS version of CKKS, which we show now.

For all $0 \leq j \leq L$ define $q_j = \prod_{i=0}^{j} p_{i}$, and in particular $q_L = q$. Then we define \(R := \mathbb{Z}[X]/(X^N+1)\) and \(R_{q_j} := \mathbb{Z}_{q_j}[X]/(X^N+1)\) for all $0 \leq j \leq L.$ Let $\omega_{j} = (p_0, p_1, \dots, p_{j})$ be a CRT base for $q_j$ and given $a \in R_{q}$, we define the inverse CRT map as follows:

Note that, in general, the inverse CRT for $\omega_j$ would be defined as a map $R_{q} \rightarrow R_{p_0} \times \ldots \times R_{p_j}$. We slightly modify this, by adding an embedding from $R_{p_0} \times \ldots \times R_{p_{j}}$ to $R_{q}^{j+1}$. More precisely, our mapping looks like:

where, using RNS representation,

Letting $Q_{i} = q_L/p_i$ and \(\hat{Q}_{i} = \left[(q_L/p_i)^{-1}\right]_{p_i}\) be the usual constants for CRT recomposition, we define

For each $0 \leq j \leq L$, the CRT recomposition vector for a given $a \in R_{q}$ is:

For any $a, b \in R_{q}$, for any $j$, the following holds

This follows from a direct application of the CRT in the ideal defined by $z_j$.

We are ready to describe the algorithms defining our proof-friendly version of CKKS. Let $q_{0} < q_{1} < \dots < q_{D-1}$ be a chain of moduli for a circuit of depth $D$ and $(\omega_{0}, \omega_{1}, \dots, \omega_{D-1})$ their respective CRT bases, $\chi_\text{key}$ be the secret key distribution over $R$, and $\chi_\text{err}, \chi_\text{enc}$ be discrete Gaussian distributions over $R_{q}$. Below we present our version of the CKKS scheme. For brevity, we only present the algorithms which are different from “regular CKKS”.

• $\mathsf{EvalKeyGen}:$ Let the secret key be $s$, and assume we are performing a key switching from $s^2$ to $s$. Sample $a_i \leftarrow R_{q}$, sample $e_i \leftarrow \chi_\text{err}$ for $i= 0, \dots, L$. Compute $b_i = - a_i \cdot s + e_i + PW_{\omega_{L}}(s^2)[i]$ $\bmod q$. For each level $l \in { 0, \dots, D - 1}$, compute

Notice that all key switching keys are generated in $R_{q}$ for all levels, but we manually change levels by moving them to the ideals defined by $z_l$. In practice, zeroed RNS components do not need to be processed, yielding similar performance as typical RNS implementations.

• $\mathsf{Mult}(ct_0, ct_1, l):$ Multiplication of two ciphertexts $ct_0 := (ct_0[0], ct_0[1])$, $ct_1 := (ct_1[0], ct_1[1])$ at the same multiplicative level $l$ goes as follows. First a pre-multiplication performs a polynomial multiplication

  $$ (d_0, d_1, d_2) := (ct_0[0] \cdot ct_1[0], ct_0[0] \cdot ct_1[1] + ct_1[0] \cdot ct_0[1], ct_0[1] \cdot ct_1[1]) \in R_q^3. $$
  $$\begin{aligned} (d_0, d_1, d_2) := \big(ct_0[0] \cdot ct_1[0], ~~~~~~~~~~~&\\ ct_0[0] \cdot ct_1[1] + ct_1[0] \cdot ct_0[1], &\\ ct_0[1] \cdot ct_1[1] \big) \in R_q^3. & \end{aligned}$$

  Then, we perform the key switching as follows.

  $$ D_i := d_i + \langle CRT_{\omega_l}^{-1}(d_2), \mathfrak{evk}_{l,i} \rangle \in R_{q}, \quad i=0,1. $$
  $$\begin{aligned} D_i := d_i + \langle CRT_{\omega_l}^{-1}(d_2), &\mathfrak{evk}_{l,i} \rangle \in R_{q},\\ \text{ for } i=0,1.~& \end{aligned}$$

  Then we re-scale $D_0, D_1$ as follows. Let \(p_l^{-1} = \left[q_{l+1}/q_{l}\right]_{q_{j+1} } \cdot z_l \in R_{q}\). Then compute and output the final ciphertext

  $$ c_i := \left( D_i - \left[D_i\right]_{p_l}\right) p^{-1}_l \in R_{q},\quad i=0,1. $$
  $$\begin{aligned} c_i := \left( D_i - \left[D_i\right]_{p_l}\right) p^{-1}_l \in R_{q},&\\ \text{ for } i=0,1.~~~~~~~~~~~~~~~& \end{aligned}$$

A detailed noise analysis can be found in the full version of our paper. We omit it here for brevity, but we show that our CKKS incurs at most one additional bit of noise.

Arithmetization

Now that we have a proof-friendly HE scheme, we describe how we can translate it into a finite set of relations over $R_q$, which, if satisfied, imply the correct execution of the scheme. Although we focus specifically on our (proof-friendly) CKKS additions and multiplications, we note that this process could be extended to any operations or schemes satisfying our desirable “proof-friendly” characteristics.

Additions

Let two ciphertexts \(a = (a_0, a_1)\), \(b=(b_0, b_1) \in R_q^2\) be at the same level $l$. Adding $a$ and $b$ can be readily expressed as an arithmetic circuit satisfiability relation over $R_q$, since the resulting ciphertext \(c = (c_0, c_1) := (a_0 + b_0, a_1 + b_1)\) is simply the component-wise addition of $a$ and $b$ over $R_q^2$.

Multiplications

Suppose that now we want to multiply the ciphertexts $a$ and $b$. That means that the ciphertexts $a, b$ are actually elements in $R_{q_l}$, although our CKKS treats them as elements in $R_q$. We know that a CKKS multiplication is composed of a pre-multiplication, followed by a key switching and finally by a rescaling. Let’s analyze each of these operations in turn.

Pre-multiplication can be easily expressed as a sequence of arithmetic operations over $R_q$:

For the key switching

we come across the first obstacle. The term \(\langle \mathfrak{evk}_0\), \(CRT^{-1}_{\omega_l}(d_2) \rangle\) involves expressing $d_2$ with respect to the RNS basis \(\omega_l\), which is not an arithmetic operation. Instead of proving the decomposition, we let the prover give the verifier the outcome of the decomposition. In other words, the prover sends inputs \(w_{ks, 0}, \dots, w_{ks, l} \in R_q\) satisfying

that is to say, they recompose to $d_2$ under the CRT map, and

which means that they are bounded by the RNS primes of the basis $\omega_l$ (remember we are at level $l$). In other words, (4) and (5) prove that the new inputs are indeed the CRT decomposition of $d_2$, and thus they can be used in (2) to compute the values $D_i$’s and continue the computation. Next is modulus switching

Note that this is just a component-wise Euclidean division of $D_i$ by $p_l$. Using the same strategy as above, we let the prover introduce values $w_{quo, 0}, w_{quo, 1}$ and $w_{rmd, 0}, w_{rmd, 1}$ and prove that these are the quotients and remainders for the above equations. Specifically, the prover shows that

and

and

Putting (2), (3), (4) and (6) together, these are equivalent to the following arithmetic circuit satisfiability relation over $R_q$:

and $l+5$ range check relations over $R_q$:

We have shown how to arithmetize a single addition and multiplication. A similar but much more involved argument can be done for a general circuit made of CKKS additions and multiplications. The strategy is to organize the CKKS circuit into mutiplicative layers, where consecutive additions are grouped together and are followed by the multiplication gate. Now instead of single $R_q$ values, one has to reason with $R_q$ vectors. For the details, we refer to Sec. 4 of our paper.

To summarize

To recap, our proof-friendly CKKS has the following properties that make it particularly suitable for proof systems:

1) A carefully designed underlying ring which gives large enough exceptional sets while keeping arithmetic fast;

2) This ring does not change during the computation, thanks to our re-design of the rescaling algorithm;

3) A scheme design for which a noise analysis proves it allows looser bounds, which in turn enables batching of range proofs.

At this point, one might ask: do these modifications have an impact on efficiency? After all, we do not change rings in our proof-friendly CKKS so, in particular, the ciphertext size does not decrease as we go through homomorphic computations. As it turns out, staying in the same ring does not impact the efficiency of CKKS operations! Intuitively, this is because we re-embed the ciphertexts into the initial ring $R_q$ by zero-ing the relevant slots in the RNS representation. The prover sees those zeros and simply ignores them: after all, operations involving zeros do not change the result.

We implemented and benchmarked our proof-friendly version of CKKS. We show that our proof-friendly CKKS implementation only introduces an overhead of up to 20% for ciphertext multiplications over a “regular” instantiation of the scheme, while still being faster than commonly used libraries such as HELib. This slowdown is mainly due to the use of incomplete NTT. The source code is available on GitHub.

A first instantiation

The framework we propose reduces the problem of proving CKKS operations to the problem of designing PIOPs for two specific relations: arithmetic circuit satisfiability over $R_q$ and range checks for $R_q$ vectors. This problem can now be solved with the use of black-box components, making our solution highly modular. In the paper, we make some specific choices for providing a first instantiation that could concretely demonstrate practical feasibility. By themselves, some of these components are also independent contributions, as we designed them to exploit the particular characteristics of our arithmetic structures. Ultimately, however, one could pick and choose different instantiations, and in doing so, optimise for different efficiency metrics.

Our instantiation of the framework consists of the following components:

• Arithmetic circuit relations are proven with a “custom” version of the GKR protocol [2] over rings. This variant crucially takes advantage of the particular structure of the circuit induced by our previous arithmetization, which results in a GKR circuit of constant depth (consisting of only $4$ layers), independent of the size or depth of the HE circuit.
• Range checks are proven using lookup arguments, i.e., a proof that convinces the verifier that a value belongs to a table of values $T_B$. For example, this table may include values within a certain range $B$. However, since CKKS requires to check large bounds (e.g., $B$ can have between $50$ and $300$ bits, depending on the level), and the ring dimension is concretely large (typically \(N \in \{2^{13}, 2^{17}\}\)) the public table $T_B$ would be too large to even represent. To overcome this issue, we rely on the recent decomposition technique of Lasso [5], that consists in splitting a large table into smaller ones, so that one can efficiently perform look-ups into them.
• The last component for building a succinct argument is a polynomial commitment for multilinear polynomials over $R_q$, since those are used to encode the messages sent by the prover in our PIOPs. First, we use the splitting (1) of $R_q$ into the product of finite fields to reduce the problem of designing a PC for multilinear polynomials over $R_q$ into that of designing PCs for multilinear polynomials over finite fields. The second contribution here is to use a field-agnostic PC, Brakedown [3], and modify it in such a way that we can use the limited algebraic structure of our fields to gain in efficiency.

Future work

The relevance of our framework is mainly on the abstraction level. We are able to provide a blueprint for constructing vHE schemes where verification is asymptotically fast and the prover can potentially scale up well with the size of the circuit. Our blueprint is realized in a modular way by combining specific building blocks. We instantiate these by modifying and optimizing recent constructions from proof systems literature. We demonstrate that our building blocks can be practically instantiated. Compared to previous literature, our results for small (depth-1) circuits indicate similar performance levels as [4], which was the state of the art on concrete performance for verifiable RNS HE schemes. However, contrary to [4], we verify full-featured RNS-based leveled HE schemes, including key switching and rescaling operations, which enables our solution to scale to larger circuits. In contrast, the performance in the previous approach [4] would deteriorate exponentially with the circuit depth.

The interested reader can also check online the recordings of our talks:

• For an FHE introduction check the talk at FHE.org
• For a more SNARK-y perspective check the talk at ZKProof

The next challenge is of course practical: to show that our framework is really able to scale up with large circuits. So stay tuned!

References

[1] I. Cascudo, A. Costache, D. Cozzo, D. Fiore, A. Guimaraes and E. Soria-Vazquez. “Verifiable Computation for Approximate Homomorphic Encryption Schemes.” CRYPTO 2025.

[2] S. Goldwasser, Y. T. Kalai, and G. N. Rothblum. “Delegating Computation: Interactive Proofs for Muggles.” Journal of the ACM 2015.

[3] A. Golovnev, J. Lee, S. T. V. Setty, J. Thaler, and R. S. Wahby. “Brakedown: Linear-time and Field-agnostic SNARKs for R1CS.” CRYPTO 2023.

[4] C. Knabenhans, A. Viand, and A. Hithnawi. “Towards Robust FHE for the Real World.” Real World Crypto 2024.

[5] S. T. V. Setty, J. Thaler, and R. S. Wahby. “Unlocking the Lookup Singularity with Lasso.” EUROCRYPT 2024.

TL;DR: Orion is a framework that compiles PyTorch neural network models into efficient CKKS FHE programs for encrypted inference. Orion automatically handles low-level FHE details such as data packing, bootstrap placement, and precision management. Orion is open-sourced at: https://github.com/baahl-nyu/orion.

1. Introduction

The CKKS FHE scheme enables cryptographically secure outsourced computing, which has broad implications for areas such as health or finance. However, writing FHE programs, especially FHE neural networks, remains a challenge given the low-level primitives that CKKS exposes: addition, multiplication, and rotation of encrypted vectors. Furthermore, auxiliary FHE operations that are necessary for deep computations (such as bootstrapping and scale management) only make this harder.

A user of FHE might ask: How and when should bootstraps be placed during inference? What FHE algorithm should be used for computing convolutions? How can we approximate non-linear activations? In this blog, we introduce our framework Orion, which handles each of these issues automatically, making it easier to write FHE neural network programs. The figure below describes three key aspects we had in mind when building Orion.

Figure 1: Orion's high-level goals: (left) vector packing for fast linear transforms, (middle) automated bootstrap placement and level management, and (right) an end-user workflow that stays close to PyTorch.

First, we automatically handle FHE packing in order to leverage fast CKKS linear transformation algorithms. Our packing strategy ensures that each linear layer consumes only one multiplicative level regardless of the linear layer configuration. Second, we entirely automate both bootstrap and scale management, which enables Orion to run deep neural networks such as ResNet-50 while still maintaining precision. Finally, we wanted Orion to be accessible; writing FHE neural networks in Orion requires only knowledge of PyTorch.

Below, we’ll cover the details of our convolution algorithm and bootstrap placement strategy.

2. Efficient Linear Transform Algorithms

Linear transformations are a core building block in neural networks, from convolutional neural networks (convolutions, average pooling, and final head layers) to modern-day transformer architectures (QKV projections, feed-forward MLPs, and even RoPE). Under CKKS, it helps to think about linear transforms in terms of three constraints: how well we use ciphertext slots, how many multiplicative levels we consume, and how many expensive homomorphic operations we require (in particular, key-switches induced by ciphertext rotations).

As a concrete example, consider outsourced neural inference where we want to compute a matrix–vector product between a plaintext weight matrix and an encrypted ciphertext vector. Since the weight matrix is unencrypted, it can be packed into CKKS plaintext vectors in different ways, and that packing choice largely determines how many rotations and levels we pay for.

A natural first attempt is to pack each row of the matrix into a CKKS vector and compute a dot product against the ciphertext. In practice, row-based packing tends to be a poor fit for CKKS: it requires padding dimensions to powers of two, it computes dot products within ciphertexts (often leading to low slot utilization), and it typically consumes extra multiplicative depth to consolidate partial sums. It also scales poorly in rotations for dense matrix–vector products.

Figure 2: The diagonal method for plaintext-ciphertext matrix–vector products.

Orion instead targets diagonal-based matrix–vector product algorithms in which the diagonals of the unencrypted matrix are packed into CKKS vectors. These algorithms have been well-optimized by the cryptographic community, and they align well with how CKKS bootstrapping itself is implemented (which relies on large linear transforms). Rather than computing dot products within intermediate ciphertexts, diagonal-based approaches compute dot products across ciphertexts and then aggregate them into a single packed ciphertext output.

A standard way to reduce the rotation count further is the baby-step giant-step (BSGS) strategy. Informally, BSGS reuses ciphertext rotations by reorganizing which shifts happen on ciphertexts and which shifts can be absorbed into plaintext preprocessing of packed diagonals. This reduces rotation counts from $O(n)$ down to $O(\sqrt{n})$ while still consuming only one multiplicative level.

Figure 3: BSGS reduces ciphertext rotations by leveraging the fact that matrix diagonals can be cheaply rotated before being encoded.

In Orion, we combine BSGS with low-level cryptographic optimizations (in particular, double hoisting) to reduce the amortized cost per rotation. Once we treat “fast matrix–vector products” as a first-class compiler target, we can build higher-level neural network layers on top of a kernel that is both level-efficient (one level per MV) and rotation-efficient (BSGS + hoisting).

3. Convolutions as Matrix-Vector Products

Now that we have a blueprint for fast matrix-vector products, a natural question is: can we apply it to convolutions? If so, then the same principles would extend to the much wider class of convolutional neural nets.

The standard approach for this is known as the Toeplitz formulation. Here, the input image is flattened into a vector and the kernel expands into a matrix. Each row of this Toeplitz matrix corresponds to one filter multiplication with the input image as it slides over all of its positions.

Figure 4: The Toeplitz formulation of a single-input, single-output (SISO) convolution.

The animation in Figure 4 shows this for single-input single-output (SISO) convolutions, although the approach naturally extends to multi-input, multi-output convolutions as well. We use the following code block in Orion to perform the initial packing of arbitrary convolutions (e.g., any stride, padding, dilation, etc.) directly in PyTorch.

def construct_toeplitz_matrix(input_shape, output_shape, conv_layer):
    """
    Construct the Toeplitz representation of a convolutional layer.
    
    The Toeplitz matrix reformulates convolution as matrix-vector multiplication:
        output_flat = toep_matrix @ input_flat
    
    Args:
        input_shape (tuple): Shape of input tensor (N, Ci, Hi, Wi)
        output_shape (tuple): Shape of output tensor (N, Co, Ho, Wo)
        conv_layer (nn.Conv2d): PyTorch convolutional layer
    
    Returns:
        torch.Tensor: Toeplitz matrix of shape (Co * Ho * Wo, Ci * Hi * Wi)
    """
    # Unpack shapes
    N, Ci, Hi, Wi = input_shape
    N, Co, Ho, Wo = output_shape
    
    # Extract convolution parameters
    kernel_weights = conv_layer.weight.data  # shape: (Co, Ci, kH, kW)
    _, _, kH, kW = kernel_weights.shape
    padding = conv_layer.padding[0]
    stride = conv_layer.stride[0]
    dilation = conv_layer.dilation[0]
    
    # Compute padded input dimensions
    Hi_padded = Hi + 2 * padding
    Wi_padded = Wi + 2 * padding
    
    # Initialize Toeplitz matrix
    num_output_elements = Co * Ho * Wo
    num_padded_input_elements = Ci * Hi_padded * Wi_padded
    toep_matrix = torch.zeros(num_output_elements, num_padded_input_elements)
    
    # Create index grid for the padded input (Ci, Hi_padded, Wi_padded)
    padded_indices = torch.arange(
        Ci * Hi_padded * Wi_padded, dtype=torch.int32
    ).reshape(Ci, Hi_padded, Wi_padded)
    
    # Indices within a single kernel window (accounts for dilation)
    kernel_window_indices = padded_indices[
        :Ci,                      # all input channels
        :kH * dilation:dilation,  # kernel height with dilation
        :kW * dilation:dilation   # kernel width with dilation
    ].flatten()
    
    # Top-left corner positions where the kernel is applied (accounts for stride)
    kernel_start_positions = padded_indices[
        0,                  # first channel only (others offset by kernel_window_indices)
        0:Ho * stride:stride,  # vertical positions
        0:Wo * stride:stride   # horizontal positions
    ].flatten()
    
    # Fill Toeplitz matrix: each output channel block gets the kernel weights
    output_channel_offsets = (torch.arange(Co) * Ho * Wo).reshape(Co, 1)
    
    for spatial_idx, start_pos in enumerate(kernel_start_positions):
        row_indices = spatial_idx + output_channel_offsets
        col_indices = kernel_window_indices + start_pos
        toep_matrix[row_indices, col_indices] = kernel_weights.reshape(Co, -1)
    
    # Extract only the columns corresponding to the original (unpadded) input
    original_input_indices = padded_indices[
        :,                      # all channels
        padding:Hi + padding,   # remove top/bottom padding
        padding:Wi + padding    # remove left/right padding
    ].flatten()
    
    toep_matrix = toep_matrix[:, original_input_indices]
    
    return toep_matrix

The core issue with this method is that it does not efficiently extend to strided convolutions under FHE. In particular, the nice diagonal pattern we see in the unit-stride case is no longer present. Without that pattern, the number of non-zero diagonals depends on the input’s spatial dimensions, which scales poorly to larger image sizes.

Figure 5: Why strided Toeplitz convolutions are harder. With stride $s > 1$, the Toeplitz matrix loses the clean diagonal structure of the unit-stride case.

For the Toeplitz representation to be useful, we need better slot utilization for strided convolutions. Our key observation is that we can permute the matrix rows without changing the computation. All that changes is the order of the output feature map. Figure 6 shows this approach for a convolution with stride $s=2$.

Figure 6: Single-shot multiplexing. Permuting rows of the Toeplitz matrix packs the diagonals more densely, which reduces expensive ciphertext rotations.

We call this technique “single-shot multiplexing” as it mirrors the work from Lee et al. ¹, but consumes just a single multiplicative level. Like their work, this method produces outputs with a gap $g$. Future layers need to account for this gap, but Orion handles it automatically during compilation.

The result is fewer rotations, roughly half of which are hoisted. On CIFAR-10, we see 1.65$\times$ fewer rotations on ResNet-20 and up to 6.41$\times$ fewer rotations on AlexNet.

4. Automating Bootstrap Placement

At this point, it’s worth zooming in on how Orion automates bootstrap placement, because bootstrapping is what makes deep encrypted inference possible in the first place. Unlike data packing, good bootstrap placement often requires a deeper understanding of the underlying cryptography. In our experience, this creates the largest barrier to entry for practitioners, making automated solutions all the more valuable.

Our approach involves reformulating things as a shortest-path problem. We create what we call a “level DAG” to enumerate the behavior of all possible network states and their transitions.

Figure 7 (left) visualizes this DAG for a simple 3-layer MLP without intermediate activation functions. Here, nodes within a row represent possible choices of level for each linear layer, weighted by the latency of performing that linear layer at the given level. Each row also excludes invalid states. For instance, there is no node for fc2 at level l=0 because linear layers consume a level, and we could lose decoding correctness if there were.

Figure 7: Bootstrap placement as shortest-path search. Nodes are level choices (weighted by latency), edges are transitions that may require a bootstrap. The shortest path gives us where to bootstrap and at what level to run each layer.

We can then weigh the edges between layers by whether a bootstrap operation is required. For instance, the edges highlighted in red in Figure 7 (middle) each increase the level of the ciphertext (after the layer itself is performed), and therefore must be bootstrapped.

With these two constraints, we can apply a shortest path algorithm to find the path that minimizes end-to-end latency in Figure 7 (right). With respect to our heuristics, this shortest path gives us both the optimal locations to bootstrap and the optimal levels at which to perform each layer.

4a. Beyond Simple MLPs

This method extends almost directly to more complex networks, especially those with residual connections. The main obstacle is that residual connections create multiple paths through the graph, each sharing a common fork and join node. This makes directly applying our shortest path approach challenging.

We solve this by creating two level DAGs around each residual connection: one for the backbone, one for the residual itself. Then, we can (i) sum the shortest paths for all possible pairs of input and output nodes, and (ii) insert that black-boxed solution back into the original level DAG. This reduces the problem to our original shortest path approach.

Figure 8: Bootstrap placement over residual connections by solving and black-boxing single-entry, single-exit regions (the backbone and residual paths) and inserting the aggregated solution back into the global level DAG.

Interestingly, this approach extends recursively to graphs with any number of fork/join pairs. Figure 9 gives the high-level solution for attention blocks within transformers.

Figure 9: Bootstrap placement for more complex networks and attention blocks with multiple fork/join pairs.

5. Addressing the Sharp Bits

There’s still more to running deep FHE inference beyond packing and bootstrap placement. Orion includes several automation layers that remove the “sharp edges” that typically trip up non-experts.

First, to conform to the CKKS programming model, all non-linear functions (e.g., ReLU or GELU) must be replaced by high-degree polynomials over the correct range. Orion automates this with orion.fit() which iterates over the training data and (i) replaces non-linearities with Chebyshev polynomials, and (ii) automatically determines the input ranges those approximations need.

Second, Orion automates scale management. We leverage the fact that our compilation phase has already determined the level at which to perform any linear layer (call it level $j$). We encode the weights with scale factor $q_j$ (the last RNS modulus at level $j$) rather than $\Delta$. This way, performing a convolution with a ciphertext at scale $\Delta$ produces an output at scale $\Delta \cdot q_j$. Rescaling divides by $q_j$, resetting the scale back to exactly $\Delta$. This is what we call “errorless” neural network evaluation.

Finally, Orion handles the large data structures that come with FHE inference. Server-side packed vectors and evaluation keys can reach tens to hundreds of gigabytes. Orion optionally reduces memory pressure by dynamically loading per-layer plaintext vectors during linear transforms.

Figure 10: The sharp bits Orion handles automatically: (left) fitting activation functions, (middle) scale management, (right) large data structures.

From the user’s perspective, Orion feels like PyTorch: you write a model as usual, fit/compile it for FHE, and run encrypted inference.

import torch.nn as nn
import orion.nn as on


class BasicBlock(on.Module):
    expansion = 1

    def __init__(self, Ci, Co, stride=1):
        super().__init__()
        self.conv1 = on.Conv2d(Ci, Co, kernel_size=3, stride=stride, padding=1, bias=False)
        self.bn1   = on.BatchNorm2d(Co)
        self.act1  = on.ReLU()

        self.conv2 = on.Conv2d(Co, Co, kernel_size=3, stride=1, padding=1, bias=False)
        self.bn2   = on.BatchNorm2d(Co)
        self.act2  = on.ReLU()
       
        self.add = on.Add()
        self.shortcut = nn.Sequential()
        if stride != 1 or Ci != self.expansion*Co:
            self.shortcut = nn.Sequential(
                on.Conv2d(Ci, self.expansion*Co, kernel_size=1, stride=stride, bias=False),
                on.BatchNorm2d(self.expansion*Co))
  
    def forward(self, x):
        out = self.act1(self.bn1(self.conv1(x)))
        out = self.bn2(self.conv2(out))
        out = self.add(out, self.shortcut(x))
        return self.act2(out)


class ResNet(on.Module):
    def __init__(self, dataset, block, num_blocks, num_chans, conv1_params, num_classes):
        super().__init__()
        self.in_chans = num_chans[0]
        self.last_chans = num_chans[-1]

        self.conv1 = on.Conv2d(3, self.in_chans, **conv1_params, bias=False)
        self.bn1 = on.BatchNorm2d(self.in_chans)
        self.act = on.ReLU()
        
        self.layers = nn.ModuleList()
        for i in range(len(num_blocks)):
            stride = 1 if i == 0 else 2
            self.layers.append(self.layer(block, num_chans[i], num_blocks[i], stride))

        self.avgpool = on.AdaptiveAvgPool2d(output_size=(1,1)) 
        self.flatten = on.Flatten()
        self.linear  = on.Linear(self.last_chans * block.expansion, num_classes)

    def layer(self, block, chans, num_blocks, stride):
        strides = [stride] + [1]*(num_blocks-1)
        layers = []
        for stride in strides:
            layers.append(block(self.in_chans, chans, stride))
            self.in_chans = chans * block.expansion
        return nn.Sequential(*layers)
    
    def forward(self, x):
        out = self.act(self.bn1(self.conv1(x)))
        for layer in self.layers:
            out = layer(out)

        out = self.avgpool(out)
        out = self.flatten(out)
        return self.linear(out)


def ResNet20(dataset='cifar10'):
    configs = {
        "cifar10":  {"kernel_size": 3, "stride": 1, "padding": 1, "num_classes": 10},
        "cifar100": {"kernel_size": 3, "stride": 1, "padding": 1, "num_classes": 100},
    }
    config = configs[dataset]
    conv1_params = {
        'kernel_size': config["kernel_size"],
        'stride': config["stride"],
        'padding': config["padding"]
    }
    return ResNet(dataset, BasicBlock, [3,3,3], [16,32,64], conv1_params, config["num_classes"])

# High-level workflow (sketch)
net = ResNet20()
orion.fit(net, trainloader)   # range discovery + polynomial activation replacement
orion.compile(net)            # packing + bootstrap placement + key/material generation

net.he()                      # switch model into FHE execution mode
ct_out = net(ct_in)           # run encrypted inference

6. Results

To highlight Orion’s scalability, we ran ResNet-34 and ResNet-50 on ImageNet end-to-end under FHE with single-threaded inference times of 3.98 hours and 8.98 hours, respectively. To show that Orion handles more than classification, we also ran object detection using a 139 million parameter YOLO-v1 model on the PASCAL-VOC dataset (images of size 448 $\times$ 448 $\times$ 3). An encrypted inference took 17.5 hours and produced bounding boxes and confidence scores entirely under FHE, matching the cleartext PyTorch output to 8 bits of precision.

Figure 11: Homomorphic object detection and localization results. Labels show predicted class and confidence score. Outputs match cleartext PyTorch to 8 bits of precision.

If you want to reproduce results or try Orion on your own models, the repository is available at https://github.com/baahl-nyu/orion.

References

TL;DR: We investigate methods for protecting server privacy in CKKS-based protocols. Unlike exact homomorphic encryption schemes, formally defining security notions for the server is challenging in CKKS-based protocols due to the approximate nature of CKKS. We address this by introducing a new security notion called Differentially Private Homomorphic Encryption, which is motivated by differential privacy. Based on this notion, we construct a general compiler that transforms CKKS-based protocols into DPHE protocols. We also present the first zero-knowledge argument of knowledge for CKKS ciphertexts to protect server privacy against malicious clients.

1.Introduction

In recent years, CKKS has become a popular choice for building privacy-preserving machine learning (PPML) protocols. The primary reason for its popularity is its support for efficient real and complex arithmetic. This feature enables straightforward design of machine learning as a service (MLaaS) protocols that protect user privacy. However, in most CKKS-based protocols, server privacy is not guaranteed. Specifically, a client may learn more than just the inference result, potentially gaining access to sensitive information such as model weights or training data. In delegated computation scenarios where the server’s model is public, such as in open-source large language models, this is not a major concern. However, in settings where the service provider aims to keep its model private—due to high training costs, risks of model jailbreaking, or legal and regulatory issues involving sensitive data such as health or legal information—protecting server privacy becomes critical. Thus, in this paper, we aim to address the following question in CKKS-based protocols.

How can we protect the server’s privacy in CKKS-based MLaaS protocols?

2. Server Privacy in Homomorphic Evaluation Protocols

Circuit Privacy is Insufficient

For other homomorphic encryption (HE)-based protocols, protecting server privacy has been studied in the context of standard two-party computation (2PC) protocol security, which is often referred to as circuit privacy. The circuit privacy framework is suitable for two-party cryptographic protocols, such as oblivious pseudo-random function (OPRF) protocols ¹, where the output reveals no information at all about the server’s input. However, for encrypted MLaaS protocols, where the output often contains too much information about the server’s input, circuit privacy does not guarantee server privacy, as it does not prevent leakage from the output itself.

Estimating Privacy Leakage via Differential Privacy

To estimate server privacy leakage in CKKS-based MLaaS protocols, we utilize a differential privacy (DP)-based analysis beyond the circuit privacy framework. In plain MLaaS protocols, server privacy leakage is usually measured through the lens of differential privacy. In particular, it can be formalized through the notion of DP-prediction², which is defined as follows.

Definition (DP Prediction). Let $M : \Theta \times \mathcal{X} \rightarrow \mathcal{Y}$ be a random algorithm. We say that $M$ is an $\epsilon$-DP prediction algorithm if, for every $x \in \mathcal{X}$, the output $M(\theta, x)$ is $\epsilon$-DP with respect to $\theta \in \Theta$. In other words, for all adjacent $\theta, \theta’ \in \Theta$ and all PPT algorithms $\mathcal{A}$, the following holds.

The above definition models an MLaaS protocol where the client’s query is $x$ and the server’s model weight or training data is $\theta$. Then, the above definition essentially says that server privacy is maintained regardless of the client’s query. Then, we model the ideal functionality of encrypted MLaaS protocols as evaluating some DP-prediction algorithm $M$, which can be described as follows.

Ideal Functionality. The ideal functionality $\mathcal{F}$ for encrypted MLaaS protocols is defined as follows.

• Client’s input: $x \in \mathcal{X}$
• Server’s input: $\theta \in \Theta$
• Client’s output: $M(\theta, x)$
• Server’s output: $\bot$

Based on the above ideal functionality, we define the server’s privacy in encrypted MLaaS protocols as follows.

Definition (Server Privacy). Let $\Pi$ be a two-party protocol that implements the ideal functionality $\mathcal{F}$. We say $\Pi$ achieves server privacy with parameter $\epsilon$ if an execution of $\Pi$ is an $\epsilon$-DP prediction with respect to the server’s input $\theta$. In other words, the following holds for all PPT adversaries $\mathcal{A}$ that manipulate the client, and all PPT environments $\mathcal{Z}$.

The above definition can be interpreted as a natural extension of DP-prediction in a two-party computation scenario. In other words, the above definition ensures that the protocol $\Pi$ protects the server’s input $\theta$ in terms of differential privacy against all adversarial clients’ inputs $x$.

Circuit Privacy implies Server Privacy

One interesting corollary is that circuit privacy remains meaningful within our new definition of server privacy. To present more details, we recall the definition of circuit privacy below.

Definition (Circuit Privacy). Let $\Pi$ be a two-party protocol that implements the ideal functionality $\mathcal{F}$. We say $\Pi$ achieves circuit privacy if there exists a PPT simulator $\mathcal{S}$ such that the following holds for all PPT adversaries $\mathcal{A}$ that manipulate the client, and all PPT environments $\mathcal{Z}$.

Then, we can derive the following result.

Theorem (Circuit Privacy). Let $\Pi$ be a two-party protocol that implements the ideal functionality $\mathcal{F}$. Suppose the target model $M$ in $\mathcal{F}$ is an $\epsilon$-DP prediction and $\Pi$ achieves circuit privacy, then $\Pi$ achieves server privacy with parameter $\epsilon$.

The above theorem says that if the target model $M$ is a DP-prediction algorithm and $\Pi$ achieves circuit privacy, then $\Pi$ guarantees server privacy. Thus, we can conclude that achieving circuit privacy is still meaningful in the context of encrypted MLaaS protocols if the target models are set to DP prediction algorithms.

3. Differentially Private Homomrphic Evaluation

Motivation

Within our new server privacy notion, the problem of achieving server privacy seems to essentially boil down to achieving circuit privacy, which naturally leads to the following questions in the case of CKKS-based protocols.

Can we achieve circuit privacy in CKKS-based protocols?

The answer to the above question is No in general due to the peculiar structure of CKKS ciphertexts. To demonstrate the reasons, we first compare the ciphertext structure of CKKS with that of other exact HE schemes, such as BFV. In a BFV ciphertext, a noise term $e$ and a plaintext $m$ are strictly separated, so they do not interfere with each other unless $e$ exceeds the decryption bound. However, in a CKKS ciphertext, the noise $e$ and the plaintext $m$ exist in a fused state $m + e$, and they cannot be separated once encryption is performed. Thus, the size of the noise affects the precision of the plaintext after decryption, as they interfere with each other.

To achieve circuit privacy, one frequently utilized technique is noise flooding, which introduces additional noise $e’$ to erase any circuit information remaining in the noise part $e$. To achieve the indistinguishability notion in circuit privacy, the size of $e’$ is set to be exponentially larger than $e$. This is acceptable for BFV ciphertexts if $e + e’$ remains below the decryption bound, as the additional noise does not alter the value $m$ of the plaintext. However, for CKKS ciphertexts, excessive noise corrupts the plaintext value because they are fused. To be precise, performing noise flooding results in a decryption result of $m + e + e’$. If $e’ \gg m$, then the decryption result becomes entirely unusable for the client, even though circuit privacy is achieved.

Definition

We observe that the main difficulty in achieving circuit privacy arises from the computational indistinguishability requirement between the ideal functionality and the real protocol execution. However, if our final goal is to achieve server privacy, which is estimated in terms of differential privacy, requiring computational indistinguishability can be an overkill. Thus, we define the concept of differentially private homomorphic evaluation³ (DPHE) as follows to resolve this issue.

Definition (DPHE). Let $\Pi$ be a homomorphic evaluation protocol that implements ideal functionality $\mathcal{F}$. We say $\Pi$ is an $\epsilon$-DPHE protocol for $F$ if there exists a PPT simulator $\mathcal{S}$ such that the following holds for all PPT adversaries $\mathcal{A}$ that manipulate the client, and all PPT environments $\mathcal{Z}$.

The above definition can be viewed as a relaxation of the indistinguishability notion in circuit privacy into something analogous to differential privacy. Once a protocol satisfies the DPHE property, we can derive the following result.

Theorem (DPHE). Let $\Pi$ be a two-party protocol that implements the ideal functionality $\mathcal{F}$. Suppose the target model $M$ in $\mathcal{F}$ is an $\epsilon$-DP prediction and $\Pi$ achieves $\epsilon’$-DPHE property, then $\Pi$ achieves server privacy with parameter $\epsilon+2\epsilon’$.

Therefore, we can conclude that achieving the DPHE property is sufficient for server privacy instead of achieving circuit privacy.

Instantiation

Once we verify that the DPHE property is sufficient, it naturally leads to the following next questions.

Can we achieve the DPHE property in CKKS-based protocols?

The answer is Yes, and we show how to instantiate a DPHE protocol by compiling existing CKKS-based protocols. The core idea is to utilize the Laplace mechanism⁴ to achieve differential privacy. Suppose the ciphertext space is \(R_q = \mathbb{Z}_q[X]/(X^N + 1)\) and security parameter is given as $\mathbf{1}^{\lambda}$. We recall that to achieve circuit privacy, the noise flooding method introduces additional noise $e’$ whose norm is $O(2^{\lambda} \cdot B_e)$, where $B_e$ is an upper bound of the norm $\Vert e \Vert_{\infty}$ of the initial noise $e$. However, to achieve the DPHE property, it suffices to add additional noise $e’$ whose norm is $O(N B_e)$, which is significantly smaller than that of noise flooding.

The detailed procedure is as follows. Suppose a protocol $\Pi$ aims at evaluating a DP mechanism $M$ on the client’s encrypted input $\mathsf{ct}_{in} = \mathsf{Enc}(x)$. Let $\tau > 0$ be an $L^1$-norm bound for the noise when evaluating $M$ in CKKS evaluation algorithms for $\theta \in \Theta$ and $x \in \mathcal{X}$. Then, the compilation is achieved as follows.

1. $(c_0, c_1) \gets \mathsf{Eval} \big( M(\theta, \cdot), \mathsf{ct}_{in} \big) \pmod{q}$
2. $(c’_0, c’_1) \gets (c_0, c_1) + (\lceil t \rfloor, 0) \pmod{q}$ for $t \gets \mathsf{Lap}(N \tau / \epsilon’)^N$
3. \(\mathsf{ct}_{out} \gets q' \cdot (c'_0, c'_1) + \mathsf{Enc}_{\mathsf{pk}}(0) \pmod{qq'}\)  

The second step is for achieving the differential privacy property on the client’s output plaintext, and the third step is to remove any remaining information in the ciphertext components by adding an encryption of zero. As a corollary, our compiler results in the following result.

Corollary (DPHE Compiler). Let $\mathcal{F}$ be the ideal functionality for homomorphic evaluation of an $\epsilon$-DP prediction algorithm $M$. Then, the DPHE compiler produces an $\epsilon’$-DPHE protocol $\Pi$ that implements $\mathcal{F}$, and $\Pi$ achieves server privacy with parameter. $\epsilon + 2\epsilon’$

Therefore, by relaxing the security notion for homomorphic evaluation protocols, we succeed in achieving server privacy in CKKS-based protocols.

4. ZKAoK for CKKS Ciphertexts

Our DPHE compiler is based on the assumption that the input ciphertext is well-formed and the input message lies in the domain $\mathcal{X}$. However, for malicious clients, there is no guarantee that the input ciphertext satisfies these conditions. Thus, for the server to verify these conditions without compromising the client’s privacy, we need a zero-knowledge argument of knowledge (ZKAoK) for CKKS ciphertexts.

However, designing ZKAoK for CKKS is nontrivial, and there have been no previous attempts for it. The main difficulty arises from the lack of techniques for verifying the validity of the message, i.e., $\vec{x} \in \mathcal{X} \subseteq \mathbb{R}^N$. To be precise, when encrypting a message $\vec{x} \in \mathbb{R}^N$, it is encoded into a polynomial $m(X) \in R_q$ that lies in the ciphertext space $R_q = \mathbb{Z}_q[X]/(X^N + 1)$. Current ZKAoK for HE ciphertexts⁵ only support verification of arithmetic relations defined over $R_q$, whereas we need to verify the condition $x \in \mathcal{X}$, which is defined over $\mathbb{R}^N$.

Solution

We address this issue by delegating the encoding procedure to the server, described below.

1. For an input message $\vec{x} := (x_0, \dots, x_{N-1}) \in \mathbb{R}^N$, the client generates a plaintext $m’(X) \in R_q$ with scaled coefficient packing as follows.
   • $m’(X) = \lceil \Delta x_0 \rceil + \lceil \Delta x_1 \rceil X + \cdots + \lceil \Delta x_{N-1} \rceil X^{N-1}$
2. The client generates a ciphertext $\mathsf{ct}’ = (a’, b’) \in R_q^2$ from $m’(X)$ and proves the following relations hold through ZKAoK for HE ciphertexts.
   • $b’ - a’ s = m’ + e’ \pmod{q}$
   • $\Vert s \Vert_{\infty} \le B_s$ and $\Vert e’ \Vert_{\infty} \le B_e$
   • $\mathsf{Coeff}(m’) \in \lceil \Delta \mathcal{X} \rceil \subseteq \mathbb{Z}_q^N$
3. The server verifies the ZKAoK for the ciphertext $\mathsf{ct}’$, and obtains the actual input ciphertext $\mathsf{ct}$ as follows.
   • $\mathsf{ct} \gets \mathsf{CoeffToSlot}(\mathsf{ct}’)$

The scaled coefficient packing in the first step allows a client to generate a ZKAoK for verifying the input domain in $R_q$. After the server verifies this ZKAoK, it can generate an input ciphertext whose slot values correspond to these coefficient values by applying the coeff-to-slot operation. As a result, the server can ensure that input ciphertexts are well-formed, i.e., the input messages lie within the input domain.

Benchmark

With the above technique, we instantiate the first ZKAoK for CKKS ciphertexts⁶ that can verify the input domain. Specifically, we construct the ZKAoK for CKKS, which proves that input messages of ciphertexts lie in $[-1, 1]^N$, together with well-formedness of public keys, including encryption, relinearization, rotation key, and conjugation key. In the following table, we provide the concrete benchmark results, where $k$ denotes the number of ciphertexts, $\Delta$ denotes the scaling factor, PK Size denotes the total size of public keys, and CT Size denotes the total size of ciphertexts. The performance is measured on an Intel Xeon Platinum 8268 CPU with a single thread.

5. Conclusion

In summary, we examine the server privacy issues in CKKS-based protocols, particularly for encrypted MLaaS protocols. The key takeaways are as follows.

• We formalize the security notion for server privacy based on differential privacy.
• We achieve server privacy for CKKS without noise flooding.
• We construct the first zero-knowledge argument of knowledge for CKKS to handle malicious clients.

References

TL;DR: FHE has advanced significantly since its introduction fifteen years ago, yet it remains challenging to use efficiently. We examine methods addressing three of the major challenges faced by cryptographers and data scientists face when using FHE: data packing; polynomial approximations and data traversal.

More than a decade and a half has passed since the publication of Gentry’s original paper [1] about Fully Homomorphic Encryption (FHE). Since then, real progress has been made transforming FHE from a theoretical tool accessible only to a few into a practical solution with rapidly improving usability, performance, and abstraction. Still, the development of practical applications and data science models remains challenging for both cryptographers and data scientists. The three major challenges are outlined below and discussed in subsequent sections:

• Efficient data packing
• Accurate polynomial approximation of analytical functions
• Efficient data traversal

Efficient Data Packing and Tile Tensors

Several FHE schemes (e.g. BGV [2], BFV [3], CKKS [4]) encode a vector of plaintext values as polynomial coefficients and operate on it element-wise. Thus, encrypted data operations in many FHE schemes can be viewed as Single Instruction, Multiple Data (SIMD). Efficiently mapping complex data to these coefficients (or vector slots) is often a pain-point for developers. Tile tensors [5] simplify this packing process by defining the layout of tensors and their tiling using high-level “tile tensor shapes”. Tile tensors extend known packing approaches, allowing researchers to focus on the algorithms rather than on the ciphertext internals.

The idea behind tile tensors is to think of a ciphertext as a tile with a configurable shape and cover tensors with these tiles. This implies that the size of a tile equals the number of slots each ciphertext has. Changing the shape of the tiles changes how a tensor is packed into ciphertexts. For example, when covering a 2-dimensional matrix with a tile of shape 1x8 (assuming 8 slots in a ciphertext, for simplicity) we get row-based packing. With a tile of shape 8x1 we get column-based packing. Other shapes, such as 2x4 are also possible. See Figure 1 for an example.

Efficient and Accurate Polynomial Approximating

Another fundamental FHE challenge is function evaluation. Most FHE schemes support a handful of arithmetic primitives, such as element-wise addition, multiplication and vector rotation. Any operation beyond these primitives, e.g. division, comparison, not to mention complex neural network activation functions, requires some approximation. One can construct polynomials using only additions and multiplications, and then use them to approximate almost any function to a desired degree of accuracy. However, since the use of any primitive comes with an inherent computational cost, every operation should be assessed with scrutiny, to minimize the amount and type of operations to only those that are necessary to meet accuracy goals. The art here is twofold: devising polynomial approximations that are both accurate and of low-enough degree to achieve acceptable performance and representing and evaluating these polynomials in ways optimized for FHE. Efficient polynomial evaluation, packing tricks (that can be implemented with Tile Tensors), and circuit crafting are all essential.

Efficient Data Traversal

Since algorithms under FHE deal with encrypted messages they are unable to make any decision based on the encrypted input. This includes branching dynamically, i.e. take a path of the code depending on encrypted input. See for example [7]. Instead, algorithms need to evaluate all possible branches and multiplex (“select”) their output. Even a simple algorithm such as searching a binary tree becomes exponentially more expensive in FHE because it needs to traverse every path of the tree and not just a single one as in the cleartext case. Algorithms such as those needed in private database queries or machine learning (decision trees) suffer from this limitation and are not efficient under FHE.

Different methods have been proposed, among which is “Copy-and-Recurse” [8, 9]. Rather than branching, which is problematic under FHE, this method creates a copy (under FHE) of the branch that the algorithm needs to take and continues with this copy. Creating this copy requires a constant number of multiplications and additions for each node, but then any the number of expensive computations that are done at nodes (e.g., comparisons) is proportional to the cleartext algorithm.

A Book for the Practicing Cryptographer and Data Scientist

These challenges, alongside techniques and practical recipes to solve them, are important for algorithmic researchers attempting to utilize FHE. Each topic is explained further with concrete examples, code templates, and in-depth discussions in the book “Homomorphic Encryption for Data Science (HE4DS)” [10]. For cryptographers determined to bridge the theory-practice gap, and for data scientists eager to harness encrypted computation for real-world ML and analytics tasks, this text stands as an invitation: the road is still rugged, but the right tools and abstractions exist. The landscape of FHE is shifting from a field of delicate manual hacks to one supported by high-level libraries and reproducible patterns. Understanding these new abstractions will empower the next generation of privacy-preserving applications.

References

[1] Craig Gentry. “Fully Homomorphic Encryption Using Ideal Lattices.” Proceedings of the 41st Annual ACM Symposium on Theory of Computing (STOC 2009), pp. 169–178. ACM, 2009. DOI: 10.1145/1536414.1536440

[2] Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan. “(Leveled) Fully Homomorphic Encryption without Bootstrapping.” Proceedings of the 3rd Innovations in Theoretical Computer Science Conference (ITCS 2012), pp. 309–325. ACM, 2012.

[3] J. Fan and F. Vercauteren. Somewhat practical fully homomorphic encryption. IACR Cryptol. ePrint Arch., 2012:144.

[4] Jung Hee Cheon, Andrey Kim, Miran Kim, and Yongsoo Song. “Homomorphic Encryption for Arithmetic of Approximate Numbers.” In Advances in Cryptology – ASIACRYPT 2017, Lecture Notes in Computer Science, vol. 10624, pp. 409–437. Springer, 2017.

[5] Ehud Aharoni, Allon Adir, Moran Baruch, Nir Drucker, Gilad Ezov, Ariel Farkash, Lev Greenberg, Ramy Masalha, Guy Moshkowich, Dov Murik, Hayim Shaul, and Omri Soceanu. “HeLayers: A Tile Tensors Framework for Large Neural Networks on Encrypted Data.” Proceedings on Privacy Enhancing Technologies (PoPETs), 2023(1): 325–342. DOI: 10.56553/popets-2023-0020

[6] Ehud Aharoni, Nir Drucker and Hayim Shaul, “Tutorial: Advanced HE packing methods with applications to ML”, ACM CCS 2022, https://research.ibm.com/haifa/dept/vst/tutorial_ccs2022.html.

[7] Sunchul Jung, “Convergent Evolution: Why Secure Homomorphic Encryption Will Resemble High-Performance GPU Computing”, https://ckks.org/blog/2025/convergent-evolution/#21-the-fhe-security-model-and-the-turing-barrier

[8] Eyal Kushnir, Guy Moshkowich, and Hayim Shaul. “Secure Range-Searching Using Copy-And-Recurse.” Proceedings on Privacy Enhancing Technologies (PoPETs), 2024(3).

[9] Eyal Kushnir and Hayim Shaul. “Improved Range Searching and Range Emptiness Under FHE Using Copy-And-Recurse.” Cryptology ePrint Archive, Paper 2025/751, 2025. Available at: https://eprint.iacr.org/2025/751

[10] Adir, A., Aharoni, E., Drucker, N., Levy, R., Shaul, H., and Soceanu, O. Homomorphic Encryption for Data Science (HE4DS). Springer Nature Switzerland, 2024. ISBN 9783031654947. Available at: https://link.springer.com/book/10.1007/978-3-031-65494-7

TL;DR: We introduce a new polynomial evaluation algorithm under homomorphic encryption, namely the Asymmetric BSGS Algorithm. It is a generalization and specialization of the original Baby-Step Giant-Step algorithm in the leveled FHE computation model. Leveraging the observation that there is a difference in multiplicative depth between the baby-step set and the giant-step set, this algorithm significantly reduces the number of modulus and key switches required for dense polynomial evaluation from \(O(\sqrt{d})\) to \(O(d^{1/t})\), by adjusting the set decomposition method and relaxing the control of noise growth and ciphertext size in some calculations. Here, \(d\) is the polynomial degree and \(t\) is a small constant which, according to our experiments, is recommended to be chosen as \(4\).

1. How to Compute Polynomial Evaluation?

Polynomial evaluation is one of the most crucial tasks in the field of computing. This is particularly true in leveled FHEs, as they only support homomorphic addition, homomorphic multiplication, and some automorphisms related to SIMD packing. Almost all functions are either interpolated (in BGV/BFV) or approximated (in CKKS) with the use of specific polynomials.

So, how can we efficiently compute polynomial evaluation? For polynomials that can be factored into sparse factors, such as \(f(X) = (x^3+1)^{16}\cdot(x^{32}+x-1)\), we can compute the evaluation of each sparse-coefficient polynomial separately and then multiply them together. Thus, the computational cost is relatively low, although the multiplication depth may not be optimal. However, most polynomials are difficult or even impossible to factor into sparse factors. One can only use general polynomial evaluation algorithms to deal with them, among which the most well-known is the BSGS algorithm¹.

Briefly speaking, for a degree-\(d\) polynomial \(f(X) = \sum_{i}f_{i}X^{i}\), the BSGS algorithm selects two integers, \(k\approx m\approx\sqrt{d}\), such that \(km > d\). Then the coefficients of \(f(X)\) can be partitioned into \(m\) intervals of length at most \(k\), namely

where each \(f^{(j)}(X)=\sum_{i = 0}^{k-1}f_{jk + i}X^{i}\) is a polynomial of degree less than \(k\).

Given a value \(x\), pre-compute \(S_1 := \{1,x,\cdots,x^{k-1}\}\) (which we call the baby-step set) and \(S_2 := \{1,z,\cdots,z^{m-1}\}\) (which we call the giant-step set), where \(z := x^k\). Then the computation of all \(y_j := f^{(j)}(x)\) is merely a linear combination of the elements in \(S_1\), and this can be efficiently computed in leveled FHE. Finally, by multiplying the \(y_j\) with the elements in \(S_2\) and then summing them up, the computation of \(f(x)\) can be completed.

The above-mentioned algorithm takes \(3\sqrt{d}\) non-scalar multiplications: computing \(S_1\), computing \(S_2\), and the final multiplication and accumulation each take \(\sqrt{d}\) non-scalar multiplications. If we use Horner’s rule, the computation of \(S_2\) can be omitted, but at the cost of increasing the multiplication depth to the order of \(\sqrt{d}\). The recursive variant of the BSGS algorithm, the Paterson-Stockmeyer algorithm, only requires \(\sqrt{2d}+O(\log d)\) non-scalar multiplications and has a multiplicative depth of logarithmic order.

It has been proven that a general polynomial evaluation algorithm requires at least \(\sqrt{d}\) non-scalar multiplications¹, so it seems that there is no way to further improve the performance.

2. We Can Do Better!

We need to emphasize that there are significant differences between the leveled FHE computation model and the classical computation model. In the classical computation model, multiplication is an atomic operation, and there is no concept of “levels” for data.

However, in the leveled FHE computation model, homomorphic multiplication consists of three distinct operations with different purposes.

1. Tensor product: A ciphertext \(\mathbf{ct} \in \mathcal{R}_q[\mathbf{S}]\) is a polynomial over the cyclotomic ring \(\mathcal{R}_q\) with respect to the variable \(\mathbf{s} \in \mathcal{R}_q\), and its (noisy) plaintext is its evaluation \(\mathbf{ct}(\mathbf{s}) = \textbf{m}+\textbf{e} \in \mathcal{R}_q\). Multiplying two ciphertexts then realizes the multiplication of the two underlying plaintexts. In a typical setting, the asymptotic complexity of the tensor product is linear in terms of the security parameter, and the cost of tensor product amounts to less than 5% of that of homomorphic multiplication in practice.
2. Modulus switching: When performing the tensor product, the ciphertext noise \(\mathbf{e} \in \mathcal{R}_q\) is also multiplied, and its growth rate is proportional to the norm of \(\mathbf{e}\). By dividing by a rescaling factor in the cyclotomic field \(\mathcal{K}\supset\mathcal{R}\) and then rounding to \(\mathcal{R}\) to discard the lower-order bits of the noise \(\mathbf{e}\), the noise growth can be effectively controlled. And modulus switching endows ciphertexts with levels. The asymptotic complexity of modulus switching is quasi-linear with respect to the security parameter, and the cost of modulus switching typically constitutes approximately 20% in homomorphic multiplication.
3. Relinearization: Because polynomial multiplication over \(\mathcal{R}_q[\mathbf{S}]\) will increase the degree of the ciphertext, we need use key switching to linearize the ciphertext polynomial. This is also of quasi-linear complexity with respect to the security parameter, and it is usually the most costly one, especially when the ciphertext size increases.

Now, let’s consider what is special about implementing the BSGS algorithm in leveled FHEs. Horner’s rule would imply depth proportional to the square root of the degree, so is excluded. Given the ciphertext of \(x\), using a binary-tree approach to pre-compute the ciphertexts of \(S_1\) and \(S_2\) requires \(\sqrt{d}\) standard homomorphic multiplications respectively. In the process of multiplying the \(y_j\) with the elements in \(S_2\) and accumulating, the lazy technique, which takes advantage of the commutativity and associativity between the above-mentioned three operations and addition, can be used to combine some modulus and key switches. Altogether, approximately \(2\sqrt{d}\) modulus and key switches are required.

The figure below shows the homomorphic evaluation process of a 32-degree polynomial, where \(k = m = 6\).

We observe that the ciphertexts of \(S_1\) have a much shallower ciphertext level than those of \(S_2\). Specifically, the multiplicative depth of the ciphertexts of \(S_1\) is \(\ell_1=\left\lceil \log (k - 1) \right\rceil\), and the multiplicative depth of the ciphertexts of \(S_2\) is \(\ell_2=\left\lceil \log (km - k) \right\rceil\). The difference between the two is \(\ell_2-\ell_1\approx\frac{1}{2}\cdot\log d\), which is half of the overall multiplicative depth. We note that the noise control for the ciphertexts of set \(S_1\) does not actually need to be so strict. As long as the multiplicative depth of \(S_1\) is not greater than that of \(S_2\), the multiplicative depth of the final calculation result will not change.

How can we make full use of this difference in multiplicative depth? During the construction of \(S_1\), given \(t = \ell_2-\ell_1+1\) ciphertexts located at most at the \(\ell_1\)-th layer, it is tempting to evaluate their tensor products without performing modulus switching. At this time, the depth of the calculated \(S_1\) will not exceed \(\ell_2\), and the computational efficiency is significantly improved.

Since the size of \(S_2\) is \(\sqrt{d}\), the overall number of modulus switches is still \(O(\sqrt{d})\), but this is sufficient to provide us with an optimization direction. To achieve improvement in asymptotic complexity, we suggest to:

1. Adjust the relative sizes of \(S_1\) and \(S_2\).
2. Further decompose \(S_1\) into some small sets.

3. Asymmetric BSGS Algorithm

3.1 Preliminary Version

First, we introduce “set multiplication”, which is used to simplify the description of set decomposition in the algorithm. Given two sets \(S\) and \(S'\), which are subsets of a multiplicative group \((G,\cdot)\). Define \(S \odot S':=\{s \cdot s' \mid s\in S, s'\in S'\} \subseteq G\).

For a set \(S := \{1,x,\cdots,x^d\}\), the BSGS algorithm considers two sets \(S_1\) and \(S_2\) of approximately the same size, such that \(S\subseteq S_1\odot S_2\). We generalize it to: \(S \subseteq S_1^{(0)} \odot \cdots \odot S_1^{(t - 1)} \odot S_2,\)

such that \(|S_1^{(j)}| = O(d^{1/t})\) and \(|S_2|\leq2^{t - 1}=O(1)\), where \(t\) is a small integer.

Most importantly, we ensure that the multiplicative depth of \(S_2\) is \(t - 1\) levels higher than that of \(S_1^{(j)}\). Then,

1. First, use the binary-tree method to construct \(S_1^{(j)}\) and \(S_2\).
2. Second, reconstruct \(S_1\) based on \(S_1^{(j)}\) and calculate \(y_j := f^{(j)}(x)\), without performing modulus switching during this process.
3. Finally, calculate \(f(x)\) based on \(y_j\) and \(S_2\).

Since the multiplicative depth of \(S_1\) calculated in step 2 does not exceed the multiplicative depth \(\ell_2\) of \(S_2\), the multiplicative depth spent by the above algorithm is \(\ell_2 + 1\), which is the same as that of the original BSGS algorithm. Let’s briefly analyze the number of modulus switches spent by this algorithm: Step 1 requires \(t\cdot O(d^{1/t})+2^{t-1}\) modulus switches, step 2 no longer requires modulus switches, and step 3 requires \(O(1)\) modulus switches. In total, it spends \(O(d^{1/t})\) modulus switches.

The decomposition of the set \(S\) is not unique. By generalizing the decomposition method in the original BSGS, we present a simple method based on digit decomposition. Suppose \(\ell=\lceil\log d\rceil\), set \(\ell'=\ell-(t - 1)\), \(\ell''=\ell'/t\) and \(B = 2^{\ell''}\). Define the sets

and

where the multiplicative depth of \(S_1^{(j)}\) is \((j + 1)\cdot\ell''\leq\ell'\), which is \((t - 1)\) levels shallower than the multiplicative depth \(\ell\) of the set \(S_2\). The figure below shows the relative relationship of the multiplicative depths of each set.

3.2 Complete Version

In the above-mentioned algorithm, there are still two directions for optimization:

• Reduce the number of key switches. Since \(t\) is a small integer, even if no relinearization is performed in step 2, the ciphertexts in the obtained \(S_1\) are polynomials in \(\mathcal{R}_q[\mathbf{S}]\) with degree at most \(t\). We postpone all relinearizations to step 3, utilizing the lazy technique along with a larger key-switching key.
• Reduce the number of tensor products. The size of the set \(S_1\) is \(O(d^{1/t})^t = O(d)\), so step 2 requires the computation of \(O(d)\) tensor products. This can be reduced to \(O(\sqrt{d})\) by re-applying the BSGS algorithm, which we term the ”Internal BSGS Subroutine”.

Specifically, let \(t'=\lceil t/2\rceil\) and define

and

Then, it can be proven that \(\bar{S}_1\subseteq S_1^{(0)}\odot\cdots\odot S_1^{(t'-1)}\), \(\hat{S}_1\subseteq S_1^{(t')}\odot\cdots\odot S_1^{(t - 1)}\) and \(S_1\subseteq \bar{S}_1\odot\hat{S}_1\), where \(|\bar{S}_1| \approx |\hat{S}_1| = O(\sqrt{d})\). Similar to the original BSGS algorithm, based on the pre-computed \(\bar{S}_1\) and \(\hat{S}_1\), the \(y_j\) in step 2 can be calculated rapidly.

Given a polynomial \(f(X)=\sum_j f^{(j)}(X)\cdot(X^{B^t})^j\) and the ciphertext of the value \(x\), the steps of the asymmetric BSGS algorithm are as follows:

1. First, compute \(S_1^{(j)}\) and \(S_2\), which costs \(O(d^{1/t})\) standard homomorphic multiplications.
2. Second, construct \(\bar{S}_1\) and \(\hat{S}_1\) based on \(S_1^{(j)}\), and then use the Internal BSGS Subroutine to compute \(y_j := f^{(j)}(x)\). During this process, only \(O(\sqrt{d})\) tensor products are performed.
3. Finally, perform modulus switching and relinearization on \(y_j\), and then compute \(f(x)\) based on \(S_2\). Here, it costs \(O(1)\) standard homomorphic multiplications.

This provides a description of the high-level abstraction of the asymmetric BSGS algorithm.

3.3 Specific Implementation

Due to the fact that different leveled FHEs adopt different encoding strategies, there are subtle differences in the specific implementation of the asymmetric BSGS algorithm.

• BGV uses LSB encoding and NTT packing, with explicit ciphertext levels and modulus switching. The asymmetric BSGS algorithm fully adheres to the description in the previous subsection.
• CKKS uses fixed-point number encoding and DFT packing, with explicit ciphertext levels, and modulus switching is replaced by rescaling. The asymmetric BSGS algorithm also fully follows the description in the previous subsection, and its computational accuracy is close to that of the original BSGS algorithm.
• BFV uses MSB encoding and NTT packing, and modulus switching is implicitly performed during the tensor product, making it difficult to actively relax the noise control. For Step 2, we suggest to first convert all the BFV ciphertexts in \(S_1^{(j)}\) to BGV ciphertexts², then compute the tensor products, and finally convert \(\bar{S}_1\) and \(\hat{S}_1\) back to BFV ciphertexts.

3.4 Complexity Analysis

The following table compares the asymptotic complexity of the asymmetric BSGS algorithm with that of the original BSGS algorithm and its recursive variant (Paterson-Stockmeyer algorithm).

A recent article³ proposed an automorphism-based polynomial evaluation algorithm with a computational complexity of only \(O(\log d)\). However, this algorithm depends on a specific algebraic structure and can only support polynomial evaluations of limited degrees, so it is excluded here.

To keep the description concise, we ignored the influence of the constant \(t\) in the asymptotic complexity of the asymmetric BSGS algorithm. However, we note that as \(t\) increases, there is a factor of \(t\) hidden in the complexity of key switching and modulus switching, and a factor of \(2^{t - 1}\) hidden in the complexity of tensor products. Therefore, for any fixed $d$, there is a turning point at which increasing \(t\) further will instead increase the overall computational cost.

To strike a balance between the positive and negative effects, we conducted a series of experiments. The results show that for polynomials of degree less than 65536, setting \(t = 4\) yields the optimal performance in most scenarios. An interesting follow-up direction would be to mitigate the negative impact of the parameter $t$ in this asymptotic complexity, so as to further increase its value.

The figure below shows the exact number of modulus switches and key switches in the asymmetric BSGS algorithm with different parameters. Although it performs worse than the Paterson-Stockmeyer algorithm for polynomials of low degrees, as the degree of the polynomial increases, the number of modulus and key switches is only a fraction of that in the Paterson-Stockmeyer algorithm.

4. Applications

The asymmetric BSGS algorithm is universal and can handle the evaluation tasks of polynomials of any degree in all leveled FHEs.

All homomorphic computing tasks that rely on high-degree dense polynomial evaluation will benefit from this, including leveled FHE bootstrapping and LWE amortized bootstrapping. For example, we obtain the following accelerations:

• \(2.9\times\) improvement in throughput for the bootstrapping of BGV presented in paper⁴.
• \(3.5\times\) decrease in latency for a recent amortized bootstrapping for LWE ciphertext presented in paper⁵.

5. References

TL;DR: We introduce a new high-precision CKKS bootstrapping method. It leverages a novel Integer Cleaning strategy inspired by the Discrete CKKS technique and is implemented using the Grafting technique. We highlight its main building blocks and discuss its efficiency.

Why High-Precision Bootstrapping Matters

CKKS bootstrapping aims to refresh ciphertexts by increasing their modulus while preserving the encrypted message, enabling further homomorphic computations. However, bootstrapping introduces an approximation error. Most existing implementations achieve 5–25 bits of precision, where the bit-precision can be defined as the negative base-2 logarithm of the worst-case error, measured across many runs.

Some advanced applications, however, require much smaller error to support stronger security properties such as Circuit Privacy and IND-CPA-D Security. It is also important for Threshold-FHE (see this blogpost). These are often achieved via noise flooding—adding large noise relative to the error before decryption—which blinds the secret-dependent error terms but also the lower bits of the message. To retain precision after flooding, the pre-flooding precision must be higher, typically 64–80 bits or more.

Supporting such high precision securely and efficiently is a key challenge in CKKS bootstrapping. In LLK+22¹, a high-accuracy polynomial approximation for modular reduction \(x \mapsto (x \bmod q)\) was introduced. This approximation enables high-precision CKKS bootstrapping, though it incurs enormous modulus consumption. Note that larger modulus consumption during bootstrapping leaves fewer levels available for subsequent computations, which necessitates more frequent bootstrappings and thus significantly increases the overall cost. BCC+22² introduced Meta-BTS, which achieves high precision by performing multiple sequential low-precision bootstrapping, at the cost of increasing latency linearly in the target precision. This approach also consumes slightly more modulus.

EvalRound+ Paradigm for High Precision

We follow the EvalRound+ paradigm as the first building block of high-precision CKKS bootstrapping. It differs slightly from the traditional CKKS bootstrapping. Let’s first recall the traditional CKKS bootstrapping pipeline:

Assume a ciphertext encrypting a message \(m\) (or the coefficient vector of a polynomial) under modulus \(q_0\). In the ModRaise step, the ciphertext modulus is extended from \(q_0\) to a larger modulus \(Q\), which introduces an extra integer polynomial \(I\) multiplied by \(q_0\). As a result, the ciphertext encrypts \(m + q_0I\), so an EvalMod step is needed to reduce the message modulo \(q_0\) and recover \(m\). To enable this modular reduction on the encrypted message, the ciphertext is first transformed from the coefficient domain to the slot domain via CoeffsToSlots. After EvalMod the result is mapped back to the coefficient domain using SlotsToCoeffs. Alternatively, one can place SlotsToCoeffs at the beginning. Here, we focus on the ModRaise-first variant, as the technical details are equivalent.

The EvalRound+ paradigm³, replaces EvalMod with a subroutine called EvalRound and branches into two parallel tracks. EvalRound⁴ is \(\text{EvalRound} = \text{Id} - \text{EvalMod}.\) That is, while EvalMod extracts the message \(m\) from \(m + q_0 I\), EvalRound extracts \(q_0 I\).

The EvalRound+ procedure begins with ModRaise and then splits into two tracks:

• the first track applies the standard CoeffsToSlots algorithm, and
• the second track uses a low-precision CoeffsToSlots* followed by EvalRound.

Then it subtracts the two resulting ciphertexts, and concludes with SlotsToCoeffs.

The two branches produce ciphertexts encrypting \(m + q_0 I\) and \(q_0 I\), respectively; subtracting them yields a ciphertext encrypting \(m\), which is then passed through SlotsToCoeffs to return to coefficient representation. Although the dual-track structure increases latency, it reduces modulus consumption, since only the second track dictates the modulus consumption and CoeffsToSlots* consumes much less modulus than the usual CoeffsToSlots algorithm.

To enable high-precision bootstrapping, one can upgrade CoeffsToSlots, EvalRound, and SlotsToCoeffs to their high-precision versions. Each requires larger scale factors (which is used for encodings to scale the real/complex messages) increasing modulus consumption. By contrast, CoeffsToSlots* can remain low-precision and consume significantly less modulus compared to the other bootstrapping components. This marks a key distinction from traditional CKKS bootstrapping, where high-precision CoeffsToSlots contributes to overall modulus consumption.

The main challenge is that high-precision bootstrapping still requires substantial modulus. In particular, EvalMod and EvalRound rely on polynomial approximations of \((x \bmod q)\) and \((x - (x \bmod q))\), respectively. Achieving higher accuracy requires higher-degree polynomials, whose multiplicative depth grows as \(\Theta(\log t)\), where \(t\) is the target bit-precision. Since scale factors grow as \(\Theta(t)\), overall modulus consumption typically scales as \(\Theta(t \log t)\).

Integer Cleaning from Discrete CKKS

Let’s take a closer look at the EvalRound procedure. When treating \(q_0\) as a new scale factor, EvalRound maps \((I+m/q_0)\) to \(I\). More precisely, an erroneous integer \(I + \varepsilon\) is mapped to a (much less) erroneous integer \(I + \varepsilon'\) where \(\varepsilon := m/q_0\) and \(\varepsilon' \ll \varepsilon\). As it cleans a noisy integer, we may call this functionality Integer Cleaning.

To reduce modulus consumption in high-precision bootstrapping, we introduce a novel Integer Cleaning algorithm based on this idea. The process involves:

1. Digit Extraction: Decompose the noisy integer \(I+\varepsilon\) into base-\(\beta\) digits: For \(I = \sum_{i=0}^{\ell} I_i \beta^i,\) each noisy digit \(I_i + \varepsilon_i\) is extracted and stored separately. This can be done by either:
   • using direct polynomial approximation, mapping \(I\) into \(I_i \in [0, \beta)\), or
   • mapping \(I\) into \(\exp(2i\pi I / \beta^\ell)\), the complex \(\beta^\ell\)-th roots of unity (as in CKKL24⁵), and decomposing the digits via interpolation (as in BKSS24⁶).
2. Iterative Digit Cleaning: Apply low-degree polynomials iteratively to each noisy digit \(I_i\), to refine its precision:
   • (\(\beta = 2\)) \(h_1(x) = 3x^2 - 2x^3\) from CKK20⁷, or
   • (\(\beta = 3\)) \(\frac{1}{3}(\bar{x}^2 + 4x - 2x^2\bar{x})\) from BKSS24⁶.

   These polynomials quadratically clean the bits or trits (ternary digits), refining a \(t\)-bit precision to around \(2t\)-bit. In the end, it returns the cleaned digits \(I_i + \varepsilon'_i\) with \(\varepsilon'_i \ll \varepsilon_i\). Note that for each iteration, the scale factor must be large enough to support the cleaned digit, which roughly squares after each iteration. This implies that early iterations (and Digit Extraction) can use much smaller scale factors (e.g., 25–35 bits) than the desired integer cleaning precision.

3. Recombination: Combine the cleaned digits \(I_i + \varepsilon'_i\) to reconstruct the cleaned integer \(I + \varepsilon'\). This requires only integer multiplications and additions, with no extra modulus consumption.

Suppose the input \(I + \varepsilon\) to the Integer Cleaning algorithm has \(t\)-bit precision (i.e., \(|\varepsilon| \leq 2^{-t}\)). Then, with \(\text{iter}\) iterations of Digit Cleaning, the algorithm outputs an integer with \(\Theta(2^{\text{iter}} \cdot t)\) bits of precision.

Grafting

We leverage Grafting⁸ to efficiently support heterogeneous (i.e., small) scale factors without incurring additional RNS moduli or performance loss. This allows our implementation to achieve modulus-efficient and high-performance bootstrapping. For further details on RNS-CKKS and Grafting, see this blogpost.

Putting It All Together

The new CKKS bootstrapping is built on the EvalRound+ paradigm with the Integer Cleaning strategy and employs the Grafting technique. We note that the Integer Cleaning parts can be further optimized using a so-called Thrifty approach detailed in the paper.

In our proof-of-concept implementation, we used a ring dimension of \(N=2^{16}\) with full-slot messages. With bit decomposition (\(\beta = 2\)), the direct approximation method for bit extraction, and three iterations of bit-cleaning, our bootstrapping achieved 81 bits of precision. We compared this with Meta-BTS, which requires four sequential bootstraps to reach similar accuracy. Our bootstrapping achieved a 1.64× speedup, while still leaving 494 bits available for homomorphic computations.

We note that the bootstrapping scales naturally with the desired precision, thanks to its iterative nature. By adjusting the number of digit-cleaning iterations, one can flexibly target either lower or higher bootstrapping precisions. For instance, adding one more iteration yields roughly 150 bits of precision still at \(N=2^{16}\), with only a modest increase in latency.

In summary, the new bootstrapping method, combining EvalRound+, Integer Cleaning, and Grafting, enables high-precision CKKS bootstrapping that is modulus-efficient and high-performance, offering a practical solution for advanced homomorphic encryption applications.

References

TL;DR: Fully Homomorphic Encryption (FHE) programming hits a fundamental Turing Barrier where secure computation forbids the dynamic branching that makes conventional software work, forcing it into a parallel-first paradigm surprisingly similar to the high-performance GPU model. This means the future of FHE isn’t a magic compiler, but a hybrid architecture where a trusted client orchestrates complex logic, while an untrusted server executes simple, branchless secure kernels on encrypted data across a well-defined offloading boundary. Ultimately, developers must stop trying to translate old optimization habits and start redefining problems from the ground up, because in the world of FHE, performance isn’t about pruning—it’s about parallelism.

Abstract

Fully Homomorphic Encryption (FHE) and high-performance GPU computing have evolved under fundamentally different pressures—security and performance—yet I argue that their programming models are converging toward a branch-free, massively parallel paradigm.

This convergence arises from FHE’s Turing Barrier: while FHE is theoretically Turing-complete at the gate level, supporting secret-dependent control flow securely is practically infeasible without incurring combinatorial overheads. Meanwhile, GPUs evolved under different constraints—avoiding warp divergence—but reached similar design instincts: uniform, parallel-first kernels.

However, FHE introduces strictly stronger constraints than GPUs:

• Every kernel must be data-oblivious.
• Memory access patterns must remain uniform.
• The Host ↔ Device (Trusted-Host ↔ Secure-Kernel-Executor in the FHE context) offloading boundary must be formally defined.

Using Quicksort and Approximate Nearest Neighbor (ANN) search as case studies, I show why pruning-based optimizations—highly effective in plaintext—become anti-secure (i.e., the act of optimization itself introduces security vulnerabilities contrary to the original intention) under encryption. Recent works, including the FHE compiler project HEIR¹, programmable bootstrapping optimizations², and private inference frameworks³, confirm these fundamental constraints, demonstrating incremental improvements within fixed sandboxes but falling short of general solutions.

I conclude that the future of practical FHE lies in hybrid architectures where trusted clients orchestrate control flow and untrusted servers execute branchless, parallel secure kernels. GPU programming models provide valuable blueprints, but advancing secure computation demands an FHE-native programming model.

Table of Contents

1. Introduction
2. Background: Fundamental Constraints
   2.1. The FHE Security Model and the Turing Barrier
   2.2. How FHE Compilers Handle Control Flow
   2.3. Compilation Resource Explosion Warning
   2.4. Programmable Bootstrapping and Its Limits
   2.5. Memory Access and ORAM Lower Bounds
3. Convergent Evolution: FHE and GPUs
4. A Practical Architecture: The Hybrid Model
5. Case Studies: The Parallel-First Imperative
6. Comparative Analysis of Recent Research
7. Implications for FHE Systems
8. Conclusion: The Path to FHE-Native Development
9. References

1. Introduction

Fully Homomorphic Encryption (FHE) enables arbitrary computation on encrypted data without exposing plaintexts⁴. Meanwhile, GPUs have revolutionized computing by enabling massive parallelism, powering deep learning and high-performance computing⁵.

Despite different origins, these two paradigms now face structurally similar challenges. The need for a parallel-first model in FHE arises from a dual mandate:

• Security: Translating secret-dependent branching from conventional programs introduces critical side-channel leakage risks, forcing a branchless, data-oblivious model.
• Performance: FHE operations are often heavily memory-bound, and mitigating the I/O overhead caused by chaining multiple operations requires exploiting massive parallelism via fused, coarse-grained kernels.

This blog explores why these dual pressures lead to a convergence with the GPU model, why traditional optimizations fail, and why the future depends on building a new ecosystem of FHE-native, fused kernels managed by a smart, hybrid architecture.

2. Background: Fundamental Constraints

2.1 The FHE Security Model and the Turing Barrier

An FHE scheme evaluates $f(\mathrm{Enc}(x)) \rightarrow \mathrm{Enc}(f(x))$ without revealing $x$. However, secure execution forbids revealing control flow or memory access patterns derived from secret data.

Dynamic branches and loops are problematic:

• if-else decisions → leak branch outcomes.
• Secret-dependent loops → leak iteration counts.

Thus, FHE programs must adopt data-oblivious execution⁶:

• Evaluate both paths of all branches.
• Fix loop bounds to public constants.
• Make memory accesses uniform.

This reality is summarized as the Turing Barrier: FHE remains Turing-complete in theory at the gate level, but we use this term to describe the practical infeasibility of securely compiling general-purpose programs that rely on unrestricted control flow.

2.2 How FHE Compilers Handle Control Flow

Many developers assume FHE behaves like a traditional runtime: write an if statement, and only the chosen branch executes. But this would leak secrets—if the server observes which path was taken, it learns private data.

In FHE, both branches must always execute. The compiler produces an arithmetic select: \(\mathrm{Enc}(r) = \mathrm{Enc}(\text{cond}) \cdot \mathrm{Enc}(r_a) + (1 - \mathrm{Enc}(\text{cond})) \cdot \mathrm{Enc}(r_b)\)

Key takeaway: Under FHE, writing if (encrypted(cond)) ... in source code does not imply conditional execution; the compiler always executes both paths and combines results securely.

2.3 Compilation Resource Explosion Warning

The combinatorial blow-up caused by encrypted control flow affects not only runtime performance but also the compilation process itself. For every secret-dependent branch, the FHE-aware compiler must materialize all possible subroutines into encrypted circuits. In the worst case, $N$ nested conditions yield a circuit size of $O(2^N)$.

Recent experiments with LLVM-based FHE Intermediate Representations (IRs) such as HEIR ¹ highlight this challange. While research explores sophisticated optimizations to avoid naive full unrolling (e.g., by hoisting common code from both branches), these techniques can only mitigate the overhead for shared computational paths. For genuinely divergent logic, the compiler must still materialize a circuit whose complexity grows exponentially with the number of secret-dependent branches.

It is therefore an expected and observable outcome that beyond a certain branching complexity, this exponential growth will cause the compiler to exhaust system resources, leading to out-of-memory (OOM) errors—before execution even begins. This demonstrates that directly translating branch-heavy business logic is infeasible. Problem redefinition is not an optimization choice — it is a requirement for tractable FHE compilation.

2.4 Programmable Bootstrapping and Its Limits

TFHE’s Programmable Bootstrapping (PBS)⁷ and CKKS’s BB-BTS (Batch-bits Bootstrapping)⁸ enable efficient Look-Up Table (LUT)-based evaluation of small non-linear functions. Recent works on optimizing these circuits² further reduce cost by compressing LUT evaluation.

However, PBS does not eliminate the combinatorial blow-up of complex business logic:

• Optimizations are pattern-limited, applicable to fixed, low-dimensional functions.
• Decision-tree inference using private inference frameworks like Piranha³ works only for small, fixed-depth trees; adaptive branching remains insecure.

PBS provides a valuable tool but not a universal escape hatch.

2.5 Memory Access and ORAM Lower Bounds

Just as control flow must be made data-oblivious, memory access patterns must also be protected. When computations require secret-dependent memory access, Oblivious RAM (ORAM) must be used to hide patterns⁶. However:

• ORAM has a provable lower bound: $\Omega(\log n)$ per access, where n is the number of blocks in memory.
• Even optimal constructions like OptORAMa⁹ cannot break this limit.
• For large-scale workloads, ORAM costs dominate if memory access depends on secrets.

Implication: Secret-driven memory access cannot be made “cheap” under FHE. Algorithms must be redesigned to avoid adaptive memory patterns.

3. Convergent Evolution: FHE and GPUs

FHE and GPU computing converge structurally, driven by the dual pressures of security and performance.

FHE’s constraints are stricter, mandating a more intentional and formally defined programming model than the emergent, pragmatic model of GPUs. We must explicitly define host-device offloading and design kernels intentionally.

4. A Practical Architecture: The Hybrid Model

Terminology Note: I borrow the host-device terminology from GPU programming models for intuitive consistency. In the FHE context:

• Host → Trusted-Host: Orchestrates application logic, manages secret-dependent control flow, and launches secure kernels.
• Device → Secure-Kernel-Executor: Executes branchless, data-oblivious kernels on encrypted inputs in an untrusted environment.

4.1 Note on GPU Programming Models

Although I borrow GPU programming terminology, GPU programming models themselves are not fully standardized. Offloading is often API-driven via libraries like cuBLAS or TensorRT, not formal control-flow abstractions. This implies an even greater challenge for FHE: we must explicitly define the offloading boundary, because FHE imposes far stricter constraints than GPUs.

5. Case Studies: The Parallel-First Imperative

Developers often misconceive that FHE’s Turing completeness at the gate level implies pruning-based optimizations can be directly ported. However, pruning is anti-secure.

5.1 Sorting

• Quicksort (FHE-unfriendly): Adaptive pivots and partitions leak structural information.
• Sorting Networks (FHE-Friendly): Fixed compare-swap sequences (e.g., Bitonic Sort) are uniform, oblivious, and parallelizable.

5.2 Approximate Nearest Neighbor (ANN)

In this context, N represents the total number of vectors in the dataset, d is the dimension of each vector, k is the number of clusters in the IVF index, and n_probe is the number of clusters to probe during a search.

• IVF-FLAT (FHE-unfriendly): This popular method works by first selecting a few (n_probe) cluster centroids nearest to the query, then searching only within those clusters. This adaptive probing leaks which clusters the query is close to.
• HNSW (FHE-unfriendly): Adaptive graph traversal leaks query-specific paths¹⁰.
• Brute-Force Scan (FHE-Compatible): Evaluate distances for all vectors uniformly.

Key Insight: In FHE, brute force is the baseline, not the fallback. Performance gains come from parallelizing fixed workloads, not pruning.

6. Comparative Analysis of Recent Research

Recent progress expands FHE’s reach but validates the central thesis: general-purpose, efficient, secure FHE requires problem redefinition, not direct translation.

7. Implications for FHE Systems

• FHE-aware compilers must act as policy enforcers, not magicians:
  • Convert branches into predicated arithmetic.
  • Enforce loop unrolling to constant bounds.
  • Optimize SIMD-style ciphertext packing.
• Hardware accelerators for FHE will increasingly resemble GPUs:
  • High-throughput execution cores.
  • On-die NTT engines.
  • High-bandwidth memory for ciphertext batching.
• Design implication: The parallel-first paradigm isn’t just optimal — it’s necessary for secure performance.

8. Conclusion: The Path to FHE-Native Development

The theoretical Turing completeness of Fully Homomorphic Encryption (FHE) may suggest that any software can be privatized with a magical compiler. In reality, secure computation faces a fundamental Turing Barrier: the dynamic, branching-based optimizations that make conventional software efficient become the very conduits that leak secrets under encryption. The future of FHE, therefore, depends not on translating legacy code, but on redefining problems from first principles.

The most pressing challenge is FHE’s dominant performance bottleneck: memory I/O. Optimizing individual operations in isolation is insufficient; for any non-trivial business logic, the cumulative overhead of sequential IR-level kernels quickly makes applications impractical. Inspired by high-performance GPU computing, the solution is to move from fine-grained primitives toward a hierarchy of fused, coarse-grained kernels—reducing data movement, exploiting massive parallelism, and unlocking practical performance.

Building these kernels also solves the ecosystem’s chicken-and-egg problem: useful, coarse-grained kernels must come first to create immediate value, attract developers, and enable sustainable growth. A lightweight orchestration framework can manage this efficiently, where the trusted host performs simple runtime scheduling—dispatching fused kernels when available and falling back to basic ones otherwise. Since scheduling depends only on the public sequence of API calls, it remains inherently secure.

Beyond kernels, the next step is to formalize the offloading boundary between the trusted host and the secure executor. Unlike GPU computing, where offloading is pragmatic and API-driven, FHE’s boundary is a security contract that must be explicit and rigorously defined. Establishing this foundation transforms FHE development from a set of clever hacks into a true engineering discipline.

Ultimately, this leads to a truly FHE-native programming model. Compilers will evolve from magical translators into policy enforcers, guiding developers toward parallel-first problem formulations. By combining optimized fused kernels with explicit host-device boundaries, we can unlock scalable, secure, and high-performance computation—turning FHE from a theoretical promise into a practical reality.

Looking further ahead, inspiration can be drawn from quantum computing, where developers also work within strict constraints, composing algorithms from a limited set of gates while carefully managing entanglement. Similarly, tomorrow’s FHE developers will think less like conventional software engineers and more like quantum algorithm designers—crafting solutions in a fundamentally constrained, parallel-first universe.

Stop translating. Start redefining.

9. References

TL;DR: NeuJeans introduces a new “Coefficients-in-Slot” (CinS) encoding for CKKS. It rethinks how convolutions are laid out and fuses them with bootstrapping, cutting latency on big models like ResNet running over ImageNet.

CKKS relies on the Ring Learning With Errors (RLWE) problem to encrypt messages into a single ciphertext. This ring structure is key to CKKS’s efficiency, as a single homomorphic operation can act on all encrypted values in parallel.

However, the same structure complicates FHE circuit design. Linear algebra in the RLWE format often forces interactions within a ciphertext, which can dominate runtime by requiring many costly rotations¹. Consequently, an FHE program’s profile can differ significantly from its plaintext counterpart. In deep circuits such as neural networks, bootstrapping further amplifies this challenge.

Encodings in CKKS

In CKKS, the data arrangement within a ciphertext’s underlying polynomial is called its encoding. Different encodings are optimized for different types of computations. Choosing the correct ones and switching between them during an algorithm is crucial for overall performance. The two primary encodings are slot encoding and coefficient encoding. Since CKKS bootstrapping naturally involves transforms between these states, a well-designed application can perform computations in whichever encoding is most efficient at the moment.

In slot encoding, a ciphertext holds a vector of complex numbers in distinct “slots”, and all arithmetic operations are performed element-wise. This structure is ideal for operations that can be parallelized easily, such as applying activation functions to every element in a vector or multiplying a diagonalized matrix with a vector. However, data aggregation across slots relies on rotations, which are computationally expensive.

Conversely, in coefficient encoding, message values are placed directly into the coefficients of the ciphertext polynomial. A multiplication in this layout computes a negacyclic convolution. Formally, for vectors $\mathbf{x}, \mathbf{y} \in \mathbb{R}^\ell$, their product is

This is equivalent to a cyclic convolution with a “wrap-around and sign flip”, reflecting the polynomial modulus $X^\ell + 1$. Such convolutions align well with the operations fundamental to neural networks and signal processing. However, the RLWE ring degree $\ell$ (commonly $2^{14}$ or $2^{15}$ for 128-bit security) is much larger than the typical dimensions of images (e.g., $32 \times 32$ or $16 \times 16$). As a result, a single ciphertext implicitly encodes tens or even hundreds of images. This mismatch complicates efficient implementation, since it forces convolutions to occur across all channels simultaneously.

CinS, or Coefficients-in-Slot encoding, is a generalized structure that combines the properties of both slot and coefficient encoding. If the total message vector has size $\ell=m\times n$, CinS encoding treats the vector as $n$ independent sub-vectors (slots), each of length $m$. Operations are then element-wise across the $n$ sub-vectors but convolutional within each of the $m$ elements. This hybrid approach allows for parallel convolutions. When $m=1$, CinS reduces to standard slot encoding, and when $n=1$, it becomes standard coefficient encoding.

Encoding Transformation

Switching between these encodings is essential for building complex applications. The Slot-to-Coefficient (S2C) transform converts a ciphertext from slot encoding to coefficient encoding, while its inverse (C2S) does the reverse. Fundamentally, the S2C transform is a Discrete Fourier Transform (DFT). To perform it efficiently, the large \(\ell \times \ell\) DFT matrix is decomposed into a product of sparse matrices using the Cooley–Tukey Fast Fourier Transform (FFT) algorithm².

The decomposition is applied to the bit-reversed DFT matrix, \(\mathcal{T}_{\ell}\), which simplifies the FFT structure and is defined recursively:

Here, $I_{\ell/2}$ is the identity matrix, \(\mathcal{T}_{\ell/2}\) is the smaller bit-reversed DFT matrix, and $D_{\ell/2}$ is a diagonal matrix of complex “twiddle factors.” Applying this recursion $\log_2 \ell$ times decomposes $\mathcal{T}_\ell$ into a product of highly sparse, block-diagonal matrices.

Each matrix $S_k^{(\ell)}$ in this product is a sparse, block-diagonal matrix whose structure is derived from the butterfly operations at each stage of the FFT algorithm.

NeuJeans: CinS Encoding and Fused Operations

NeuJeans defines CinS encoding using a partial S2C transform. Instead of applying the full DFT, it applies only the first $\log_2{m}$ stages, leaving the ciphertext in an intermediate state between slot and coefficient encoding. Formally, for a message vector $\mathbf{x}$ and slot encoding $s(\mathbf{x})$, CinS is:

The strength of this encoding lies in its multiplication. The partial DFT places each sub-vector into coefficient form, so multiplying two CinS ciphertexts directly performs the desired operation: the element-wise negacyclic convolution of the sub-vectors. For two message vectors $\mathbf{x}, \mathbf{y}$, we have:

where each sub-vector of the output, $\mathbf{z}_j$, is the negacyclic convolution of the input sub-vectors:

This multiplication property allows NeuJeans to map the many 2D convolutions of a CNN layer into a single homomorphic multiplication.

The figure above illustrates this mapping: the image and kernel are zero-padded and flattened, with $I_n$ and $K_{m,n}$ converted into vector $i_n$ and $k_{m,n}$. As shown, the negacyclic convolution $o_{m,n}=i_n \circledast k_{m,n}$ is equivalent to 2D convolution result \(O_{m,n}=O_n*_{2D}K_{m,n}\). The extra terms ($x_1$ to $x_5$) that arise from zero-padding are later removed using a mask vector.

Fusing with Bootstrapping

NeuJeans goes further by fusing the convolution with bootstrapping. Bootstrapping already performs a full S2C transform; NeuJeans inserts the convolution midway, creating a sequence like: [Part 1 of S2C] -> Convolution -> [Part 2 of S2C]

Since both the convolution and the second half of S2C are sparse diagonal matrices, the server can precompute their product offline. At runtime, this reduces to: [Part 1 of S2C] -> [Fused convolution + Part 2 of S2C]

This fusion removes redundant steps, streamlining the bootstrapping process.

Application to Large-Scale CNN Inference

By combining CinS encoding with fused bootstrapping, NeuJeans enables faster 2D convolutions and a leaner S2C transform. We evaluated the approach on ResNet-18/50 and MobileNet-V2 using the HEaaN library. ResNet-18 and ResNet-50 are built primarily from standard convolution layers, whereas MobileNet-V2 adopts depthwise separable convolutions for efficiency.

Across all three models, NeuJeans consistently outperforms prior methods^{3 4} based on slot and coefficient encodings, achieving

• 7.7$\times$-30.3$\times$ speedup in convolution layers
• 1.47$\times$-1.84$\times$ speedup in total inference time

Overall, NeuJeans demonstrates how a small shift in encoding design—using CinS and fusing operations into bootstrapping–can deliver meaningful efficiency gains for encrypted CNN inference. These results underscore encoding design as an effective path for performance optimization. Looking ahead, we aim to extend this approach to emerging architectures, including diffusion models and graph neural networks.

TL;DR: We propose fast ciphertext-ciphertext matrix multiplication (CC-MM) algorithms for large matrices. Our algorithms consist of plaintext matrix multiplications (PP-MM) and ciphertext matrix transpose algorithms (C-MT). We introduce and utilize new fast C-MT algorithms for large matrices. By leveraging high-performance BLAS libraries to accelerate PP-MM, we implement large-scale CC-MM with substantial performance improvements.

The Matrix Has You

“The Matrix is everywhere. It is all around us. Even now, in this very room.” — Morpheus, The Matrix (1999), written by Lilly & Lana Wachowski

Matrix multiplication (PP-MM) is one of the central tasks in machine learning (ML). In particular, for large ML models, accelerating large matrix multiplication is important as its cost grows cubically with the dimension of the matrix. There exist many highly optimized open linear algebra libraries (BLAS libraries). On my machine using a single thread CPU, the OpenBLAS library took 1.47 seconds to multiply two large \(4096\times 4096\) matrices, which was 30x faster than my schoolbook implementation.

Matrix multiplication on encrypted data plays an important role in privacy-preserving ML, when a server trains or performs inference on ML models using encrypted data. For example, when using homomorphic encryption for large language models, one needs to multiply matrices of various dimensions either in encrypted or unencrypted form. For the multiplication between plaintext and ciphertext matrices (PC-MM), a recent work BCHPS24¹ significantly improved the efficiency compared to the state of the art, taking 17.1 seconds for \(4096\times 4096\) matrices on an Intel Xeon Gold 6242 CPU running at 2.80GHz, using a single thread.

However, ciphertext-ciphertext matrix multiplication (CC-MM) has been much slower than PC-MM and PP-MM. A notable work JKLS19² took 0.6 seconds for multiplying two \(64\times 64\) matrices on an Intel Core i9 CPU with 4 cores rated at 2.3GHz. If one naively utilizes JKLS19 for \(4096\times 4096\) matrices, it takes more than 19 hours. This is not desirable. Note that most of the current CC-MM implementations are based on JKLS19 or its variants.

As Fast As Matrix Multiplications in Clear

Reduction to PP-MM

A lower bound for the cost of PC-MM and CC-MM is the cost of PP-MM: if CC-MM becomes faster than PP-MM, we should replace all existing PP-MM codes with this new CC-MM implementation. How close can PC-MM and CC-MM be to PP-MM?

BCHPS24 suggested a strategy to answer this question by providing a reduction from PC-MM to PP-MMs. Precisely, they perform PC-MM by using multiple PP-MMs with other minor computations. It makes PC-MM comparable to PP-MM up to small constant factors. Note that the impact of this reduction strategy is significant in practice; JKLS19 would take several hours for large matrices even though the JKLS19 algorithm provides a good asymptotic complexity. The reduction allows to exploit BLAS-based PC-MM.

The reduction introduced in BCHPS24 starts with a simple equation borrowed from LZ22³. A bundle of coefficient-encoded CKKS ciphertexts encrypting each row of a plaintext matrix \(\textbf{V}\) corresponds to a pair of plaintext matrices \((\textbf{A}, \textbf{B})\) satisfying

where \(\textbf{S}^*\) is a structured matrix determined by the ciphertext format⁴ and the secret. Once multiplying a plaintext matrix \(\textbf{U}\) to above equation, it becomes

This process results in CKKS ciphertexts that encrypt each row of the product matrix \(\textbf{U}\cdot\textbf{V}\). This is a reduction from PC-MM to two plaintext matrix multiplications \(\textbf{U}\cdot\textbf{A}\) and \(\textbf{U}\cdot\textbf{B}\). A part of the results from BCHPS24 is the utilization of BLAS PP-MM libraries for various dimensional PC-MM tasks.

What about CC-MM?

One may ask whether we can reduce CC-MM to PP-MMs in the same way. However, CC-MM is not as easy as PC-MM. Suppose we have two bundles of CKKS ciphertexts that decrypt to \(\textbf{U}\) and \(\textbf{V}\), respectively. We can represent them as two pairs of matrices \((\textbf{A}_{\textbf{U}}, \textbf{B}_\textbf{U})\) and \((\textbf{A}_\textbf{V}, \textbf{B}_\textbf{V})\) such that \(\textbf{A}_\textbf{U} \cdot \textbf{S}^*+\textbf{B}_\textbf{U}~\approx~\textbf{U}\) and \(\textbf{A}_\textbf{V} \cdot \textbf{S}^*+\textbf{B}_\textbf{V}~\approx~\textbf{V}\). Once we multiply them, we obtain

In contrast to PC-MM, it does not reduce to PP-MMs between \(\textbf{A}_\textbf{U}, \textbf{B}_\textbf{U}, \textbf{A}_\textbf{V}\), and \(\textbf{B}_\textbf{V}\). The secret matrices \(\textbf{S}^*\) appears in the middle of the multiplications. To interpret this using CKKS ciphertexts, one may want to swap the order of matrix multiplication (e.g., \(\textbf{A}_\textbf{U} \cdot\textbf{B}_\textbf{V}\cdot \textbf{S}^*\) instead of \(\textbf{A}_\textbf{U} \cdot \textbf{S}^*\cdot\textbf{B}_\textbf{V}\) ). However, matrix multiplication is not commutative.

Ciphertext Matrix Transpose

Here is an approach to solve the above problem. For each \(\textbf{S}^*\cdot\textbf{M}\), suppose we can find an appropriate \(\textbf{M}'\) such that \(\textbf{S}^*\cdot\textbf{M}~=~\textbf{M}'\cdot\textbf{S}^*\). Once we find it, we replace \(\textbf{S}^*\cdot\textbf{M}\) with \(\textbf{M}'\cdot\textbf{S}^*\). Then, the above equation turns into

This reduces CC-MM to four PP-MMs, \(\textbf{A}_\textbf{U} \cdot \textbf{A}_\textbf{V}'\) , \(\textbf{A}_\textbf{U} \cdot\textbf{B}_\textbf{V}'\), \(\textbf{B}_\textbf{U}\cdot \textbf{A}_\textbf{V}\), and \(\textbf{B}_\textbf{U}\cdot \textbf{B}_\textbf{V}\), and a relinearization.

Let us take a step back to understand what \({\textbf{S}^*}\cdot\textbf{M}\) means. A bundle of CKKS ciphertexts encrypting each column of a plaintext matrix \(\textbf{V}\) corresponds to a pair of matrices \((\textbf{A}, \textbf{B})\) such that

Thereby, finding \((\textbf{A}', \textbf{B}')\) from \((\textbf{A},\textbf{B})\) such that \(\textbf{A}'\cdot\textbf{S}^*+\textbf{B}'~\approx~{\textbf{S}^*}^T\cdot \textbf{A} +\textbf{B}~\approx~\textbf{V}\) is equivalent to the ciphertext matrix transpose (C-MT) problem. Even though this is not exactly the same as finding \(\textbf{M}'\) from \(\textbf{M}\) that \(\textbf{S}^*\cdot\textbf{M}~=~\textbf{M}'\cdot\textbf{S}^*\), the above argument hints that a fast C-MT algorithm would be useful for fast CC-MM.

Algebraically, the C-MT is related to converting \(\{m_i(X)~\approx~ \sum_j \textbf{M}_{i,j}X^j \}_i\) into \(\{m_j'(X) ~\approx~ \sum_i \textbf{M}_{i,j}X^i \}_j\). We can use algebraic and algorithmic ideas to devise efficient C-MT algorithms. Please refer to Section 3 of Park25⁵ for the details. The paper introduces two C-MT algorithms, one focusing on the latency (Section 3) and the other focusing on the key size (Section 5). Independently, Craig Gentry has also sketched another C-MT approach involving bivariate polynomials in a recent talk in FHE.org conference.⁶

Ciphertext-Ciphertext Matrix Multiplication

Finally, we put it all together to devise a fast CC-MM algorithm for large matrices. Assume that we are given two pairs of matrices \((\textbf{A}_\textbf{U}, \textbf{B}_\textbf{U})\) and \((\textbf{A}_\textbf{V}, \textbf{B}_\textbf{V})\) such that \(\textbf{A}_\textbf{U} \cdot \textbf{S}^*+\textbf{B}_\textbf{U}~\approx~\textbf{U}\) and \(\textbf{A}_\textbf{V} \cdot \textbf{S}^*+\textbf{B}_\textbf{V}~\approx~\textbf{V}\). As previously mentioned, it implies that

The CC-MM algorithm follows the following steps.

1. It first performs C-MT on \((\textbf{A}_\textbf{U}, \textbf{B}_\textbf{U})\), obtaining a pair of matrices \((\underline{\textbf{A}}_\textbf{U}, \underline{\textbf{B}}_\textbf{U})\) that satisfies \({\textbf{S}^*}^T\cdot\underline{\textbf{A}}_\textbf{U}+\underline{\textbf{B}}_\textbf{U}\approx\textbf{U}\). Then,

   \[\textbf{U}\cdot\textbf{V}~\approx~({\textbf{S}^*}^T\cdot\underline{\textbf{A}}_\textbf{U}+\underline{\textbf{B}}_\textbf{U})\cdot(\textbf{A}_\textbf{V} \cdot \textbf{S}^*+\textbf{B}_\textbf{V}).\]

2. It computes four PP-MMs, \(\underline{\textbf{A}}_\textbf{U} \cdot \textbf{A}_\textbf{V}\), \(\underline{\textbf{A}}_\textbf{U} \cdot \textbf{B}_\textbf{V}\), \(\underline{\textbf{B}}_\textbf{U}\cdot \textbf{A}_\textbf{V}\), and \(\underline{\textbf{B}}_\textbf{U}\cdot \textbf{B}_\textbf{V}\), using fast BLAS libraries. Let \(\textbf{C}_{0,0}\) , \(\textbf{C}_{0,1}\), \(\textbf{C}_{1,0}\), \(\textbf{C}_{1,1}\) be the output matrices, respectively. Then, it holds that

   \[\textbf{U}\cdot\textbf{V}~\approx~{\textbf{S}^*}^T\cdot \textbf{C}_{0,0} \cdot \textbf{S}^*+{\textbf{S}^*}^T\cdot\textbf{C}_{0,1}+\textbf{C}_{1,0}\cdot \textbf{S}^*+\textbf{C}_{1,1}.\]

3. It transposes \((\textbf{C}_{0,0}, \textbf{0})\) and \((\textbf{C}_{0,1}, \textbf{0})\) to find matrices that \({\textbf{S}^*}^T\cdot \textbf{C}_{0,0}\approx \textbf{A}\cdot\textbf{S}^*+\textbf{B}\) and \({\textbf{S}^*}^T\cdot \textbf{C}_{0,1}\approx \textbf{A}'\cdot\textbf{S}^*+\textbf{B}'\). Since each entry of \(\textbf{S}^*\) is small, it impliest that \({\textbf{S}^*}^T\cdot \textbf{C}_{0,0}\cdot \textbf{S}^*\approx \textbf{A}\cdot{\textbf{S}^*}^2+\textbf{B}\cdot \textbf{S}^*\). After several matrix additions, it obtains three matrices \((\textbf{C}_2, \textbf{C}_1, \textbf{C}_0)\) such that

   \[\textbf{U}\cdot\textbf{V}~\approx~\textbf{C}_2 \cdot{\textbf{S}^*}^2+\textbf{C}_1\cdot\textbf{S}^*+\textbf{C}_0.\]

4. It relinearizes and rescales each row of \((\textbf{C}_2, \textbf{C}_1, \textbf{C}_0)\) as is done usually in CKKS. It finally obtains a pair of matrices \((\textbf{A}_\times, \textbf{B}_\times)\) such that

   \[\textbf{U}\cdot\textbf{V}~\approx~\textbf{A}_\times\cdot\textbf{S}^*+\textbf{B}_\times.\]

   This corresponds to CKKS encryptions of the product matrix \(\textbf{U}\cdot\textbf{V}\), completing the CC-MM.

Note that the algorithm consists of three C-MTs and four PP-MMs. The cost of C-MT is asymptotically minor compared to the cost of PP-MM, and one can fully utilize the high efficiency of BLAS libraries for the PP-MMs. The implementation in Park25⁵ took 85.2 seconds to multiply two \(4096\times 4096\) encrypted matrices on an Intel Xeon Gold 6242 CPU running at 2.80GHz, using a single thread. This is a huge improvement compared to the previous 19 hours. Park25⁵ introduces another CC-MM algorithm that focuses on the key size, so take a look if you are interested!

Next Steps

In the more recent work BCHPS25⁷, which is an extended and consolidated journal version of this paper and BCHPS24, my colleagues and I introduce fast CC-MM algorithms with pre-computations. As a future direction, it would be interesting to explore whether CC-MM for small-dimensional matrices can be reduced to PP-MM of the same dimensions, without any pre-computations.