Now that we have seen a formal presentation of FHE and an overview of the existing landscape, we move on to more practical aspects. Colloquially, it is often said that FHE allows the execution of any function on encrypted data, yet performing a division or taking the square root remain open problems in this field. We will see in a second that what seems like a contradiction at first glance is actually due to the imprecision of the colloquial wording.
1.3.1 The Importance of Encoding
Concretely, suppose there is a function g : Sn → S for some domain S (e.g., S = R) which a user wants to evaluate. However, FHE schemes have finite fields11 GF (pk) as their plaintext spaces – some restricted to GF (2), some allowing arbitrary fields. In any case, no FHE scheme (or any encryption scheme, to be exact) has a plaintext space of N or Q or R, or more generally S if S can be chosen arbitrarily. Denoting the plaintext space of the Fully Homomorphic Encryption scheme with P and the ciphertext space12
with C, we thus first need to map the domain S to a tuple of plaintexts and find a function f that does the same thing as g, but operates on this tuple of plaintexts rather than S. Fully Homomorphic Encryption now promises that there is a function f∗ that operates on a tuple of ciphertexts and computes the same thing as f . Note that this is also the source of the perceived contradiction mentioned above: FHE allows a user to compute any function that they can compute on the plaintext space on encrypted data instead – if the function cannot be expressed on the plaintext space, Fully Homomorphic Encryption offers no such guarantees. We have illustrated the different conceptual components involved in homomorphically computing a function in Figure 1.1.
Sn S (Pk)n Pk (Ck)n Ck g f f∗ π π−1 Enc Dec Function Space: Plaintext Space: Ciphertext Space:
Figure 1.1: Steps in homomorphic evaluation
Fully Homomorphic Encryption tells us that if the upper half of the diagram is commuta- tive, then so is the entire diagram. We see that there are three main components to FHE computations: Mapping the function domain into the plaintext space (upper rectangle, green), encrypting the plaintexts (middle rectangle, orange), and running the function on the ciphertexts (lower rectangle, pink), which often involves some effort in expressing g in
11
A finite field is an algebraic structure of the form GF (pk) = Zp[X]/(f (X)) for a prime p and an
irreducible polynomial f (X) of degree k. Its elements are of the form
k−1
X
i=0
aiXiwith ai∈ {0, 1, . . . , p − 1},
i.e., all polynomials of degree at most k−1 with coefficients in {0, 1, . . . , p−1}. Computations are performed using regular polynomial addition and multiplication, reducing by the coefficients by p and the monomials by f (X).
12Recall that in Definition 1.1, we differentiated between the space of fresh ciphertexts generated by
encryption, X , and the space of evaluation outputs, Y. Since we implicitly assume circuit privacy, these two spaces fall together, so that the notion of a ciphertext space is well-defined.
a way such that it can run on the ciphertexts – i.e., tranforming g into f (resp. f∗). Research on Fully Homomorphic Encryption schemes and improving their efficiency forms the orange box - this aspect was covered in Section 1.2. Our work focuses on the remaining two boxes: We first analyze the costs of different encoding choices with respect to the underlying plaintext space GF (pk) for natural numbers, integers and rational numbers. This comprises the green upper box. We then apply our results to concrete algorithms from the field of Machine Learning, which usually run on rational numbers. We show how to move from rationals to finite fields for these cases, and modify the algorithms to allow more efficient evaluation. This constitutes the pink lower box.
1.3.2 Cost Metrics
When we analyze the costs of different encoding bases for FHE computations, the first question that comes to mind is how to define the cost. As it turns out, there is no definitive answer to this question, as there are different possible cost metrics.
Suppose a number is encoded by a set of digits, which are finite field elements. Then encrypting the number means encrypting each digit separately, and computing on the encrypted number is achieved through manipulation of the individual encrypted digits. Thus, we need to emulate the original computation (e.g., adding two numbers) through finite field operations on the plaintext digits that result in a sequence of digits encoding the correct result of the computation. This digit-wise computation can then also be performed on the encrypted digits. Consequently, we express the effort with regard to the underlying finite field operations although in reality, they would be performed on the encrypted digits in the ciphertext space.
In this work, we examine the following three cost metrics:
• Multiplicative Depth: As we have mentioned in the context of Definition 1.9, all FHE schemes that we have today are noise-based, in that the plaintext is masked with noise which accumulates with each operation. Concretely, each multiplication of ciphertexts doubles the length of the noise, and each addition increases the length by 1. When the noise passes a certain threshold, decryption fails and the result is lost. The bootstrapping procedure can remove this noise, but it is a very slow procedure and often the bottleneck of the computation. For this reason, minimizing the number of bootstrappings by minimizing the number of consecutive multiplications, also known as multiplicative depth, has frequently been a goal in FHE computations. As an example, consider the product of 4 ciphertexts c1·c2·c3·c4. Then the multiplicative
depth depends on the order in which we perform the multiplications: If we compute c1· (c2· (c3· c4)), we get a multiplicative depth of 3. However, if we were to compute
the product as (c1· c2) · (c3· c4), we instead get a depth of only 2. Multiplicative
depth is closely related to the concept of Levelled FHE (Definition 1.12), where the expected number of bootstrappings determines the number of levels. It can be considered as the most traditional cost metric in this field.
• Number of Field Multiplications: For most FHE schemes, ciphertext multiplica- tions are much more expensive than ciphertext additions – so much so that additions are considered “free” by comparison. Thus, it naturally makes sense to keep track of this number. Additionally, when using p-adic encoding, the multiplicative depth quickly becomes so large that bootstrapping is unavoidable, so that minimizing the
total number of multiplications can significantly speed up computations. To see this, consider a parameter setting where there is a bootstrapping operation performed af- ter every multiplication. In this case, the depth is completely irrelevant, and the total number of multiplications completely dominates the computation time. This line of reasoning also extends to less extreme parameter settings, so we regard this as an important metric as well.
• Number of Field Additions: For the first and second generation FHE schemes, ciphertext multiplications were a lot more costly than ciphertext additions, but we have always pointed out ( [JA16], [JA17]) that there is no theoretical reason why this must be the case. With [CGGI16], there now indeed exists a scheme where every gate is bootstrapped after execution (because they were built from the even more elementary NAND-gate specifically supported by that scheme), and thus there is no significant difference between the two. Thus, we also keep track of the total number of ciphertext additions that need to be performed.
1.3.3 Related Work on FHE Encodings
In the last few years, there has been a large increase in papers about encodings for Fully Homomorphic Encryption. This illustrates the importance of this field, and we give a short overview of these works at this point.
One of the first works to address this topic was [NLV11], where integers are encoded as polynomial ring elements in a bitwise, straightforward fashion. In contrast, our work also accommodates rational numbers instead of being restricted to integers. [CK16] uses continued fractions to encode rational numbers, but is restricted to positive rationals and evaluating linear multivariate polynomials, whereas we allow signed rationals and arbitrary functions. [CSVW16] and [DGBL+15] focus on most efficiently embedding a computation into a single large plaintext space, and the latter also offers an implementation. However, embedding the computation into a large plaintext space is actually Somewhat Homomor- phic Encryption (see Definition 1.10), as opposed to Fully Homomorphic Encryption as in our work: The plaintext space must be chosen to accommodate the computations, and thus the possible computations are in turn limited by the plaintext space. An extension of [FV12] that allows floating point numbers is presented in [AN16], and [CG15] gives a high-level overview of arithmetic methods for FHE, but resticted to positive numbers rather than arbitrary rationals as in our work. In [GC14], integers are encoded by modi- fying the underlying scheme [BV11b] to allow a natural mapping from an integer quotient ring, which is of course highly specific to that one encryption scheme, whereas our results apply to an FHE scheme with a finite field plaintexts space (i.e., all currently known schemes). [BBB+17] explores a non-integral base encoding, and [XCWF16] presents dif- ferent arithmetic algorithms including a costly division, though again limited to positive numbers.
To our knowledge, the only work concerned with the costs of encoding in a base other than p = 2 is [KT16], which exclusively analyzes [NK15] and uses different cost metrics than we do. The latter also presents a formula for the carry of a half adder, but merely considers GF (pk) for k = 1 in the context of homomorphically computing the decryption step (needed for bootstrapping) of their variation of [vDGHV10], and does not include an effort analysis. In [CLPX17], an encoding that allows high-precision computations on
rational numbers, but is highly specific to the underlying (new) variant of the [FV12] encryption scheme, is presented. Lastly, [CKKS16] allows approximate operations by utilizing noise from the encryption itself.