Optimization of Parameters for Encrypted Computation

Abstract

One embodiment is directed to a computer-implemented method for determining parameters of an encrypted computation for performing an encrypted computation on a noisy ciphertext. A computation graph is divided into a plurality of subgraphs defined by a type and instantiation parameters for that type. Each set of parameters of the encrypted computation is defined for each type. Optimization of the parameters of the encrypted computation is performed to minimize the computational cost of performing the encrypted computation according to the parameters of the encrypted computation. The parameters of the encrypted computation are constrained to satisfy noise constraints on the noise of the ciphertext while performing the encrypted computation. The noise constraints are based on respective noise constraints of respective subgraphs defined by a noise constraint function for the type that takes as input at least the parameters of the encrypted computation for the type and the instantiation parameters of the subgraph.

Description

Technical Field

[0001] The subject matter disclosed herein relates to a computer-implemented method, corresponding device, and computer-readable medium for determining parameters of encrypted computations.

Background Art

[0002] Homomorphic encryption methods enable encrypted computations: computations performed on data encrypted by a party, data that the party cannot decrypt, such as circuit evaluation. For example, input data and computation results may be received and returned in encrypted form. Intermediate data, such as the internal state of the computation, may also be in encrypted form.

[0003] Despite the fact that the computation results are returned in encrypted form, when decrypted, the output is expected to be the same as or very close to what would result if the operations were performed on unencrypted data. Homomorphic encryption can be used for outsourced storage and computation that protects privacy. This enables data to be encrypted and outsourced to a cloud environment for processing and / or storage while all encrypted.

[0004] For example, homomorphic encryption methods may make it difficult to regulate privacy to share plain data, but may be applied in fields such as healthcare where calculations on encrypted medical data may be permitted. For example, a medical model developed to classify medical data may be configured to receive medical data from a third party, such as a hospital, in encrypted form. The medical model may be able to classify medical data, for example, as normal or abnormal, or as having a particular medical syndrome, disease, or other disorder. Using homomorphic encryption, the medical model may be applied to medical data received in encrypted form. This means that the parties providing the medical model cannot access the plain medical data corresponding to the encrypted medical data. The user of the service can decrypt the results of the medical model application.

[0005] In particular, there are homomorphic encryption method technologies that can be used, at least in principle, to compute any function on encrypted data. Such technologies are called "fully homomorphic encryption" (FHE) technologies.

[0006] Known implementations of FHE use noisy ciphertexts for security reasons. For example, the encryption of a data item may involve mapping the data item to a point in a key-dependent lattice, to which noise is added. In particular, many known implementations of FHE use LWE-type ciphertexts where security depends on the cryptographic hardness of the Learning With Errors problem. Such LWE-type ciphertexts may include a value obtained by adding one or more mask values (e.g., values modulo a certain modulus q, or torus elements), and a body value that is derived from the mask values and the plaintext using an encryption key and includes noise. A generalization of this is the GLWE-type ciphertext that encrypts polynomials instead of scalar values. RLWE-type ciphertexts are another type of GLWE ciphertext.

[0007] When a data item has just been encrypted, the noise is low - the encryption is fresh. For example, since the amount of noise is very low, if the data item were to be decrypted, at some point in the decryption process, the noise could be removed, for example, by rounding. On the other hand, the noise should be large enough to make attacks on the system sufficiently difficult. For example, if it is assumed that there is no noise, many homomorphic encryption schemes can be attacked with linear algebra or other efficient algorithms, such as lattice reduction algorithms. The noise is added when the data item is encrypted and is selected such that homomorphic operations can still be performed and decryption is still possible while attacks are difficult.

[0008] Most homomorphic operations increase the noise inherent in homomorphically encrypted data items. When many such operations are performed, the noise may reach a level where unique decryption is no longer possible. In general, it is known to use a technique called bootstrapping to reduce the noise of homomorphically encrypted values. Bootstrapping may use a public key called a bootstrapping key. By using bootstrapping to reduce the noise when needed, it is in principle possible to compute any desired number of homomorphic operations.

[0009] A particular class of fully homomorphic encryption schemes is the TFHE-like homomorphic encryption schemes. Such schemes are described in I. Chillotti et al., "Programmable bootstrapping enables efficient homomorphic inference of deep neural networks", Cyber Security Cryptography and Machine Learning (CSCML 2021), Volume 12716 of Lecture Notes in Computer Science, pages 1-19, Springer, 2021 (incorporated herein by reference). TFHE-like schemes distinguish themselves from other FHE schemes by supporting a relatively very efficient technique for bootstrapping; furthermore, they enable the evaluation of functions simultaneously during the bootstrapping operation, called programmable bootstrapping. Regular bootstrapping corresponds to programmable bootstrapping by the identity function.

[0010] Interestingly, the output of programmable bootstrapping has an amount of noise that does not depend on the noise of the input ciphertext. Thus, by performing programmable bootstrapping, the noise of the input ciphertext can probably be reduced to a fixed amount, perhaps while applying a function to the input ciphertext at the same time. By performing programmable bootstrapping at the appropriate time, encrypted computations with unbounded multiplicative complexity can be performed.

[0011] Techniques for encrypted computation and in particular TFHE-like operations are affected by various parameters of the encrypted computation. These include various parameters of the encryption scheme itself, such as the number and modulus of mask values used for LWE, as well as parameters that affect a particular encrypted operation, such as the decomposition level used in the programmable bootstrap operation.

[0012] The parameters of the encrypted computation need to be carefully selected. In general, the parameters can affect the security of the encrypted computation (e.g., the more noise added during encryption or the more mask values there are, the harder it is to break the encryption scheme); the accuracy of the result of the computation (e.g., the size of the polynomial affects the number of bits of accuracy at which the computation can be performed); and the computational and storage requirements for performing the computation (e.g., the decomposition level of the programmable bootstrap and the LWE parameters affect the size of the bootstrap key and the computational complexity of performing this operation).

[0013] This means that the selection of parameters involves various trade - offs. For example, in order to reduce the minimum noise while maintaining security, some other parameters of the encryption method, such as the size of the polynomial and / or the dimension of GLWE, may be increased. At the same time, the cost of various encrypted - computation operators depends on the size of the polynomial and / or the dimension of GLWE, leading to a trade - off between noise and cost: it is desirable to use little noise to guarantee the correctness of the computation, but at the same time, using little noise requires increasing other parameters, thus increasing the computational cost.

Prior Art Documents

Non - Patent Documents

[0014]

Non - Patent Document 1

Non - Patent Document 2

Non - Patent Document 3

Non - Patent Document 4

Non - Patent Document 5

Non - Patent Document 6

Non - Patent Document 7

Non - Patent Document 8

Non - Patent Document 9

Non-Patent Document 10

Non-Patent Document 11

Non-Patent Document 12

Summary of the Invention

Problems to be Solved by the Invention

[0015] Therefore, it is desirable to provide an automated technique for determining appropriate values of parameters of encrypted computations for performing a given encrypted computation.

Means for Solving the Problems

[0016] According to one aspect of the present invention, a computer-implemented method for determining parameters of an encrypted computation is provided as defined by the claims. According to a further aspect, a device corresponding to the computer-implemented method is provided as defined by the claims. According to another aspect, a computer-readable medium is provided as defined by the claims.

[0017] Various embodiments relate to optimizing parameters of encrypted computations for performing encrypted computations on noisy ciphertexts. For example, such parameters may include global parameters used throughout the encrypted computation, such as the size of the polynomial used and / or the dimension of GLWE, which are parameters related to the encryption scheme in which the noisy ciphertext is encrypted.

[0018] Interestingly, the parameters may be optimized for a given computation at hand. The optimization of the cryptographic parameters may be based on the representation of the encrypted computation being performed. The computation being performed may be considered to correspond to a computation graph where nodes represent operations performed on encrypted data and edges represent the inputs and outputs of the operations. For example, the nodes may correspond to operations such as homomorphic linear operations, key switching, modulus switching, blind rotation, and / or sample extraction. In general, each edge may have an effect on the security, accuracy, and / or efficiency of the encrypted computation, for example, by incurring a particular computational cost or by providing an output of a particular degree of accuracy.

[0019] Interestingly, the inventors have noticed that the computation graph of an encrypted computation is often composed of particular patterns that may occur multiple times throughout the encrypted computation. For example, the pattern may be that an encrypted linear mapping is applied to one or more inputs; followed by key switching; followed by modulus switching; followed by blind rotation and sample extraction.

[0020] The inventors considered using the recurrence of this kind of pattern to efficiently optimize the parameters of encrypted computations. That is, the inventors considered performing optimization based on dividing a computational graph into a plurality of subgraphs according to the recurring pattern. Accordingly, a subgraph is defined by a type from one or more sets corresponding to the pattern that the subgraph follows, and zero or more instantiated parameters of that type. For example, continuing with the above example of a subgraph using a linear mapping, the subgraph may be parameterized by a set of coefficients representing the applied linear mapping (or, in many cases, the two-norm of the coefficients, which is sufficient information for performing optimization).

[0021] Thus, the optimization can be expressed by this representation of the computation by types and instantiated parameters. The optimization can take into account computational cost, security, and accuracy. In particular, the optimization can minimize the computational cost while ensuring that the computation is sufficiently secure and accurate. In this way, when given requirements regarding security and accuracy, the most computationally efficient solution can be obtained. The optimization can be configured to ensure that additional constraints are met, such as constraints regarding storage requirements related to the number of different bootstrapping keys or key-switching keys used in encrypted computations. However, in many cases, this is not required. For example, the storage requirements may be encoded by determining them as part of the definition of the optimization problem such that they do not need to be separately guaranteed to be met.

[0022] Interestingly, the security and accuracy requirements may be expressed by the subdivision of the computational graph into subgraphs with respective types and instantiation parameters. That is, the optimization may constrain the parameters of the encrypted computation so as to satisfy the noise constraints on the ciphertext computed during the execution of the encrypted computation. This noise constraint may be defined by a noise constraint function defined for each type of subgraph. The noise constraint function may take as input at least the parameters of the encrypted computation for a given type and the instantiation parameters of a particular subgraph. Thus, the overall noise constraint may include the respective constraints of each subgraph given by the noise constraint function.

[0023] Interestingly, defining the noise constraint by a noise constraint function for each type of subgraph enables the optimization to be performed efficiently. Representing the optimization problem by subgraphs instead of individual encrypted operations significantly reduces the size of the constraint satisfaction problem to be solved. Further, by using the noise constraint function, the optimization problem is represented by multiple instantiations of the same constraint function to be satisfied. This formulation facilitates the optimization, especially as it enables either explicitly or automatically by the optimizer used to remove constraints that are inferior to other constraints.

[0024] Noise constraints can explicitly constrain the noise of ciphertexts, for example, by specifying that the noise of each ciphertext is below its respective limit. However, they can also be implicitly constrained by the parameters of the encryption scheme used, in particular, as is known in itself, by the product of the dimension of GLWE and the size of the polynomial, which is inversely proportional to the noise at a given security level. By forcing the noise of each ciphertext to be greater than the minimum noise required to achieve a particular security level and less than the maximum noise required to achieve a particular degree of accuracy, both security and accuracy may be guaranteed.

[0025] In an embodiment, based on the instantiation parameters of the first and second subgraphs, it may be determined that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph. That is, for a given set of parameters of an encrypted computation, if the noise constraint of the first subgraph is satisfied, this may mean that the noise constraint of the second subgraph is also satisfied. Interestingly, this may be enabled by the representation of the computation by the type and instantiation parameters, as it may be determined whether the noise constraint of the first subgraph of that type is at least as strict as the noise constraint of the second subgraph of that type, based on the instantiation parameters, for a given type. In some cases, such a determination may also be made for different types of subgraphs, as shown in the examples given herein. In any case, determining that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph allows the noise constraint of the second subgraph to be removed from the optimization. This allows the size of the optimization problem to be significantly reduced and the optimization problem to be solved much more efficiently.

[0026] In an embodiment, the first and second subgraphs may be parameterized by a noise limit and the 2-norm of the applied linear mapping. The noise limit may correspond to the desired minimum precision of the encrypted value and thereby to the maximum amount of noise. Since the increase in noise due to applying the linear mapping may be represented by the 2-norm, the 2-norm can be used as a parameter.

[0027] For example, the subgraphs represented by these parameters may include: application of a linear mapping, key switching; modulus switching; and blind rotation and sample extraction. This is a common pattern in encrypted computations and, in fact, in some cases, the entire encrypted computation may actually be composed of an instantiation of this type of subgraph.

[0028] In such cases, it can be determined particularly efficiently that one subgraph has more stringent noise constraints than another. That is, this may apply when the noise limit of the first subgraph is at most the noise limit of the second subgraph (in combination with conditions regarding other parameters if any), and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph. This makes it possible to significantly reduce the number of constraints required. In particular, the noise limit may be represented by discrete parameters. These discrete parameters may have a relatively small number of possible values, for example, at most 10 or at most 20. In this case, for a given value of the noise limit, the subgraph with the largest 2-norm may be retained and the remaining subgraphs removed. Thus, the number of remaining subgraphs may be at most equal to the number of possible values of the noise limit, regardless of the size of the encrypted computation. Interestingly, it is possible to make the complexity of satisfying at least the noise constraints of this type of subgraph independent of the size of the computation, resulting in an efficient improvement particularly for large-scale encrypted computations.

[0029] In principle, the computational cost can be determined in various ways, for example, by simulating or measuring the actual execution time of encrypted computations.

[0030] However, in embodiments, the computational cost may be minimized based on a cost function. Similar to the noise constraint, the cost function may be based on the cost of each subgraph, and the cost of a given type of subgraph is defined by a cost function for that given type. This cost function may take as input at least the parameters of the encrypted computation for a given type. Using a cost function instead of simulation or measurement is not only because such a function can be evaluated much more efficiently than performing simulation or measurement, but also because it enables the use of optimization techniques that depend on having a functional expression to be optimized, such as branch-and-bound based on lower and upper bounds of the functional expression, optimization based on variable changes, or removal of non-optimal solutions based on the arguments of the functional expression, thereby significantly increasing the efficiency of optimization.

[0031] In particular, in embodiments, the cost function of a given type of subgraph may be independent of the instantiation parameters of that subgraph. In other words, it may be assumed that the computational cost of a given type of subgraph does not depend on the instantiation parameters. In many cases, this is a reasonable approximation. For example, the noise limit of a subgraph may not affect its performance because it does not change the way the computation is executed, while the applied linear mapping may have only a limited impact, for example, accounting for at most 10% or at most 1% of the computational cost of performing the encrypted computation corresponding to the subgraph. Interestingly, this approximation greatly simplifies the optimization problem because only a single instance of the cost function is required to represent the cost for each instantiation.

[0032] In an embodiment, a subgraph may represent a subcomputation that results in an output ciphertext with noise that does not depend on the input, i.e., noise in the input ciphertext of the subgraph as well as noise that does not depend on, for example, the number of linear operations applied to the input ciphertext in the subgraph. Thus, such an output ciphertext may be used as an input to a further subgraph. This makes it possible to define the noise constraint of the subgraph without depending on a particular amount of noise in the input, i.e., in other words, the input noise need not be an instantiation parameter, which simplifies the optimization problem. In particular, all inputs to a subgraph throughout the computation, or at least all inputs to a given type of subgraph, may be assumed to have the same amount of noise. As exemplified by using the 2-norm and noise bound as instantiation parameters, this may help in particular to remove noise constraints that are not stricter than other noise constraints.

[0033] In particular, the subgraph may be the final part that results in an output ciphertext with noise that does not depend on the input: typically having blind rotation and sample extraction, and optionally subsequent rounding, as will be considered in more detail elsewhere. Except for this final part, the subgraph usually does not include cryptographic operations that result in noise that does not depend on the input. In particular, the noise may increase monotonically within the subgraph until the final part is reached. This also simplifies the optimization problem, because it may be sufficient to determine the noise of the input to the final part, which is the maximum noise during the subcomputation, and constrain this noise, for example, to provide sufficient accuracy.

[0034] In an embodiment, the encrypted computation parameters may include one or more of: a decomposition base of programmable bootstrapping, a decomposition level of programmable bootstrapping, a decomposition base of key switching, and a decomposition level of key switching. These parameters may be defined as global encrypted computation parameters or may be defined for a particular given type. There is a trade-off with respect to these parameters in terms of the resulting noise and the efficiency with which the corresponding operations can be performed. For example, by increasing the level, the computational complexity increases but the noise decreases. Further, these operations form an important part of the overall computational amount of the encrypted computation. Therefore, optimizing these parameters has a particularly large impact on the resulting encrypted computation.

[0035] It is noted that different types of subgraphs may share the same base parameters and / or level parameters corresponding to their use of the same key-switching key and / or bootstrapping key. On the other hand, it is possible for different subgraphs, which have essentially the same structure from the perspective of cryptographic operations, to have different base parameters and / or level parameters corresponding to performing the same operations but with different bootstrapping keys and / or key-switching keys. Thus, by appropriately defining the type and parameters, an appropriate level of flexibility in optimization can be achieved.

[0036] In an embodiment, the subgraph may include programmable bootstrapping that yields an output ciphertext and noise rounding of the output ciphertext. In other words, the ciphertext may be rounded to encrypt the same value but with different noise. Interestingly, by performing noise rounding, it may be realized that programmable bootstrapping becomes deterministic in the sense that it does not depend on a particular implementation of the fast Fourier transform (FFT) used especially in programmable bootstrapping progs.

[0037] In fact, the inventors have observed that when no rounding is performed, at least some of the least significant bits of the ciphertext representing the noise of the ciphertext usually depend on the rounding error of the FFT implementation used. Such rounding errors may not affect the security or correctness of the encrypted calculation itself, but it may still be desirable for the calculation to be deterministic. For example, the fact that the calculation is deterministic allows the same encrypted calculation to be performed by different parties, perhaps using different software and / or hardware configurations, and check whether the resulting ciphertexts are the same, thus providing some assurance that the correct calculation has been performed.

[0038] In particular, in an embodiment, the encrypted calculation may be performed by a blockchain miner device, and rounding enables the results of the encrypted calculations determined by multiple miner devices to be compared with each other without the need for decryption. In this way, it may be possible to reach a consensus regarding the encrypted output of the calculation and, accordingly, prove that the intended encrypted calculation has actually been performed.

[0039] In an embodiment, the optimization of the encrypted computation parameters may be performed by a branch and bound method. By performing the branch and bound method, the optimization may be performed significantly more efficiently than by brute force, while at the same time ensuring that the best possible value of the encrypted computation parameters can be obtained.

[0040] In an embodiment, the optimization may be used to determine the key switching keys and / or the bootstrapping keys used for each subgraph. A predefined number of key switching keys and / or bootstrapping keys may be used. Each key may add a respective amount of noise and may have a respective computational cost. Adding less noise may be more computationally costly, resulting in a trade-off. For a given subgraph, the encrypted computation parameters may identify which of the predefined key switching keys and / or bootstrapping keys should be used in the subgraph. In this way, for each subgraph, a respective optimal choice may be made, enabling an overall better solution than if the same key switching keys and / or bootstrapping keys were used throughout the encrypted computation or if the key switching keys and / or bootstrapping keys for a given subgraph were predefined.

[0041] Interestingly, when optimizing which key-switching keys and / or bootstrapping keys should be used for each subgraph, it is possible to significantly reduce the parameter space of the parameters indicating the keys used. That is, if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the key-switching keys and / or bootstrapping keys for the first subgraph may be constrained to add at most the same amount of noise as the key-switching keys and / or bootstrapping keys for the second subgraph. As a result, ordering the subgraphs according to the noise constraints of the subgraphs means that the selection of the key-switching keys or bootstrapping keys may, in contrast to independent selections for each subgraph, essentially correspond to a linear search within this ordered list, making the optimization problem much more efficiently solvable.

[0042] In embodiments, the parameters of the encrypted computation may indicate, for each subgraph to which each linear mapping is applied, the respective number of programmable bootstrappings performed during the application of each linear mapping. By performing programmable bootstrapping during the application of the linear mapping, noise may be reduced at the expense of incurring a significant computational cost. By making the number of bootstrappings a parameter that can be optimized, an optimal selection can also be made with respect to this trade-off.

[0043] In embodiments, when it is to be the case that at least one programmable bootstrapping is performed with a linear mapping, it may be automatically determined how the linear mapping should be split into a plurality of linear mappings. As the inventors have noticed, this can be done by minimizing the maximum 2-norm of each linear mapping. This is advantageous because it minimizes the noise after each linear mapping and facilitates satisfying the noise constraint.

[0044] Interestingly, the inventors have noticed that the parameter space of the parameter indicating the number of programmable bootstrappings performed can be significantly reduced. That is, when the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph, the number of programmable bootstrappings for the first sub-graph may be constrained to be greater than or equal to the number of programmable bootstrappings for the second sub-graph. Thus, sorting the sub-graphs by the noise constraint, the search for the optimal number of programmable bootstrappings for each sub-graph may, in contrast to an independent selection for each sub-graph, essentially correspond to a linear search within this sorted list.

[0045] In an embodiment, the computational graph can be obtained by transforming an unencrypted computational graph. For this, techniques known per se can be used. This transformation can directly output a computational graph of encrypted computations that is already divided into sub-graphs. In an embodiment, the computational graph of encrypted computations can be compiled into a set of instructions for an encrypted computing engine. The instructions may be according to the determined parameters of the encrypted computations. Accordingly, a compiler may be provided that takes as input plain or encrypted computations and outputs instructions for an encrypted computing engine that optimally executes a given computation. In an embodiment, the encrypted computations may be performed according to the determined parameters of the encrypted computations, enabling the encrypted computations to be performed in a way that combines efficiency, accuracy, and security.

[0046] Generally, encrypted computations may be performed in the TFHE setting. This means that the ciphertexts used to encrypt values enable programmable bootstrapping operations. In particular, the ciphertexts may be LWE (Learning With Errors) encryption, i.e., encryption based on the cryptographic assumption that the Learning With Errors problem is hard. As is known per se, programmable bootstrapping may, for example, evaluate LWE decryption at the exponent of a GLWE-encrypted monomial implemented as a so-called blind rotation. In particular, programmable bootstrapping may include calculating the encrypted polynomial product of a bootstrapping monomial that represents a plaintext value as an exponent and a test polynomial. The test polynomial may represent a function and / or lookup table evaluation applied to the input by programmable bootstrapping. Programmable bootstrapping may use a bootstrapping key that enables programmable bootstrapping but does not enable decryption of the ciphertexts.

[0047] The provided techniques for improved computation on encrypted data can be applied to a wide range of practical applications. Such practical applications include the encrypted evaluation of software programs without access to the plain data. For example, it may be possible to evaluate medical diagnostic software against medical data without actually being able to access the medical data. The medical data may include medical images. The medical images may be acquired by various acquisition modalities such as, but not limited to, standard X-ray imaging, computed tomography (CT), magnetic resonance imaging (MRI), ultrasound (US), positron emission tomography (PET), single photon emission computed tomography (SPECT), and nuclear medicine (NM), and may include, for example, multi-dimensional image data, e.g., two-dimensional (2D), three-dimensional (3D), or four-dimensional (4D) images.

[0048] In an embodiment, the technology provided can be used to evaluate a neural network against an encrypted input. A person evaluating the neural network may or may not have plaintext access to the trained parameters of the neural network, such as weights and biases. Generally, the technology provided herein, such as improved parameters for encrypted computing, improves the efficiency of neural network evaluation and / or reduces the storage and transmission requirements of the ciphertext or key material used.

[0049] Embodiments of the method may be implemented on a computer as a computer-implemented method, or in dedicated hardware, or in a combination of both. Executable code for embodiments of the method may be stored in a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, and the like. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for performing embodiments of the method when the program product is executed on a computer.

[0050] In an embodiment, a computer program includes computer program code configured to perform all or part of the steps of an embodiment of the method when the computer program is executed on a computer. Preferably, the computer program is embodied on a computer-readable medium.

[0051] Further details, aspects, and embodiments are described by way of example only with reference to the drawings. Elements in the figures are shown for simplicity and clarity and are not necessarily drawn to scale. In the figures, elements corresponding to elements already described may have the same reference numerals.

Brief Description of the Drawings

[0052]

Figure 1a

Figure 1b

Figure 1c

Figure 2

Figure 3

Figure 4a

Figure 4b

Figure 4c

Figure 5

Figure 6a

Figure 6b

Figure 7a

Figure 7b

Figure 8

Figure 9a

Figure 9b

Figure 10

Figure 11

Best Mode for Carrying Out the Invention

[0053] The subject matter disclosed herein admits of many different forms of embodiments, but it should be regarded as an example of the principles of the subject matter disclosed herein, and on the understanding that the subject matter disclosed herein is not intended to be limited to the specific embodiments shown and described herein, one or more specific embodiments are shown in the drawings and described in detail herein.

[0054] In the following, for the sake of understanding, the elements of the embodiments in operation will be described. However, it will be apparent that each element is configured to perform the functions described as being performed by those elements.

[0055] Furthermore, the subject matter disclosed herein is not limited to embodiments only, but also includes any other combination of features described herein or in different dependent claims.

[0056] The various embodiments relate to encrypted computations on noisy ciphertexts. When creating the encryption of the noise of an unencrypted value, in other words, when determining a freshly encrypted ciphertext, the noise used may be drawn from a distribution denoted χ(σ) that is parameterized by a parameter σ. By way of example, the distribution χ may be a centred Normal distribution, and the parameter σ may be a standard deviation.

[0057] When performing encrypted operations on ciphertexts, the noise contained in those ciphertexts is typically corrected as a side effect. The connection between the input noise and the output noise of the operation may be represented by a noise formula. The noise formula may model the evolution of the noise as a result of this operation. In particular, during an operation on a ciphertext, the distribution of the noise within the ciphertext typically changes. In particular, when the noise within a ciphertext is drawn from a normal distribution with a larger standard deviation σ, the ciphertext may be said to contain more noise than another ciphertext.

[0058] In particular, various embodiments use LWE (Learning With Errors) encryption. Generally, an LWE type of ciphertext may include one or more mask values and a body value that is derived from the mask value, the plaintext value, and the secret key and includes noise. The values are typically integers modulo a given modulus q. Various embodiments also use GLWE (Generalized Learning With Error) type of ciphertexts. A GLWE type of ciphertext may include one or more mask polynomials and a body polynomial that is derived from the mask polynomial, the plaintext polynomial, and the secret key and includes polynomial noise. A GLWE type of ciphertext may be defined modulo a modulus q and a quotient polynomial p(X). An LWE ciphertext may be regarded as a particular kind of GLWE ciphertext where the quotient polynomial has degree 1. Another particular kind of ciphertext is the RLWE (Ring Learning With Errors) ciphertext where the number of mask polynomials is one.

[0059] In particular, the secret key

Number

Number

Number

Number

Number

Number

Number

Number

[0060] In general, the security of GLWE-type encryption depends on the distribution of the secret key (e.g., binary, ternary, or Gaussian), the product k·N of the dimension k of GLWE and the size N of the polynomial; the amount of noise in a fresh ciphertext; and the modulus q. Given these parameters, how to estimate the degree of security provided is known per se, see, for example, M. Albrecht et al., "On the concrete hardness of Learning with Errors", Journal of Mathematical Cryptology, 9(3):169-203, 2015 (incorporated herein by reference), and the estimator software available at https: / / github.com / malb / lattice-estimator. In general, the larger the product k·N, the smaller the minimum noise required for security.

[0061] Since there is a connection between the dimension k of GLWE, the size N of the polynomial, and the standard deviation σ of the Gaussian noise (e.g., the minimum noise for a given number of bits of security), it may be noted that one of these variables can be calculated from the others. In particular, throughout this specification, given a particular distribution of the secret key (e.g., binary, ternary, or Gaussian); the product k·N; and the security level λ, the minimum noise of a fresh ciphertext to achieve the security level may be calculated, i.e.,

Equation

[0062] The integer q is used throughout this specification to represent the modulus of the ciphertext, but it is noted that the modulus of multiple ciphertexts may be used in encrypted multiplication, for example, such that modulus switching is used to align the ciphertexts under the same q when required.

[0063] The above example describes a symmetric variant of the GLWE secret key. The techniques provided herein are equally applicable to the public-key variants which are known per se. In the latter case, for example, the above secret key may be used as a private key, and the public key may include one or more encryptions of zero. See, for example, R. Rothblum, "Homomorphic encryption: From private-key to public-key", Theory of Cryptography (TCC 2011), Lecture Notes in Computer Science volume 6597, pages 219 - 234, Springer, 2011 (incorporated herein by reference).

[0064] Various embodiments operate in the TFHE setting, i.e., ciphertexts that support programmable bootstrapping (PBS) are used. Programmable bootstrapping can take a ciphertext as input and output a ciphertext of the same message with input-independent noise or a function and / or lookup table of that message. PBS may include evaluating the homomorphic decryption of the input ciphertext at the exponent of a polynomial. Examples of encryption schemes in the TFHE setting that may be combined with the techniques provided herein are given in the following references: - [DM15] L. Ducas et al., "FHEW: bootstrapping homomorphic encryption in less than a second", proceedings EUROCRYPT 2015, - [CGGI16] I. Chillotti et al., "Faster fully homomorphic encryption: Bootstrapping in less than 0.1 seconds", proceedings ASIACRYPT 2016, - [CGGI17] I. Chillotti et al., "Faster packed homomorphic operations and efficient circuit bootstrapping for TFHE", proceedings ASIACRYPT 2017.

[0065] Throughout this specification, the plaintext may be represented as integers modulo a modulus q. Such values modulo integers may be equivalently regarded as elements of a discretized torus, as done in some of the aforementioned references. In particular, various documents represent the message space and the ciphertext space using the real torus

Number

Number

Number

Number

Number

[0066] The programmable bootstrapping operations of TFHE-like schemes make them an attractive option for a wide range of applications. Bootstrapping is relatively efficient compared to many other FHE schemes and can, for example, much more feasibly perform relatively complex calculations with at least 10, at least 50, or at least 100 multiplicative depths. In particular, the cryptographic parameters of TFHE-like schemes can be selected based on the desired accuracy and the resulting computational cost, and it is not necessarily the case that the amount of homomorphic operations and the circuit depth have to be large. In contrast, in other FHE schemes, bootstrapping is very inefficient, and in practice, these schemes are usually applied in a levelled way, i.e., their parameters are selected according to a given calculation so that the given calculation can be performed without the need for bootstrapping. However, such levelled techniques are infeasible for more complex calculations, and thus, in such cases, TFHE-like schemes are particularly beneficial.

[0067] In the embodiments of this specification, the parameters of TFHE-like LWE and GLWE-based ciphertexts used may be selected based on the desired level of security and on the desired precision of operations such as linear combinations of LWE ciphertexts and / or the application of programmable bootstrapping, in other words, based on the noise level resulting from applying these operations. Interestingly, in the TFHE setting, the security parameter may be selected independently of the size of the computation, e.g., independently of the multiplication depth of the computation. This is different from non-TFHE-like schemes where the security parameter is typically selected to limit or remove bootstrapping.

[0068] In particular, the LWE-based ciphertexts and / or GLWE-based ciphertexts used in the TFHE setting of this specification may use a relatively small modulus, e.g., up to 32 bits, up to 64 bits, or up to 128 bits. This modulus is typically selected independently of the computations being performed, e.g., according to the desired accuracy and / or efficiency. The parameters N, k, and / or σ may be pre-defined or may be the output of the optimizations described herein. For example, N may be set to at least 512 and / or at most 2048, 4096, or 16384, e.g., 1024. For example, in an embodiment, RLWE is used such that N is at least 512 and / or at most 2048 or 4096, e.g., 1024 and k = 1. Such values of N are not typically used in non-TFHE-like encryption schemes that significantly limit the computations that can be performed; instead, in non-TFHE-like schemes, q and N are typically both selected based on the desired level of security such that q may be much larger.

[0069] Throughout this specification, the term "standard score" may be used as follows.

Number

[0070] The standard score may be applied to the confidence interval of the central normal distribution as follows. [Number] and [Number] and p err ∈ [0,1]. Let z'(p err ) be the standard score of p err . Then: [Number] is.

[0071] FIG. 1a schematically shows an example of an embodiment of the configuration device 110. The device 110 may be for determining the parameters of the encrypted calculation for performing the encrypted calculation on the noisy ciphertext.

[0072] Device 110 may include a processor system 130, a storage 140, and a communication interface 150. The storage 140 may include local storage, such as a local hard drive or electronic memory. The storage 140 may include non-local storage, such as cloud storage. In the latter case, the storage 140 may include a storage interface to the non-local storage. For example, the storage 140 may be for storing data representing a computational graph of encrypted computations. In this representation, the computational graph may be divided into a plurality of subgraphs. A subgraph may be defined by a type from one or more types of sets and zero or more instantiation parameters of that type.

[0073] Device 110 may communicate internally, via a computer network, with other devices, external storage, input devices, output devices, and / or one or more sensors. The computer network may be the Internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. The device may optionally include a connection interface 150 configured to communicate with other devices as needed. For example, the connection interface may include a connector, such as a wired connector, such as an Ethernet connector, an optical connector, etc., or a wireless connector, such as an antenna, such as a Wi-Fi, 4G, or 5G antenna. Communication, such as internal communication, may use other communication protocols or media, such as an internal data bus.

[0074] In device 110, communication interface 150 may be used to transmit or receive digital data. For example, device 110 may be configured to receive or transmit data representing calculations performed in encrypted form. For example, device 110 may obtain data representing a computational graph of unencrypted or encrypted calculations, the latter of which, when received, may optionally be split into subgraphs as already described herein. Device 110 may determine encrypted calculation parameters for optimally performing this calculation in encrypted form. Device 110 may transmit data representing the encrypted calculation parameters, in particular instructions for an encrypted calculation engine for performing the calculation in encrypted form according to the determined encrypted calculation parameters.

[0075] The execution of device 110 may be implemented by a processor system 130, for example, one or more processor circuits, such as a microprocessor, examples of which are shown herein. Device 110 may include multiple processors, which may be distributed in different locations. For example, device 110 may use cloud computing.

[0076] The processor subsystem 130 may be configured to define respective sets of encrypted calculation parameters for each type. The processor subsystem 130 may be further configured to perform optimization of the encrypted calculation parameters, including respective sets of encrypted calculation parameters for each type. In this optimization, the encrypted calculation parameters may be optimized to minimize the calculation cost of performing the encrypted calculation according to the encrypted calculation parameters. Further, in this optimization, the encrypted calculation parameters may be constrained to satisfy the noise constraint with respect to the noise of the ciphertext while performing the encrypted calculation. The noise constraint may be based on the respective noise constraints of each subgraph. The noise constraint of a given type of subgraph may be defined by a noise constraint function for a given type that takes as input at least the encrypted calculation parameters for a given type and the instantiation parameters of the subgraph.

[0077] Some of the figures show functional units that may be functional units of the processor system. For example, the figures may be used as a blueprint for the organization of the possible functions of the processor system. The processor circuitry is not shown separately from the units in most of the figures. For example, the functional units shown in FIGS. 2-6 (see below) may be implemented in whole or in part by computer instructions stored in a device such as device 110, for example, in the electronic memory of device 110 and executable by the microprocessor of device 110. In a hybrid embodiment, the functional units are implemented partly in hardware, for example, as a coprocessor, for example, an arithmetic coprocessor and / or a cryptographic coprocessor, and partly in software stored in and executed by device 110.

[0078] Figure 1b schematically shows an example of an embodiment of the encrypted computing device 119. The encrypted computing device 119 may be for performing encrypted computations. The encrypted computations may use a homomorphic encryption cipher. For example, the device 119 may be used to perform encrypted computations. For example, the device may perform computations even if the data is in encrypted form, for example, received from a data provider, and even if the device 119 cannot decrypt the data. The computations are performed according to the parameters of the encrypted computations determined as described herein, for example, by the device 110 of Figure 1a. The device 119 may determine the parameters themselves. For example, the device 119 may be combined with the device 110 of Figure 1a.

[0079] The device 119 may include a processor system 139, a storage 149, and a communication interface 159. The processor system 139, the storage 149, and the communication interface 159 may be implemented as considered for the respective components of Figure 1a. The storage 149 may be for storing the representation of the encrypted computations to be performed and / or the parameters of the encrypted computations according to which the encrypted computations are to be executed. Thus, the device 119 may include a storage 149 for storing the parameters of the encrypted computations. The parameters of the encrypted computations may be included in the representation of the encrypted computations.

[0080] For example, storage 149 may store encrypted data items received from, for example, one or more data providers, or intermediate or final results of calculations, such as those generated as output. Typically, most or all data items on which the calculations of device 119 are performed are encrypted with a key (or keys) unknown to device 119. That is, device 119 may not be configured to obtain the plain data item corresponding to the encrypted data item as stored, for example, in storage 149. The decryption key in plain form is secret to device 119, but the encryption / decryption key may be available in encrypted form.

[0081] Communication interface 159 may be used to receive the encrypted representation of the calculations performed and / or the encrypted calculation parameters according to which the calculations are to be executed. Communication interface 159 may be further configured to receive encrypted data for performing the calculations. Communication interface 159 may be further used to transmit the encrypted output obtained as a result of the encrypted calculations.

[0082] Processor subsystem 139 may be configured to execute encrypted calculations. This may be done as is known in the art itself. Interestingly, processor subsystem 139 uses the parameters of the encrypted calculations as described herein, so that, as considered throughout this specification, improved encrypted calculations may be performed, for example, with improved computational efficiency.

[0083] Instead of or in addition to using the parameters of the encrypted calculations as described herein, processor subsystem 139 may apply, for example, a noise rounding operation to the ciphertext having implementation-dependent noise, such as the output of programmable bootstrapping, as considered in connection with FIG. 8.

[0084] FIG. 1c schematically shows an example of an embodiment of an encryption computing system 100. The system 100 is configured to perform encrypted computations using homomorphic encryption, such as fully homomorphic encryption.

[0085] The system 100 of this example includes a compiler device 111, a data provider device 113, and an encrypted computing device 112. The compiler device 111 may be combined within a single device with the encrypted computing device 112 or the data provider device 113. The device 112 may be configured to receive encrypted data items from the data provider 113. At least one or more data items may be received in encrypted form. One or more additional data items may be received in plain format. The device 112 may be configured to receive from the compiler device 111 a homomorphic executable for performing encrypted computations.

[0086] The device 112 may perform the computations described herein on the received data items and possibly also on stored data items. Interestingly, the computations may be performed by the device on the encrypted data without decrypting the data, for example, without converting the encrypted data items to data in plain format.

[0087] Interestingly, device 112 may perform encrypted calculations according to the encrypted calculation parameters determined as described herein. For example, the encrypted calculation parameters may be determined by compiler device 111. For example, a homomorphically executable file may conform to the encrypted calculation parameters. In such a case, compiler device 111 may be based on device 110 of FIG. 1a and may include, for example, processor system 130, storage 140, and / or communication interface 150 of FIG. 1a. Although it is also possible in principle for the determination of the encrypted calculation parameters to be performed by device 112 or device 113 or a different device, in that case, this device may be based on device 110 of FIG. 1a. Device 112 may be based on device 119 of FIG. 1b and may include, for example, processor system 139, storage 149, and / or communication interface 159 of FIG. 1b.

[0088] Optionally, compiler device 111 or data provider device 113 may be further configured to generate key material for encrypted computing device 112 to perform encrypted calculations, including, for example, a bootstrapping key for performing programmable bootstrapping as considered herein. The device generating the key material may provide the bootstrapping key 151 to device 112, for example, by transmitting the bootstrapping key 151 via computer network 150, uploading the bootstrapping key 151 to shared storage, etc. It is also possible for the key material to be generated by another key generation device (not shown in this figure).

[0089] Although not shown in this figure, the encryption computing system 100 may include a plurality of encryption computing devices, for example, two, three, or more than three encryption computing devices. Encrypted computations may be distributed across the plurality of encryption computing devices. The encryption computing devices may typically exchange encrypted intermediate computation results with each other. Each encryption computing device may be implemented like the encryption computing device 112 and may perform encrypted operations as described herein.

[0090] The homomorphic encryption scheme can be applied in many settings. For example, the encryption computing device 112 may be operated by a cloud provider. The cloud provider may provide computing services and storage services to clients. By adopting homomorphic encryption, a data provider device 113, for example, a client of the cloud provider, can send its client's data in an encrypted form. The cloud provider can still perform the required computations and / or the required storage, but cannot know the corresponding plain data. For example, the data provider device 113 may use an encryption key of a type corresponding to a particular homomorphic encryption system used to encrypt data items. When a computation result is received from the encryption computing device 112 by the data provider 113, a corresponding decryption key may be used to decrypt the encrypted data item. The encryption key and the decryption key may be the same - typically they are.

[0091] For example, the encryption computing system 100 may be configured to train a machine learning model, such as an image classifier, such as a medical model, even if the encrypted computing device cannot access the plain data item. For example, linear regression may be performed on the input data, perhaps even without bootstrapping. For example, backpropagation may be performed on the input data, perhaps with bootstrapping. The resulting model parameters may be returned to the entity owning the decryption key. This enables multiple providers of medical data to pool their data by sending the data to a cloud provider. The cloud provider then returns the model parameters without being able to access the plain data. The encryption key may be equal to the decryption key.

[0092] After the model is trained, the encryption computing system 100 may be used, for example, to provide the model for use with medical data. This can be done with plain model parameters or encrypted model parameters - in both cases using encrypted data, such as encrypted input data, intermediate data, and output data. Using plain model parameters is usually far more efficient. In both cases, the effect of the system is that computations, such as image classification, such as medical image classification, are performed without the computer knowing the plain data item. For example, a mammogram may be evaluated for cancer without the image even being present in plain on the encrypted computing device 112 and without the encrypted computing device 112, or the cooperation of such a device, knowing what the result of the cancer evaluation is. From a privacy perspective, it may be acceptable to operate a plain model with encrypted privacy-related data, but it may not be acceptable to operate with plain privacy-related data.

[0093] Other uses include, for example, database services that search for encrypted data within an encrypted database; for example, the computation may be a comparison between an input item and a database item. For example, multiple computations may be combined to create a database index that matches an index. For example, the database may be a genomic database and the input may be a gene sequence. For example, system 100 may be used for protected control of a device. For example, a device, even a large-scale device such as a power plant, may send sensor values to an encrypted computing device 112 and receive an encrypted control signal as a response. The control signal is computed from the sensor signal. An attacker of the system may be able to go to one or more encrypted computing devices 112 and determine the content of the data coming from and going to one or more encrypted computing devices 112, or even access the intermediate data of these devices, but since the data is encrypted, the attacker is not helped thereby. Even by completely breaking all of the encrypted computing devices 112 of system 100, the data will not be revealed because the decryption keys are not known to these devices. Computing the control signal may include mathematical operations such as linear algebra, averaging, matrix multiplication, polynomial evaluation, all of which are executable by homomorphic encryption operations.

[0094] For example, a pool of encrypted data items may be maintained in an encryption computing system; subsets of these may be received, and other subsets may be, for example, intermediate results of encrypted computations. For example, the encryption computing device 112 may be configured to apply a homomorphic encryption operation to one, two, or more encrypted data items in a pool, such as a collection of input values and / or intermediate values and / or output values. The result may be a new encrypted data item that can be stored in the pool. The pool may be stored in the storage of the encryption computing system. This may be local storage or distributed storage. In the latter case, it may happen that one or more encrypted data items are represented multiple times within the pool. Encrypted data items may be transmitted from one computing device to another, for example, if their values are needed elsewhere. The pool may be implemented in various ways, such as as a register file, an array, various data structures, and the like.

[0095] Encrypted data items can represent all kinds of data. For example, an encrypted data item may represent a number that needs to be averaged or used in linear regression. For example, an encrypted data item may represent an image. For example, each pixel of an image may correspond to one or more encrypted data items. For example, a grayscale pixel may be represented by a gray level, and further, that gray level may be represented by a single encrypted data item. For example, 256 gray levels may be encoded in a single encrypted data item. For example, a color pixel may be represented as a plurality of color levels, such as RGB levels, and further, those color levels may be represented by a tuple of encrypted data items. For example, three 256-level colors may be encrypted as their respective encrypted values.

[0096] A set of homomorphic encryption operations may be defined for computation. For example, from the homomorphic encryption operations, an encrypted computation computational graph, also known as a network or circuit of operations that perform computations together, for example, by a compiler device 111 or by the computing device 112 itself, may be constructed. For example, the operations may include Boolean operations. The way the homomorphic encryption operations are combined, for example, which operation is applied to which operand within a pool, determines the computation being performed. For example, the computation may be represented as a list of homomorphic encryption operations to be performed, along with an indication of which encrypted data item the operation should be performed on, thereby implicitly defining the computational graph by their input / output relationships.

[0097] FIG. 2 shows a detailed but non-limiting example of how to determine the parameters of encrypted computation for performing encrypted computation on a noisy ciphertext.

[0098] As shown in the figure, the encrypted computation may be considered to correspond to an encrypted computation graph ECG 230 (also referred to as an “FHE DAG”). The encrypted computation graph ECG may be represented explicitly in memory or implicitly, for example, as a list of instructions, such as in executable code. The encrypted computation graph ECG may be a directed acyclic graph of encrypted operations, also referred to as an “FHE operator”. The encrypted operations may take one or more ciphertexts and / or plaintexts as inputs and provide one or more ciphertexts as outputs.

[0099] Hereinafter, G is used to represent an FHE graph ECG composed of FHE operators. Mathematically, G = (V, E) may represent a directed acyclic graph (DAG) of FHE operators {O i} i∈I where V = {O i} i∈Iis a set of vertices that are FHE operators; E is a set of edges of G. For simplicity of explanation, if the set of edges E is not required, the graph may be identified with its set of vertices, and G = V.

[0100] For example, FHE operators may represent homomorphic addition (of ciphertexts and / or plaintexts), homomorphic multiplication with a plain value, key switching, modulus switching, blind rotation, sample extraction, etc. In various examples, for simplicity, blind rotation and sample extraction are represented together as one FHE operator since they typically occur together in encrypted computations.

[0101] Optionally, the encrypted computation graph ECG may be obtained by taking as input the non-encrypted computation graph PROG 210 and performing a compilation COMP 220 that converts the graph into the encrypted computation graph ECG. The compilation COMP may act on the graph PROG of plain operators. By using the techniques provided, this graph PROG may be converted into the corresponding graph ECG of FHE operators with a correct optimized set of parameters ECP 280.

[0102] In the graph PROG, a plain operator may be an operator that performs operations on data marked as confidential and / or data marked as plain data and outputs confidential data. Data marked as confidential may be encrypted in the resulting encrypted computation. For example, some or all plain operators may be selected from: Addition of confidential data to each other; Addition of confidential data and plain data; Multiplication of confidential data with each other; Multiplication of confidential data and plain data; and Application of a unary function.

[0103] Compilation COMP can map a plain operator to each set of one or more FHE operators. Both the plain operator and the set of FHE operators may compute the same operation, where the former performs operations on plain data and confidential data, and the latter performs operations on plaintext and ciphertext. For this, techniques known in the art itself may be used. Interestingly, for the resulting graph ECG, the techniques described herein can be used to find the best encrypted computation parameters.

[0104] In the splitting operation DIV, the computation graph G, ECG can be split into a plurality of subgraphs {G i}. The subgraph may be defined by a type from one or more types of sets and zero or more instantiation parameters of that type. Subgraphs of a particular type may have in common that the same FHE operators are applied in the same order. For this purpose, as illustrated in FIG. 4a and elsewhere, several additions and scalar multiplications together may be regarded as a single FHE operator representing a linear mapping. In this case where the subgraph includes a linear mapping, the applied linear mapping (or its 2-norm sufficient to perform various optimizations) may be, for example, one of the instantiation parameters. The type of subgraph is also called an atomic pattern (AP) species.

[0105] Examples of subgraph types are considered in connection with, for example, FIGS. 4a, 6a, and 6b. Subgraphs of a particular type may have in common that the same key material is used for a particular FHE operator such as key switching or blind rotation; however, it is also possible to use the key material as a parameter, as considered in connection with, for example, FIG. 7a.

[0106] In particular, a subgraph may represent a sub-computation that results in an output ciphertext with noise independent of the input. For example, the output ciphertext may be that of programmable bootstrapping or the rounding of the output of programmable bootstrapping. Thus, the splitting operation DIV may operate on the encrypted computation graph ECG by splitting the graph into subgraphs at the output of each set of operations that result in noise independent of the input, for example, in each instance where blind rotation + sample extraction, or blind rotation + sample extraction + rounding is applied.

[0107] By way of example, the figure shows an encrypted computation graph ECG including three subgraphs S1 131; S2 232;, and S3 233. In this example, subgraphs S1 and S3 have a common first type T1 258, and subgraph S2 has a second type T2. Thus, the splitting DIV results in a representation REP 250 of the encrypted computation graph by instantiation parameters IP-S1 251; IP-S3 253; for instantiating the first type T1 to obtain each of the subgraphs S1, S3 and an instantiation parameter IP-S2 252 for instantiating the second type T2 to obtain the subgraph S2.

[0108] The number of subgraphs can be relatively large, for example, at least 100, at least 1000, or at least 10000. The number of different types of subgraphs occurring in a given encrypted computation graph is typically limited, for example, to one, at most or at least two, or at most or at least three. The graph may be partitioned into subgraphs, for example, where each node of the graph occurs in exactly one subgraph. The number of instantiation parameters for a type of subgraph can be, for example, zero, one, two, at most or at least three, or at most or at least five. Different types of subgraphs can have different numbers of instantiation parameters. Examples are given throughout this specification.

[0109] Generally, the way the FHE operation of the encrypted computation graph ECG is performed may depend on the values of the set of encrypted computation parameters ECP 280.

[0110] The encrypted computation parameters ECP may include a set of global encrypted computation parameters ECPG 285. These parameters may include, for example, parameters of the encryption method used, such as the dimension k of GLWE and / or the polynomial size N and / or their product k·N. The number of global parameters can be, for example, at most or at least 2, or at most or at least 5.

[0111] The encrypted computation parameters ECP may further include the respective encrypted computation parameters ECP1 288, ECP2 289 for each type T1, T2. For example, these parameters may include the programmable bootstrapping and / or key-switching decomposition base B and / or decomposition level l occurring in the subgraph of that type. In particular, for different types of subgraphs, the values of these parameters may be different, but it is also possible to share these parameters between different types. However, the encrypted computation parameters ECPi are shared between different subgraphs having the same type, thereby simplifying the optimization of the encrypted computation parameters as compared to defining these parameters separately for separate FHE operations or subgraphs.

[0112] The encrypted computation parameter ECP may further optionally include parameters ECP-S1 281, ECP-S2 282, ECP-S3 283 that are specific to each subgraph of the respective subgraphs S1, S2, S3. Such parameters can identify, for example, a set of bootstrapping keys or key-switching keys used in the subgraph (as shown in relation to FIG. 7a), and / or can indicate the number of programmable bootstrappings performed as part of a linear mapping (as shown in relation to FIG. 7b).

[0113] The parameter ECP-Si specific to a subgraph usually does not provide values of cryptographic parameters such as bases or levels: these are usually defined as type-specific encrypted computation parameters EPCi, or rather as global encrypted computation parameters ECPG. This improves the efficiency of optimization and further limits the number of different values that such parameters can have, thereby, for example, limiting the number of different key-switching keys and bootstrapping keys required to perform encrypted computations.

[0114] To determine the value of the encrypted computation parameter ECP, an optimization OPT 223 may be performed. The optimization may be configured to find the value of the encrypted computation parameter ECP that minimizes the computational cost Cost(G,x) of executing the encrypted computation G according to the encrypted computation parameter x, while ensuring (to a given probability) the desired level of security and the correctness of the computation result.

[0115] The optimization OPT may ensure security and correctness by constraining the encrypted computation parameters to satisfy noise constraints on the noise of the ciphertext generated while performing the encrypted computation. An example of defining such a noise limit is considered in relation to FIG. 3.

[0116] In particular, the noise limit can guarantee a desired level of security by setting the noise of the ciphertext of fresh encryption based on the security parameters of the encryption method so that a desired level of security is provided. In particular, as will also be considered elsewhere, for example, given the security level λ and the encryption parameter k·N included in the global parameter EPG, the noise of the fresh ciphertext is a mapping defined such that the fresh ciphertext contains enough noise to hide the plaintext. [Number] can be given by. In other words, by considering the noise of encryption not as a variable but as the output of a mapping given the security level, it can be guaranteed that the security is at least the required value.

[0117] Regarding the correctness of the calculation result, it is noted that when the noise of the ciphertext becomes larger than the threshold, decryption no longer returns the correct plaintext with sufficient probability. This threshold regarding the amount of noise of the ciphertext may be called the noise limit. The noise limit can be global or can vary between parts of the calculation according to the accuracy desired at that point during the calculation, in which case it can be defined, for example, based on the instantiation parameter IP-Si of the subgraph. The noise limit can be specified manually or can be calculated, for example, based on the desired accuracy (e.g., the number of bits required to represent the encrypted value) and the maximum desired error probability of decryption.

[0118] In general, the optimization problem for which the optimization OPT seeks a solution can be defined as follows. For a given encrypted calculation parameter x, a corresponding set of possible values is defined and denoted as E x and may be called the search space of x. The search space is usually discrete. The Cartesian product of the search spaces is E GIt may be expressed as, and may be called the search space of the encrypted calculation graph G. In this specification, for the sake of simplicity, the graph G may be omitted such that the search space of the encrypted calculation graph is expressed as E.

[0119] Generally, some solutions within the search space generate too much noise. A noise feasible set is defined as a set of encrypted calculation parameters ECP that satisfy the noise constraint. For example,

Number

Number

[0120] In addition to the noise constraint, there may be further constraints configured to be taken into account by the optimization OPT, such as restrictions on the size of the public key and / or ciphertext. The constraints can, for example, relate one or more encrypted calculation parameters to each other. Generally, such further constraints may define a further feasible set S other (G).

[0121] Therefore, the optimization problem can be stated as

Number

[0122] Interestingly, by splitting the computational graph into subgraphs of each type, the optimization problem may be simplified. In particular, this splitting may make it less computationally costly to test whether the solution is within the feasible set [Mathematics] and may be less computationally costly to test whether the solution is within the feasible set.

[0123] In particular, the noise constraint may be defined based on the noise constraint of each subgraph Si. Here, the noise constraint of a subgraph Si of a given type Tj may be defined by the noise constraint functions NCF1 268; NCF2 269 for that given type T1, T2. The noise constraint function NCFj may take as input at least the encrypted computation parameter ECPj for a given type Tj and the instantiation parameter IP-Si of the subgraph Si.

[0124] More precisely, the noise constraint may be [Mathematics] defined as follows. Here, the noise constraint i of subgraph A [Mathematics] may be defined by the noise constraint function for the type of subgraph A i .

[0125] Generally, the noise constraints of a certain type of subgraph may be obtained by propagating the noise estimate of the input of the subgraph through the operations of the subgraph. Generally, when a graph ECG is divided into subgraphs with outputs that are independent of the input, such as PBS outputs or rounded PBS outputs, the input of the subgraph may be assumed to have fixed noise derived, for example, from the global encrypted computation parameters ECPG, and the noise is assumed to increase throughout the subgraph so that the noise constraints can, for example, constrain the noise of the input of PBS (or other noise-fixing operations) to be small enough to guarantee sufficient accuracy. A detailed example is given in relation to Figure 4b.

[0126] Interestingly, the noise constraints of each subgraph of the same type are thus defined by the same function NCFj, and the satisfaction of these constraints is made suitable by manual or automatic simplification. In particular, a constraint removal operation CE 222 may be performed, and based on the instantiation parameter IP-Si1 of the first subgraph and the instantiation parameter IP-Si2 of the second subgraph, it may be determined that the noise constraints of the first subgraph Si1 are at least as strict as those of the second subgraph Si2. As illustrated elsewhere in this specification, this may apply not only when the subgraphs are of the same type but also when the subgraphs are of different types. In any case, in such a situation, the noise constraints of the second subgraph can be removed from the optimization, making the optimization Opt easier to perform. In other words, the noise realizable set

Number

Number

[0127] Additional realizable set S other It is noted that when used, the same technique can also be used to remove the constraints of each subgraph from the calculation of its realizable set.

[0128] In general, the optimization OPT may evaluate the computational cost of performing encrypted calculations in various ways, for example, by performing simulations or by measuring the actual computational cost of performing encrypted calculations.

[0129] A particularly efficient way to evaluate the computational cost is to use a cost function that can be calculated, for example, as a closed formula, based on the parameters ECP of the encrypted calculation without simulation or measurement. In particular, the cost function may be based on the cost of each subgraph. Such a cost for a subgraph of a given type Tj may be defined by cost functions CF1 278, CF2 279 for given types T1, T2. The cost function usually depends on the parameters ECPj of the encrypted calculation for a given type Tj and allows these parameters ECPj to be optimized for the cost function.

[0130] Interestingly, as an approximation, the cost function CFj may be defined to be independent of the instantiation parameter IP-Si of a particular subgraph Si. This is a reasonable approximation that greatly simplifies the optimization OPT since the parameters can be optimized for each type of subgraph rather than for each subgraph.

[0131] As an example, consider types of subgraphs that include linear mapping (or equivalently, multisum), key switching, modulus switching, blind rotation, and sample extraction. Each of these operations generally has a respective cost that depends at least on the parameters ECP of the encrypted computation. For key switch, modulus switching, blind rotation, and sample extraction, the cost function usually does not depend on the instantiation parameters.

[0132] For linear mapping, it is possible to define the cost function such that 1) the cost function does not depend on the linear mapping being applied (e.g., the number of additions and / or the value of the scalar being multiplied), or 2) the cost function depends on the linear mapping.

[0133] In the first case, since the cost of the linear mapping does not depend on the number of additions / multiplications and depends only on the parameters ECPG, ECPi that are not instance-specific, it is possible to simplify the optimization problem solved by the optimization OPT. For example, the cost of the subgraph may be defined as the sum of the costs of the operations that do not depend on the instantiation parameters: ∀x∈E,Cost(A(ν,t),x)=Cost(Σ(ν)x)+Cost(KS,x)+Cost(MS,x)+Cost(BR,x)+Cost(SE,x) As a result, the costs of different subgraphs of the same type in G are the same. Therefore, the optimization

Number

Number

[0134] The cost function may be defined as the sum of the costs of each subgraph, but this is not necessary. More generally, the cost may be defined by combining the costs of each subgraph or type of subgraph. Also, the cost of a particular subgraph, Cost(A(ν,t),x) or Cost(A(·,·),x), need not be the sum of the costs of each operation. For example, the cost of a subgraph may be defined as a polynomial of the costs of each operation of the subgraph. Such a more general cost function may be used, for example, to optimize with respect to latency, and the cost function may be configured to take into account that some operations of the subgraph and / or some subgraphs may be evaluated in parallel.

[0135] Generally, there are many different ways for an optimizer OPT to determine the encrypted computation parameters ECP. For example, the optimizer may perform a brute-force search. Interestingly, as described herein, this may be feasible especially when constraint elimination CE is performed.

[0136] A preferred way to determine the encrypted computation parameters ECP is by the branch and bound method. As is known per se, using the branch and bound method, an optimal solution in terms of computational cost may be found based on a given upper and lower bound of the computational cost. Given these limits, the branch and bound method can be much more efficient than a brute-force search.

[0137] In particular, the branch and bound method can be done by first efficiently finding a set of feasible parameters and then deriving the lower and / or upper bounds using the feasible parameters.

[0138] As an example, consider an encrypted computation graph that includes one or more subgraphs of the type shown in FIG. 4a. As considered in connection with this figure, such a subgraph is A i =A(νi ,t i may be represented as ν i is the 2-norm of the applied linear mapping, and t i is the noise limit. The set of achievable parameters is such that for all subgraphs of this type, ν max ==max{ν i} i∈I and t min =min{t i} i∈I for a single subgraph A i =A(ν max ,t min ). By this construction, solving the optimization problem for this graph can be guaranteed to output an achievable solution with respect to the input graph G. Thus, the optimization problem may be solved on this graph, remembering the optimal parameters.

[0139] ∀i, ν i ∈I norm and t i ∈I p for a given encrypted computation graph G = {A(ν i ,t i ) i}, a table of achievable parameters can be constructed by performing an optimization Opt for each subgraph respectively. That is, the optimization problem can be solved, for example, by solving the optimization problem |I norm |·|I p | times, for each graph G = {A(ν,t)} where ν ∈ I norm and t ∈ I p . Thus, for each pair (ν,t), a respective set of allowable parameters can be determined.

[0140] In particular, lower and upper bounds derived from the noise and cost models may be used to perform the optimization for the subgraph. As an example for illustration, the noise function

Number

Number

[0141] After determining the table of achievable parameters, the table may be used to efficiently derive upper and lower bounds for the encryption computation graph G where ν max = max{ν i} i∈I and t min = min{t i} i∈I Furthermore, an initial solution for optimization may be determined based on the table. Interestingly, this table enables the efficient determination of a relatively good initial solution, which improves the efficiency of optimization.

[0142] As an example for illustration, the lower and upper bounds can take into account the number of programmable bootstrappings for a linear mapping as considered in relation to Figure 7b as follows.

[0143] The lower bound can be derived based on the parameters corresponding to the maximum number of programmable bootstrappings without considering the cost of programmable bootstrapping. In particular, the largest possible split may be taken to reduce the noise of the output of each split multi-sum. Ignoring the cost of the added PBS, the input graph can be transformed accordingly and take the maximum 2-norm with respect to the minimum noise limit

Number

Number

[0144] The upper bound can be derived based on the parameters corresponding to the minimum number of programmable bootstrappings, while including the cost of performing the maximum number of programmable bootstrappings. In particular, taking the smallest possible division and considering the cost of the added PBS, the input graph can be transformed accordingly, and the parameters in the case of (ν max , t min ) can be obtained from a table of achievable parameters. In this way, an upper bound on the complexity can be obtained.

[0145] After determining the encrypted computation parameters ECP, the combining operation COMB 224 can be applied, and the parameters ECP can be substituted into the parameterized encrypted computation graph ECG. Thus, the computation graph ECG can be compiled into a set of instructions HE 290 for the encrypted computation engine. By executing the instructions HE, the encrypted computation can be performed according to the determined encrypted computation parameters ECP by the same device that performs the optimization OPT, or more typically, by a different device that receives the instructions HE for execution.

[0146] Figure 3 shows a detailed but non-limiting example of the constraints on the noise of the ciphertext. In particular, an example of deriving the noise limit from the desired accuracy when the encoding of values into the ciphertext is given and the desired maximum error probability is given is provided. Such a noise limit may be used to define the noise constraints of the subgraph, as was also considered in relation to Figure 2. In particular, the noise constraints may be defined by determining the maximum noise of the ciphertext of the type of subgraph and constraining this maximum noise to be less than the noise limit.

[0147] In particular, the noise limit t(·) may be a threshold applied to the noise of the ciphertext. The noise limit may be parameterized by an error probability that may be configurable by the user. The error probability may also be hard-coded. It is noted that for security reasons, the exact noise contained in the ciphertext is not known to the parties performing the encrypted computation. However, these parties typically know the variance of the probability distribution of the noise at a given point in time, assuming that the input given to it has a given variance. Thus, the noise limit may represent a limit in terms of the variance of the errors in the ciphertext. In general, the noise limit may depend on the number of bits of accuracy used to represent the message and the desired probability that the decryption is correct.

[0148] As an example for illustration, the figure shows the noise limit 310 of an LWE-type ciphertext based on the encoding 320 of a message m. The presented method for deriving the noise limit applies to various encrypted computation techniques proposed, for example, in the following literature: - TFHE: I. Chillotti et al., "Faster fully homomorphic encryption: Bootstrapping in less than 0.1 seconds", proceedings ASIACRYPT 2016 and I. Chillotti et al., "Faster packed homomorphic operations and efficient circuit bootstrapping for TFHE", proceedings ASIACRYPT 2017; - FHEW: L. Ducas et al., "FHEW: bootstrapping homomorphic encryption in less than a second", proceedings EUROCRYPT 2015; - BFV: J. Fan and F. Vercauteren, "Somewhat Practical Fully Homomorphic Encryption", http: / / eprint.iacr.org / 2012 / 144; - CKKS: Jung Hee Cheon et al., "Homomorphic Encryption for Arithmetic of Approximate Numbers", proceedings ASIACRYPT 2017.

[0149] In the example shown in the figure, the message m 322 has a bit length p and is encrypted in the most significant bit of a single ciphertext. In particular, the LWE ciphertext is a tuple (a1,...a [Number] which may be a tuple (a1,...a n ,b), where: - [Number] is a secret key with coefficients sampled according to a given distribution, for example, a uniform binary, uniform ternary, or Gaussian distribution; - [Number] is [Number] sampled from the uniform distribution in [Number] and is an integer in - e + Δm is the encoding 320 of the message that includes the error e 326 sampled from the centred Gaussian distribution χ σ and the re-scaled message Δm 322 in the most significant bit. It is.

[0150] In this example, the noise term e326 is sampled from a Gaussian distribution. The noise limit may be defined based on the variance threshold of the noise term, and thus, if the noise remains below this threshold, the calculation is correct up to a given probability p err up to.

[0151] In particular, this figure shows the following: - The modulus q327 of the ciphertext, for example, 2 32 , 2 64 , or a power of 2 such as 2 128 or other than a power of 2 such as a prime number; - The accuracy p, for example, the message m322 having the number of bits used to encode the message; - The MSB321 set to 0 required for various programmable bootstrapping implementations; - Padding bits 323 to prevent noise from contaminating the message m during decoding due to rounding; - p err ≈ 2 -13.9 The standard score z corresponding to the error probability 330 of * (p err ) = 4 corresponding additional bits 324.

[0152] As shown in the figure, the noise limit 310 can be obtained based on the number of bits required for padding 321, message 322, padding 323, and error margin 324. The noise limit 310 may require that the variance of the noise 326 remains below this value. In this particular case, there is a room 325 between the noise limit and the error, and thus, the noise constraint is satisfied.

[0153] The above example can be adapted to various other encodings as desired. For example, as proposed by I. Chillotti et al., "Improved programmable bootstrapping with larger precision and efficient arithmetic circuits for TFHE", proceedings ASIACRYPT 2021, or Z. Liu et al., "Large-precision homomorphic sign evaluation using FHEW / TFHE bootstrapping", Cryptology ePrint Archive 2021 / 1337, MSB 321 can be removed if programmable bootstrapping does not require it. Programmable bootstrapping without padding bits 321 is also referred to herein as "WOPBS". This results in a noise limit that is twice as high, e.g., [Number] results in.

[0154] More generally, the noise limit can be calculated as [Number] where pad left can be any number of padding bits on the left side of the message, and pad right can be any number of padding bits on the right side of the message.

[0155] Interestingly, given the encoding and error probability, the noise limit can depend only on the desired accuracy of the message m. In particular, the number of possible values that the noise limit can achieve may be relatively small, e.g., the number of possible values may be at most 10 or at most 20. As explained elsewhere, when optimizing the parameters of encrypted computations, a limited number of possible values can be advantageously used.

[0156] FIG. 4a shows a detailed but non-limiting example of a type of subgraph. This type of subgraph is also referred to as an atomic pattern of type 1.

[0157] In this example, subgraph 400 includes a linear mapping 420 for one or more input ciphertexts 410 - 412. The linear mapping may include one or more homomorphic additions of the ciphertext with another ciphertext and / or plaintext, and / or one or more homomorphic multiplications of the ciphertext with a scalar. In general, any number of such operations, e.g., addition of ciphertext / plaintext or ciphertext / ciphertext, and multiplication of plaintext and ciphertext, can be represented as a dot product between a vector of ciphertexts and a vector of plaintexts. Thus, linear mapping 420 may represent the calculation of this dot product. Linear mapping 420 may have a vector of plaintexts corresponding to each input ciphertext 410 - 412 as instantiation parameters; interestingly, for the purpose of optimization, it may be sufficient to represent linear mapping 420 only by the 2-norm of the vector of plaintexts. Thus, the subgraph may have the 2-norm of the vector of plaintexts corresponding to linear mapping 420 as an instantiation parameter.

[0158] In addition to linear mapping 420, subgraph 400 includes a key switching 430; in this case, a modular switching 440 and a programmable bootstrapping implemented by a subsequent blind rotation and sample extraction 450, resulting in an output ciphertext 460. Since output ciphertext 460 is obtained as a result of programmable bootstrapping, interestingly, its noise can be made independent of the input (at least when the noise constraints are met), e.g., independent of the noise of input ciphertexts 410 - 412 and the 2-norm of linear mapping 420. For the purposes of this figure, blind rotation and sample extraction are represented by a single node 450; it is also possible to represent them as separate nodes.

[0159] Often, the overall computational graph can be split into subgraphs that introduce noise independent of the input. For example, the input ciphertexts 410-412 may result from an encryption operator or programmable bootstrapping (optionally with rounding). In such cases, the noise of the input may be assumed to be bounded by the maximum of the input-independent noise used, e.g., the noise resulting from programmable bootstrapping. Each operation 420-450 may introduce the noise of each ciphertext obtained by propagating the noise of the input (e.g., up to the limits considered or given as instantiation parameters) throughout the graph, as considered in relation to FIG. 4b, while performing the computation represented by the subgraph.

[0160] In addition to the 2-norm of the linear mapping 420 applied, the subgraph 400 may be further parameterized by instantiation parameters representing noise limits 421, 431, 441, 451 that the ciphertexts output by operations 420-450 may be required to satisfy. Interestingly, it may be observed that operations 420, 430, 440 typically increase the noise, while the output noise of the blind rotation 450 is independent of the noise of its input. Thus, to verify that the subgraph satisfies the noise constraint, it may be sufficient to verify this limit 451 only with respect to the noise of the input to the blind rotation 450.

[0161] The parameters for the encrypted computations for the type of subgraph 400 may include the decomposition base B and the decomposition level l of the programmable bootstrapping 450 and the key switching 430. In general, these parameters can affect the noise of the outputs of the key switching and the programmable bootstrapping: if the noise becomes too large, the correctness of the computation may be lost. Furthermore, the parameters can affect the computational cost of the operations, especially the computation cost of the blind rotation 450. These parameters for the encrypted computations may be shared during the instantiation of the type of subgraph. It is also possible to define multiple types of subgraphs that have the same structure 400 but, for example, have different parameters for the bootstrapping and / or the key switching. This can be implemented, for example, by representing the bootstrapping and / or the key switching with different parameters as different FHE operations, and thus leading to different types of subgraphs.

[0162] The computational cost of performing the computations of the subgraph 400 may be represented by a cost function, as will be considered elsewhere. In particular, the cost may be obtained by combining the costs of the respective FHE operations, for example: Cost(A(ν,t),x)=Cost(Σ(ν)x)+Cost(KS,x)+Cost(MS,x)+Cost(BR,x)+Cost(SE,x) The cost Cost(Σ(ν)x) of computing the linear map 420 may be based on the corresponding 2-norm, and / or the number of inputs, and / or the number of additions and multiplications, as will be explained elsewhere. The cost of the linear map can also be approximated to be independent of the particular linear map being applied, and thus obtaining a cost function that is independent of the instantiation parameters.

[0163] Optionally, the number of possible values of the key switching and / or blind rotation decomposition base and decomposition level may be reduced by removing possible parameter sets that have worse noise and / or complexity than other parameter sets. In particular, the key switch may add linear noise to the input noise, and the blind rotation may reset the input noise, so in either case, the noise of the operation can be considered independently of the input noise. Furthermore, for both operations, the computational cost may increase as the level increases. Therefore, combinations of (base, level) that are worse than their combinations in terms of both noise and complexity may be removed. This is shown by the procedure below.

[0164] let C β,l ={} for n ∈ {256,..., 2048} for N ∈ {28,..., 214} for k ∈ {1,..., 10} for β, l ∈ {(β, l) ∈ {1,..., 64} 2 | β · l ≤ log2q} Noise of blind rotation

Number

Number

Number

[0165] For example, in a specific case, the number #Ω of parameter values that can be blindly rotated β,l may decrease from 280 to 35, and the number of key switching values may decrease from 280 to 46.

[0166] Figure 4b shows a detailed but non-limiting example of the noise of the ciphertext during the evaluation of the subgraph of the encrypted computation. In this example, a subgraph of the type shown in relation to Figure 4a is executed. In particular, the figure shows a linear mapping 420 applied to one or more input ciphertexts 410, 411; a subsequent key switching 430; a modulus switching 440; and a blind rotation and sample extraction 450 that results in an output ciphertext 460.

[0167] In particular, as shown in the figure, each FHE operation may have a respective noise model that defines how the noise of the ciphertext of the output of the FHE operation relates to the noise of the input ciphertext. The noise model may generally take as input the encrypted computation parameters and the instantiation parameters for each operation. In this particular example, the noise model of the linear mapping 420 may depend on the applied linear mapping and, in particular, may depend on the 2-norm ν of the applied linear mapping. That is, the noise variance of the output of the linear mapping 420 Σ(ν) may be modeled as equal to the input noise variance multiplied by ν 2 in some cases. The noise of the remaining operations of the subgraph 400 may depend only on the encrypted computation parameters.

[0168] For example, key switching 430 and blind rotation 450 in each instantiation of the subgraph 400 type may use the same key switching key and bootstrapping key. Thus, the noise constraints for the instantiation of the subgraph 400 are the 2-norm of the linear mapping 420, and the noise limit indicating the maximum level to which noise is allowed to reach, or equivalently, the desired accuracy of the encrypted value, and the instantiation parameters of the subgraph 400; it may depend only on the parameters of the global encrypted computation and / or the parameters of the encrypted computation for the type of subgraph. Thus, in this example, there are no encrypted computation parameters specific to the instantiation. Thus, each instantiation of the shown subgraph type may be distinguished by their 2-norm ν and noise limit t(p).

[0169] As shown in the figure, it can be assumed that all input ciphertexts of each instantiation of the subgraph 400 have the same noise 419 corresponding to the noise 459 of the output of, for example, blind rotation and sample extraction 450 (and optional rounding). This is particularly the case when the overall computational graph is divided into subgraphs representing sub-computations that result in output ciphertexts with input-independent noise, for example, by dividing the computation in programmable bootstrapping (and optional rounding) operations. However, this is not strictly required, for example, the input noise may be an instantiation parameter.

[0170] The noise of the ciphertext during the evaluation of subgraph 400 is shown in graph 499. As shown by line 490, the noises 429, 439, 449 can generally grow significantly by each operator of the subgraph in this case until reaching its peak 449 after the modular switching 440. And the blind rotation and sample extraction 450 can then result in an output ciphertext 460 having an input-independent noise 459 corresponding to the noise 419 of the input of the subgraph. Graph 499 also shows a noise limit 492 of the noise 490, for example, based on the desired accuracy of the calculation. Since the noise increases until the blind rotation and sample extraction 450 are performed, the noise constraint of the subgraph 400 may thus indicate that the noise 449 of the input to the blind rotation is less than the noise limit 492.

[0171] Figure 4c shows a detailed but non-limiting example of the parameters of the encrypted calculation. These parameters are shown here with respect to the type 400 of the subgraph also shown in Figures 4a and 4b and include the linear mapping 420, the key switching 430, the modular switching 440, as well as the blind rotation and sample extraction 450. It will be understood that the same parameters of the encrypted calculation apply also when different combinations and / or orders of these operations are used. The figure shows, for some parameters of the encrypted calculation, where they are used in which part of the subgraph 400.

[0172] In particular, the figure shows the following parameters (along with the ranges of the following parameters including start and end values): - k: the dimension of the GLWE of the output of the blind rotation, for example, an integer having a maximum or at least 5, maximum or at least 10 possible values, for example, a value between 1 and 10; this may be a global parameter of the encrypted calculation; - N: the size of the GLWE polynomial of the output of the blind rotation, for example, a power of 2 having a maximum or at least 5 or maximum or at least 10 possible exponent values, for example, 2 8from 0 to 2 14 a power of 2 between 0 and 2. The sample extraction 450 can result in an LWE ciphertext of dimension k·N. This can be a global encrypted computation parameter; - n small : the dimension of the LWE of the output of the key switching 430, for example, an integer having at least 100 or at least 1000 possible values, for example, an integer between 256 and 2048. For the efficiency of optimization, the number of possible values considered may be limited. For example, n small may be assumed to be a power of 2, but this is not required for the encrypted computation itself. This can be a global encrypted computation parameter; - β KS : the decomposition base of the key switching 430, for example, an integer having at most or at least 32 or at most or at least 64 possible values, for example, an integer between 1 and 64; this is, for example, an encrypted computation parameter specific to the subgraph type 400 and may possibly be shared with one or more other subgraph types, and thus, the remaining subgraph types may use different values for this parameter; - l KS : the decomposition level of the key switching 430, for example, an integer having at most or at least 32 or at most or at least 64 possible values, for example, an integer between 1 and 64; this is, for example, an encrypted computation parameter specific to the subgraph type 400 and may possibly be shared with one or more other subgraph types, and thus, the remaining subgraph types may use different values for this parameter; - β BR: The decomposition basis of programmable bootstrapping 450, e.g., an integer having at most or at least 32 or at most or at least 64 possible values, e.g., an integer between 1 and 64; this is, for example, an encrypted calculation parameter specific to subgraph type 400 and may possibly be shared with one or more other subgraph types, and thus the remaining subgraph types may use different values for this parameter; - l BR : The decomposition level of programmable bootstrapping 450, e.g., an integer having at most or at least 32 or at most or at least 64 possible values, e.g., an integer between 1 and 64; this is, for example, an encrypted calculation parameter specific to subgraph type 400 and may possibly be shared with one or more other subgraph types, and thus the remaining subgraph types may use different values for this parameter.

[0173] For example, within the range of parameters considered above, the number of possible values of this parameter combination can be approximately 2 41 and this emphasizes the validity of the efficient optimization of the parameters.

[0174] Figure 5 shows a detailed but non - limiting example of noise constraint removal. In particular, it shows how, based on the instantiation parameters of the first and second subgraphs, it may be determined that the noise constraint of the first subgraph is at least as strict as that of the second subgraph. In such a case, the noise constraint of the second subgraph may be removed from the optimization of the encrypted calculation parameters described herein.

[0175] In this example, the subgraph may be parameterized by a noise limit t(p) and the 2 - norm ν of the applied linear mapping, as may be the case for subgraph types shown in, for example, FIGS. 4a, 6a, and 8.

[0176] In such a case, when two instantiations of the same subgraph have the same noise limit, generally, the instantiation with the smaller 2-norm has less ciphertext noise. Thus, it may be noted that if the other instantiation satisfies the constraints, this instantiation may also satisfy the constraints. Similarly, when two instantiations have the same 2-norm and the first instantiation has a higher noise limit, in other words, a noise limit that is easier to satisfy, it may be sufficient to ensure that the noise limit of the second instantiation is satisfied.

[0177] In other words, the noise constraint may be removed when the noise limit of the first subgraph is at most the noise limit of the second subgraph and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph. Mathematically, if ν1 and ν2 are 2-norms such that ν1 ≤ ν2, and t1 and t2 are noise limits such that t2 ≤ t1, then

Equation

[0178] For example, in the figure: - Subgraph A4 can be removed thanks to Subgraph A1 or thanks to Subgraph A2; - Subgraph A5 can be removed thanks to Subgraph A2 or thanks to Subgraph A3; - Subgraph A6 can be removed thanks to Subgraph A1, A2, A3, A4, or A5; Thus, the non-removed subgraphs in this example may be Subgraphs A1, A2, and A3. The set of non-removed subgraphs may be called the "Pareto front" of the subgraph types.

[0179] As a result of removing the noise constraints of some subgraphs, it may no longer be necessary to check the constraints of as many realizable sets as there are existing subgraphs. Instead, it may be sufficient to check the constraints of the subgraphs that are not removed. In an example where a subgraph is defined by two instantiation parameters, and at least one of those instantiation parameters has a limited number of values, such as a noise limit and a 2-norm, this is particularly beneficial because the number of non-removed subgraphs is at most the number of values of the instantiation parameters. For example, with respect to the type of subgraph, the number of noise limits, and thus the number of non-removed subgraphs, may be at most 5 or at most 10.

[0180] Figure 6a shows a detailed but non-limiting example of the type of subgraph 600. This type of subgraph may include one or more key switchings 620-1, 620-2, 620-3 for each input ciphertext 611, 612, 613; a linear mapping 630; and a programmable bootstrapping applied to the output of the linear mapping, such as a modulus switching 640 and subsequent blind rotation and sample extraction 650. The output ciphertext 660 may be the output of the sample extraction, and any rounding may be applied to the output, as described elsewhere. Thus, the output ciphertext 660 may have noise that is independent of the noise of the input ciphertexts 611-613.

[0181] Interestingly, also with respect to that type of subgraph 600, if the noise limit of the first subgraph is at most the noise limit of the second subgraph and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph, the noise constraints of the second subgraph may be removed. Further, interestingly, the subgraph may be of type 600, but it may also be of type 400 shown in relation to Figure 4a.

[0182] In particular, the subgraph types 400 in FIG. 4a, such as Multisum, key switch, modulus switch, blind rotation, and sample extraction, are A 1 also called the "atomic pattern of type 1" denoted as A 2 The subgraph type 600 in this figure may be called the "atomic pattern of type 2" denoted as A

[0183] For example, the encryption computation graph G may be composed of all of these two types of APs. Independently for each type, as described in relation to FIG. 5, subgraphs may be removed.

[0184] However, interestingly, by comparing subgraphs of two different types of APs 400, 600, it may be possible to further remove subgraphs. More generally, by determining that the noise constraint of the first subgraph of a different type is at least as strict as that of the second subgraph, the noise constraint of the second subgraph may be removed from the optimization of the encrypted computation parameters.

[0185] In particular, for the purpose of removal, FHE operators may be divided into three categories with respect to noise: - Operators that output noise independent of input noise, such as PBS, WOPBS; - Operators that add noise independent of the input to the input noise, such as key switch 620, modulus switch 640; - Operators that output ciphertext with noise (e.g., non-linearly) dependent on input noise, such as Multisum 630, GLWE multiplication, etc.

[0186] Specifically, consider two types of subgraphs where the FHE operators of type 2 and type 3 are reordered, as is the case for multi-sum 630 and key switch 620 of subgraph types 400, 600. Note that non-type 1 FHE operators increase the noise within the ciphertext. The type 3 FHE operator increases the noise depending on the input noise, so the greater the input noise, the greater the output noise.

[0187] From this, the following conclusion may be drawn. A 1 and A 2 contain the same operations, but are distinguished in that in A 1 the type 2 FHE operator comes before the type 3 FHE operator, while in A 2 the same type 2 FHE operator comes after the type 3 operator. Then, the noise of A 2 is greater than the noise of A 1 . For example, let A 2 correspond to subgraph type 600 of FIG. 6a, and A 1 correspond to subgraph type 400 of FIG. 4a. Let ν be the 2-norm and t be the noise limit. Then, since the noise of the type 2 operator is amplified by the type 3 operator, the noise of A 2 (ν,t) is greater than the noise of A 1 (ν,t).

[0188] The above example shows, in particular, how a certain type of subgraph can be used to remove the noise constraints of another type of subgraph when the subgraph type differs due to a reordering between the type 2 and type 3 FHE operators, in this case, due to KS and Multisum. Specifically, let ν1, ν2 represent 2-norms such that ν1 ≤ ν2, and let t1, t2 represent noise limits such that t2 ≤ t1. Then,

Equation

[0189] More generally, it may be noted that the noise constraint may be removed regardless of what operation follows the ciphertext with the maximum noise, for example, regardless of what follows a type 1 FHE operator. In particular, subgraph 600 is shown using one operator of type 1, a blind rotation, and a sample extraction 650. More generally, in a graph with multiple types of subgraphs, additional types of subgraphs may have one or more different operators of type 1 as final nodes. Since these operators do not affect the maximum noise and thus do not affect the noise constraint, as described herein, a subgraph of one of those types can be removed based on a subgraph of another of those types.

[0190] FIG. 6b shows a detailed but non-limiting example of the type of subgraph 601. This type of subgraph may include one or more linear mappings 621, 622 on one or more input ciphertexts 614, 615; a subsequent leveled encrypted multiplication 670; a key switching 631; and a programmable bootstrapping 651. The leveled encrypted multiplication 670 may include, for example, a packing key switch, a tensor product, and a relinearization, as is known per se, and may also be presented by respective nodes for each sub-operation. Similarly, the programmable bootstrapping is represented in this example by a single node 651, but may also be represented by nodes for each of its sub-operations, as in FIG. 6a for example. This type of subgraph may be referred to as an "atomic pattern of type 3" denoted as A 3 and may be called.

[0191] Thus, the sub-graph type 601 may be based on the sub-graph type 400 and further includes a multiplication 670. Similarly, based on the sub-graph type 600 of FIG. 6a, a fourth sub-graph type may be defined that further includes an encrypted multiplication between the linear mapping 630 and the modulus switching 640.

[0192] Interestingly, the first type of sub-graph may be removed based on the third type of sub-graph, and similarly, the second type of sub-graph may be removed based on the fourth type of sub-graph. More generally, a particular type of sub-graph may be removed based on a sub-graph of that type with additional leveled encrypted multiplications. In fact, leveled encrypted multiplications add additional noise and thus lead to more stringent noise constraints.

[0193] For example, let 1 A(ν,t) be a sub-graph of the first type, and let 3 A(ν1,ν2,t) be a sub-graph of the third type. [Number] If so, then 3 A(ν1,ν2,t) is superior to 1 A(ν,t), and thus the latter may be removed.

[0194] FIG. 7a shows a detailed but non-limiting example of the identification of the respective key-switching keys and / or bootstrapping keys used for each sub-graph.

[0195] As discussed elsewhere, key-switching keys and bootstrapping keys may be specific to a particular set of parameters for encrypted computations, such as level and decomposition key parameters. As discussed in connection with FIG. 4a, these parameters may be shared among different instantiations of the same type of subgraph. In particular, in some cases, the same key-switching key and / or bootstrapping key may be used throughout the encrypted computation. This has the advantage of leading to less key material, but on the other hand, in this case, the subgraphs in which this is possible are noisier and it is not possible to use faster key-switching or bootstrapping, which can have an adverse effect on the computational complexity.

[0196] There are several ways to support multiple key-switching keys and / or bootstrapping keys in the same encrypted computation. As also discussed in connection with FIG. 4a, one way is to define each type of subgraph that has the same structure but uses a respective key-switching key and / or bootstrapping key, and a particular subgraph is preconfigured to have a particular type. The drawback of this approach is that it is not possible to automatically optimize which key is used in which subgraph.

[0197] Another approach is to define key-switching and / or bootstrapping cryptographic parameters (e.g., level / base) as parameters for encrypted computations for a particular instance of a subgraph rather than for a type of subgraph. In such cases, the number of different keys used in the computation can be limited by including this as an optimization constraint. However, this approach leads to a large number of additional parameters and makes the optimization problem much more complex.

[0198] Interestingly, the inventors have contemplated a better way to automatically determine which key-switching keys and / or bootstrapping keys to use in which subgraphs. That is, multiple sets of parameters (e.g., levels and / or bases) corresponding to multiple sets of key-switching keys and / or bootstrapping keys may be defined, for example, as part of the parameters of a global encrypted computation or as parameters for a given type of subgraph. The number of sets to use may be preconfigured. For a given subgraph 770-772, the encrypted computation parameters δ 780-782 of that subgraph may identify which set of parameters is used in the subgraph.

[0199] This is shown below with respect to key switching. Assume that the number of key-switching keys to use is X and the number of subgraphs in which they are used is Y. The optimization of the key-switching keys to use may correspond to determining, for all i ∈ [1, Y], δ i ∈ [1, X], leading to an additional search space of size X Y . This is better than having a separate set of parameters for each subgraph, but is still quite large.

[0200] Interestingly, the inventors have noticed that when the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the search space for identifying key-switching keys (and similarly for bootstrapping keys) can be significantly reduced by constraining the key-switching keys of the first subgraph to add at most the same amount of noise as the key-switching keys of the second subgraph.

[0201] In particular, the key switching keys used may be ordered as a sequence (KSK0, KSK1,...) such that, for example, KSK0 adds less noise than KSK1, KSK1 adds less noise than KSK2, and so on according to the amount of noise added. In such a case, usually, the key switch using KSK0 has a higher computational cost than the key switch using KSK1, leading to a trade-off between cost and noise.

[0202] As an example, consider a plurality of subgraphs (e.g., of type 1 or 2 considered herein) having the same noise limit t and different 2-norms, G = {A(ν0, t), A(ν1, t), A(ν2, t)} such that ν0 < ν1 < ν2. Further, consider two key switching keys KSK0 and KSK1 such that KSK1 adds more noise during the key switch than KSK0. The key switching key used in each subgraph may be represented by a parameter (δ0, δ1, δ2), δ i ∈ {0, 1}, 780 - 782.

[0203] Note that in this example, (δ0, δ1, δ2) = (0, 1, 0) cannot be an optimal solution. This can be argued as follows. As considered in relation to FIGS. 4a and 6a, in this case,

Number

[0204] Assume that (δ0, δ1, δ2) = (0, 1, 0) is the optimal solution. Further, the noise constraint of A(ν0, t) can be removed from the optimization since the noise constraint of A(ν2, t) is at least as strict.

[0205] Here, consider the solution (δ0, δ1, δ2) = (1, 1, 0). In this case, the noise constraint of A(ν0, t) can be removed from the optimization because the noise constraint of A(ν1, t) is at least as strict.

[0206] As a result, for G = G where (δ0, δ1, δ2) = (0, 1, 0) 010 and G = G where (δ0, δ1, δ2) = (1, 1, 0) 110 we have: ― (δ0, δ1, δ2) can be equal to (0, 1, 0) or (1, 1, 0), and in either case, the resulting

Number

Number

[0207] ― The only difference between G 010 and G 110 is that the former uses a slower key switch, so

Number

[0208] The above argument can be extended to graphs with any number of subgraphs having the same noise limit. In such a case, identifying each key-switching key may well correspond to determining the number of the most noise-constrained subgraphs that use the first key-switching key, and the remaining subgraphs use the second key-switching key. This significantly reduces the parameter space. Mathematically, ν0 < ν1 < ν2 <... < ν Yand G={A(ν i ,t)} i∈I Let us assume that two key switching keys are used. Then, the optimal δ = (δ0,...,δ Y ) is of the form (1,...,1,0,...,0). Thus, the optimization is to find all possible {δ i} i∈I There is no need to calculate, for example, δ i-1 = 1 and δ i It may be sufficient to determine γ∈{1,...,Y} such that δ=(1,...,1,0,...,0) for γ=i=0. This is a generalized problem for Y This means that instead of having to search in a search space of size Y, it may be sufficient to search in a space of size Y.

[0209] The above arguments also hold for any number of key-switching keys. In this case, it may be sufficient to determine the number of subgraphs (ordered from most to least noise-constrained) that use each key-switching key. Mathematically, ν0<ν1<ν2<...<ν Y and G={A(ν i ,t)} i∈I Let us assume that the Xth key is one of the switching keys. Then, the optimal δ=(δ0,...,δ Y ) is of the form (Y,...,Y,Y-1,...,Y-1,...,1,...,1,0,...,0). As a result, for all possible {δ i} i∈I There is no need to calculate, for example, γ j ∈[[1,Y]],δ i-1 = x∈[[1,X-1]] and δ i = x + 1 j =i, and {γ0<γ1<...} j} j∈[[1,X-1]] This is because size X Y Instead of having to search in a search space of size

number

[0210] The above method can be applied to each set of subgraphs that share the respective noise limits by defining respective key identifier vectors (δ0,..., δ Y ).

[0211] Furthermore, the above method can also be applied to identify each bootstrapping key used in each subgraph, in which case the bootstrapping keys are ordered according to the amount of noise added.

[0212] Also, for a given subgraph, it is possible to determine both the key switching key and the bootstrapping key used. In such a case, if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the key switching key and the bootstrapping key for the first subgraph may be constrained such that neither adds more noise than the key switching key and the bootstrapping key for the second subgraph. For example: if ν1 > ν2 and t is the noise limit,

Number

Number

Number

Number

[0213] FIG. 7b shows a detailed but non-limiting example of the determination of the number of programmable bootstrap operations performed during the application of a linear mapping. The example of this figure is based on the type of sub-graph of FIG. 4a, but the technique is equally applicable to other types of sub-graphs that include the application of a linear mapping, such as the type of sub-graph shown in FIG. 6a.

[0214] Shown in the figure is a sub-graph 700 of the type shown in relation to FIG. 4a, including a linear mapping 720 applied to one or more input ciphertexts 710; a subsequent key switching 730; and a programmable bootstrap operation 740 (shown here as a single node, but typically implemented as modular switching; blind rotation; and sample extraction) that results in an output ciphertext 760.

[0215] Also shown is a different sub-graph 700’ that calculates the same output ciphertext 760 from the same input ciphertext 710, but does so by using a programmable bootstrap operation 750 during the application of a linear mapping that is split into two parts 721, 722 in this case. The inserted programmable bootstrap operation 750 in this example applies the identity function, but could also incorporate, for example, scalar multiplication and / or addition of a public value. Similar to sub-graph 700, key switching and programmable bootstrap operation 730 (shown here as a single node for brevity) are applied to the outputs of linear mappings 721 - 722 to obtain the output ciphertext.

[0216] Inserting PBS 750 into the sub-graph may, in this case, increase the computational complexity during the application of the linear mapping. On the other hand, the noise of the ciphertext during the evaluation of the sub-graph is reduced by PBS 750, which in this case reduces the 2-norm of the multi-sums 721, 722, thus enabling the use of parameters that are noisier but faster.

[0217] Interestingly, the inventors have optimized with respect to this trade-off, thereby making it possible to automatically determine, for each subgraph of a given type, the respective number of programmable bootstrappings that are performed during the application of each linear mapping in the subgraph, for example as in this case. Thus, a type of subgraph having a variable number d of programmable bootstrappings may be defined. For example, the computational graph of the encrypted computation input to the optimization may not include programmable bootstrapping during the application of each linear mapping, in which case the optimization inserts those programmable bootstrappings as appropriate.

[0218] Mathematically, the optimization problem is, in this case,

Number

[0219] When it is determined to perform one or more programmable bootstrappings during a linear mapping, the linear mapping may be automatically split into a number of linear mappings corresponding to the number of programmable bootstrappings. This can be done by minimizing the maximum 2-norm of each linear mapping, for example, ν1≒ν2. In this way, the insertion of programmable bootstrapping is most effective in enabling noisier parameters.

[0220] In particular, the linear mapping may be split by minimizing the maximum 2-norm of each linear mapping. This provides a good approximation of the optimal solution in terms of noise and complexity by effectively ignoring the cost of the multi-sums (and in particular, the number of inputs to which each multi-sum is applied). In particular, to split a multi-sum into two multi-sums, such as subgraph 700’, the following optimization problem can be solved using, for example, an appropriate solution known per se:

Number

[0221] Another technique for splitting Multisim is as follows. This technique is particularly effective when the weights are close to a uniform distribution, for example, when w i ∈ [-2 p , 2 p . According to this technique, each weight is radix-decomposed into digits, and the digits are applied to the input and combined. For example, the radix decomposition may be similar to Algorithm 1 of I. Chillotti et al., "Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 seconds", proceedings ASIACRYPT 2016 (incorporated herein by reference), or it may be possible to use a signed decomposition as disclosed in M. Joye, "Balanced non-adjacent forms", proceedings ASIACRYPT 2021 (incorporated herein by reference). In particular, the level of radix decomposition may be equal to d + 1, where d is the number of programmable bootstrappings applied, and the base log is [Number] may be set to. Each Λ i may be a respective power of base B.

[0222] Interestingly, the number d of programmable bootstrappings performed for each subgraph i iWhen determining, if the noise constraint of the first subgraph i is at least as strict as the noise constraint of the second subgraph j, the number d of programmable bootstrapping of the second subgraph j is such that the number d of programmable bootstrapping of the first subgraph i is restricted, by which the parameter space of d i may be significantly reduced.

[0223] That is, if inserting PBS into the subgraph does not change the parameters, the insertion is not always optimal. More precisely, let G = A(ν i ,t) be such that ν0 < ν1 <.... d * =(d1 * ,...) and

Number

Number

Number

Number

Number

[0224] FIG. 8 shows a detailed but non-limiting example of programmable bootstrapping with noise rounding. This example can be combined with any type of subgraph including programmable bootstrapping, e.g., the type of subgraphs of FIGS. 4a, 6a, 6b, or 7b.

[0225] In particular, this example shows programmable bootstrapping including a modulus switch 840 applied to an input ciphertext 839 of the programmable bootstrapping that yields an LWE-encrypted modulus switching output 849; and a blind rotation 851 that uses a bootstrapping key 854 and a lookup table 855 that yields a GLWE-encrypted monomial 852 (RLWE-encrypted in this example), followed by a sample extraction 853 applied to the GLWE-encrypted monomial 852 to obtain the LWE-encrypted output ciphertext 869 of the programmable bootstrapping. These operations may be performed as is known per se.

[0226] Interestingly, as shown in this figure, a noise rounding operation 870 may be applied to the sample extraction output 869 to obtain a rounded output ciphertext 879. In particular, the operation may set a given number of least significant bits of the value of the ciphertext to zero, or in other words, round the value of the ciphertext to a given power of two. It is noted that the output ciphertext 869 typically has noise independent of the input, and thus the rounded output ciphertext 879 also has noise independent of the input.

[0227] As the inventors have noticed, by applying a rounding operation to the result of programmable bootstrapping, as long as the implementation of the fast Fourier transform (FFT) has a given accuracy, it is possible to make the rounded result 879 of programmable bootstrapping independent of the specific FFT implementation used to perform the programmable bootstrapping. Thereby, the PBS can become practically deterministic. This can result in, or at least contribute to, a fully encrypted calculation becoming deterministic.

[0228] That is, the inventors noticed that the output 869 of the sample extraction before rounding 870 can be different during the implementation of the FFT. This was actually observed in an experiment where the implementation of PBS on a CPU using FFTW was compared with the implementation on a GPU using a custom FFT. Both outputs are correct in themselves, but may differ in terms of the exact output noise produced. For many coefficients of the PBS output, it was observed that the most significant bits containing the message are the same, while there are some differences in the least significant bits (including the noise).

[0229] The number of bits to which rounding is applied, in other words, the place where rounding should be done, can be preconfigured, but it is also possible to determine this place as a parameter specific to the encrypted calculation, for example, a global encrypted calculation parameter or a parameter specific to the type of subgraph. That is, rounding can add a certain amount of noise, and the higher the rounding is applied to the MSB, the more noise is added to the plaintext. For a given implementation of the FFT, the optimization may use the limitations in terms of the error of the ciphertext coefficients introduced by the implementation. Thus, the parameters of the encrypted calculation can be optimized taking into account the FFT error model in addition to the noise and cost model.

[0230] To account for implementation-dependent FFT errors, constraints can be included in the optimization of the parameters of the encrypted computations. This constraint can be represented by an additional set S other (G) that can be realized. The conditions are:

Number

Number

[0231] In general, this approach can be based on a model of the error in the output of the FHE operator in terms of the coefficients of the ciphertext. For example, an FHE operator using an FFT may take as input a ciphertext without error and may output a ciphertext without error.

[0232] Programmable bootstrapping, or more generally, an FHE operator using an FFT may reset the error to a minimum level depending on the parameters of the operator and the input error, for example, may result in a ciphertext that is not error-free or may output the maximum amount of error, for example, the re-randomization of the ciphertext. Rounding may maintain the same amount of error or may cancel the error depending on the parameters of the encrypted computation and the input error.

[0233] The FFT error is based on other ciphers and / or the parameters of the encrypted computation, for example,

Number

[0234] In the above example, noise rounding 870 is applied to the output of programmable bootstrapping, but more generally, noise rounding may be applied to the output of other FHE operations that use an FFT, or more generally, other FHE operations that introduce implementation-dependent noise, and thus it is noted that it contributes to deterministically acting on the encrypted computation with respect to the ciphertext.

[0235] It is also noted that noise rounding 870 may be applied to make the encrypted computation more deterministic, regardless of whether the parameters of the encrypted computation are determined by optimization as described herein. In particular, the inventors consider a cryptographic method of performing an encrypted computation in which a noise rounding operation 870 is applied to the output of an FHE operation that includes implementation-dependent noise such as the noise dependent on the FFT of programmable bootstrapping 840-853, and a corresponding encrypted computing device. The encrypted computation performed by this method and device may use the parameters of the encrypted computation as described herein, but this is not necessary.

[0236] In particular, a cryptographic method of performing an encrypted computation that includes noise rounding may be performed by a distributed ledger, such as a blockchain mining device. In particular, multiple such mining devices may perform the encrypted computation. By using rounding 870, it may be realized that each mining device computes exactly the same ciphertext as the output of the encrypted computation, that is, not only is the plaintext the same, but also the ciphertext encrypting the plaintext is the same. When used in combination with the optimizations described herein, it is still possible for each mining device to use the parameters of each encrypted computation that are optimal for implementation-dependent noise of each system configuration, such as FFT errors. In particular, by using rounding 870, a miner may achieve a consensus regarding the output of the encrypted computation without the need for decryption.

[0237] The following numbered items include intended non-limiting examples:

[0238] 1. A computer-implemented method (900) for determining parameters of an encrypted computation for performing an encrypted computation on a noisy ciphertext, comprising: - accessing data representing a computation graph of the encrypted computation (910); - obtaining a partitioning of the computation graph into a plurality of subgraphs (920), wherein the subgraphs are defined by a type from one or more sets of types and zero or more instantiation parameters of that type (920); - defining respective sets of parameters of the encrypted computation for each type (930); - performing optimization of the parameters of the encrypted computation (940), wherein - the parameters of the encrypted computation are optimized to minimize a computational cost of performing the encrypted computation according to the parameters of the encrypted computation, - the parameters of the encrypted computation are constrained to satisfy a noise constraint with respect to the noise of the ciphertext while performing the encrypted computation, the noise constraint being based on the respective noise constraints of each subgraph, and the noise constraint of a subgraph of a given type being defined by a noise constraint function of the given type that takes as input at least the parameters of the encrypted computation and the instantiation parameters of the subgraph for the given type (940). The method (900) comprising the above.

[0239] 2. - determining that the noise constraint of a first subgraph is at least as strict as the noise constraint of a second subgraph based on the instantiation parameters of the first subgraph and the second subgraph; and - removing the noise constraint of the second subgraph from the optimization. The method (900) of item 1 comprising the above.

[0240] 3. The method (900) of item 2, wherein the first sub-graph and the second sub-graph are parameterized by a noise limit and the 2-norm of the applied linear mapping, the noise limit of the first sub-graph is at most that of the second sub-graph, and the 2-norm of the first sub-graph is at least that of the second sub-graph.

[0241] 4. The computational cost is minimized based on a cost function, the cost function is based on the respective costs of the respective sub-graphs, the cost of a given type of sub-graph takes as input at least the encrypted computation parameters for the given type and is independent of the instantiation parameters, and is defined by a cost function for the given type, the method (900) of any of the preceding items.

[0242] 5. The method (900) of any of the preceding items, wherein the sub-graph represents a sub-computation that results in an output ciphertext with noise independent of the input.

[0243] 6. The method (900) of any of the preceding items, wherein the encrypted computation parameters include one or more of: a decomposition basis of programmable bootstrapping, a decomposition level of programmable bootstrapping, a decomposition basis of key switching, and a decomposition level of key switching.

[0244] 7. The method (900) of any of the preceding items, wherein the sub-graph includes programmable bootstrapping that results in an output ciphertext and noise rounding of the output ciphertext.

[0245] 8. The method (900) of any of the preceding items, wherein the optimization of the encrypted computation parameters is performed by a branch and bound method.

[0246] 9. The parameters of the encrypted computation identify the respective key-switching keys and / or bootstrapping keys used for each subgraph, and if the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph, the key-switching key and / or bootstrapping key for the first subgraph is constrained to add at most as much noise as the key-switching key and / or bootstrapping key for the second subgraph, the method (900) of any of the preceding clauses.

[0247] 10. The parameters of the encrypted computation indicate, for each subgraph to which a respective linear mapping is applied, the respective number of programmable bootstrappings performed during the application of each linear mapping, the method (900) of any of the preceding clauses.

[0248] 11. The method (900) of clause 10 further includes dividing a linear mapping into a respective number of linear mappings corresponding to the number of programmable bootstrappings by minimizing the maximum 2-norm of each linear mapping.

[0249] 12. If the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph, the number of programmable bootstrappings for the first subgraph is constrained to be greater than or equal to the number of programmable bootstrappings for the second subgraph, the method (900) of clause 10 or 11.

[0250] 13. - Converting an unencrypted computational graph into an encrypted computational graph, and / or - Compiling an encrypted computational graph into a set of instructions for an encrypted computing engine, and / or - Executing an encrypted computation according to the determined parameters of the encrypted computation The method (900) of any preceding item, further comprising

[0251] 14. A configuration device (110) for determining parameters of an encrypted calculation for performing an encrypted calculation on a noisy ciphertext, - A storage (130) for storing data representing a calculation graph of the encrypted calculation; - A processor subsystem (140), - Obtaining a division of the calculation graph into a plurality of subgraphs, the subgraphs being defined by a type from one or more types and by zero or more instantiation parameters of that type; - Defining respective sets of parameters of the encrypted calculation for each type; - Optimizing the parameters of the encrypted calculation, the parameters of the encrypted calculation being optimized to minimize the calculation cost of performing the encrypted calculation according to the parameters of the encrypted calculation; the parameters of the encrypted calculation being restricted to satisfy the noise constraints with respect to the noise of the ciphertext while performing the encrypted calculation, the noise constraints being based on the respective noise constraints of each subgraph, and the noise constraint of a subgraph of a given type being defined by a noise constraint function of a given type that takes at least the parameters of the encrypted calculation and the instantiation parameters of the subgraph of the given type as inputs, a processor subsystem (140) A configuration device (110) comprising

[0252] 15. Instructions that cause a processor system to perform the method according to any one of items 1 - 13 when executed by the processor system; and / or a temporary or non - temporary computer - readable storage medium (1000) comprising data (1020) representing the parameters of the encrypted calculation and / or instructions for an encrypted calculation engine determined according to the method of any one of items 1 - 13.

[0253] FIG. 9a schematically shows an example of an embodiment of a computer-implemented method 900 for determining parameters of an encrypted computation for performing an encrypted computation on a noisy ciphertext.

[0254] Method 900 may include accessing data representing a computation graph of the encrypted computation 910.

[0255] Method 900 may include obtaining a partitioning of the computation graph into a plurality of subgraphs 920. The subgraphs may be defined by a type from one or more sets of types and zero or more instantiation parameters of that type.

[0256] Method 900 may include defining respective sets of parameters of the encrypted computation for each type 930.

[0257] Method 900 may include performing optimization of the parameters of the encrypted computation 940. In the optimization, the parameters of the encrypted computation may be optimized to minimize a computational cost of performing the encrypted computation according to the parameters of the encrypted computation. Further, the parameters of the encrypted computation may be constrained to satisfy a noise constraint with respect to the noise of the ciphertext while performing the encrypted computation. The noise constraint may be based on the respective noise constraints of each subgraph. The noise constraint of a subgraph of a given type may be defined by a noise constraint function of the given type that takes as input at least the parameters of the encrypted computation for the given type and the instantiation parameters of the subgraph.

[0258] FIG. 9b schematically shows an example of an embodiment of a cryptographic method 950 for performing an encrypted computation.

[0259] Method 950 may include, as described herein, obtaining 960 encrypted calculation parameters and performing 970 an encrypted calculation according to the obtained encrypted calculation parameters. For example, the encrypted calculation parameters may be incorporated into a set of obtained instructions for an encrypted calculation engine that performs the encrypted calculation (970), or the encrypted calculation parameters 960 may be obtained separately from the representation of the encrypted calculation being performed.

[0260] Instead of or in addition to using encrypted calculation parameters as described herein, method 950 may, for example, apply a noise rounding operation to a ciphertext having implementation-dependent noise, such as the output of programmable bootstrapping, as considered in connection with FIG. 8.

[0261] As will be apparent to those skilled in the art, there can be many different ways of performing methods 900, 950. For example, the steps may be performed in the order shown, but the order of the steps can be changed, or some steps may be performed in parallel. Further, other method steps may be inserted between the steps. The inserted steps may represent an improvement to the method as described herein or may be unrelated to the method. For example, some steps may be performed at least partially in parallel. Further, a given step may not be fully completed before the next step is started. It is also possible to combine methods 900, 950. For example, method 950 for performing an encrypted calculation may be performed according to encrypted calculation parameters determined in advance according to method 900.

[0262] Embodiments of the method may be implemented using software that includes instructions for causing a processor system to perform method 900 or 950. The software may include only those steps performed by certain sub-entities of the system. The software may be stored on a suitable storage medium such as a hard disk, floppy disk, memory, optical disk, etc. The software may be transmitted as a signal, either wired or wirelessly, or using a data network such as the Internet. The software may be made available for download and / or remote use on a server. Embodiments of the method may be implemented using programmable logic, such as a bitstream arranged to configure a field programmable gate array (FPGA), to perform the method.

[0263] It will be understood that the subject matter disclosed herein also extends to a computer program, particularly a computer program configured to implement the subject matter disclosed herein, carried on or in a carrier wave. The program may be in the form of object code, such as source code, object code, intermediate source of the code, and partially compiled forms, or in any other form suitable for use in implementing embodiments of the method. Embodiments relating to a computer program product include computer-executable instructions corresponding to each of at least one processing step of the methods described. These instructions may be subdivided into subroutines and / or stored in one or more files that are statically or dynamically linked. Another embodiment relating to a computer program product includes computer-executable instructions corresponding to each of at least one device, unit, and / or component of the systems and / or products described.

[0264] Typically, the devices described herein, for example, in FIGS. 1a-1c, include one or more microprocessors that execute appropriate software stored in the system; for example, the software may be downloaded and / or stored in a corresponding memory, such as volatile memory like RAM or non-volatile memory like Flash. Alternatively, the system may be implemented in whole or in part as programmable logic, for example, as a field programmable gate array (FPGA). The system may be implemented in whole or in part as a so-called application specific integrated circuit (ASIC), for example, as an integrated circuit (IC) customized for those specific applications. For example, the circuit may be implemented in CMOS using a hardware description language such as Verilog, VHDL, etc. In particular, the system may include a circuit for the evaluation of cryptographic primitives.

[0265] The processor circuit may be distributed and implemented, for example, as a plurality of sub-processor circuits. The storage may be distributed across a plurality of distributed sub-storages. Some or all of the memory may be electronic memory, magnetic memory, etc. For example, the storage may have a volatile part and a non-volatile part. A part of the storage may be read-only.

[0266] FIG. 10 shows a computer-readable medium 1000 having a writable portion 1010. A computer-readable medium 1000 in the form of an optically readable medium is shown. The computer-readable medium 1000 can store data 1020, which may represent instructions that, when executed by a processor system, cause the processor system to perform embodiments of a method for determining encrypted calculation parameters and / or performing encrypted calculations according to the embodiments.

[0267] Alternatively or in addition, the data 1020 may represent encrypted calculation parameters and / or instructions for an encrypted calculation engine determined according to the embodiments.

[0268] Data 1020 may be embodied on computer-readable medium 1000 as physical marks or by magnetization. However, any other suitable embodiments may also be contemplated. Further, although computer-readable medium 1000 is shown here as an optical disk, computer-readable medium 1000 may be any suitable computer-readable medium such as a hard disk, solid-state memory, flash memory, etc., and may be non-recordable or recordable.

[0269] FIG. 11 shows a schematic diagram of a processor system 1140 according to an embodiment of a device for performing encrypted calculations or for determining parameters of encrypted calculations. The processor system includes one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in the figure. Circuit 1110 includes a processing unit 1120, such as a CPU, for executing a computer program component for executing a method according to an embodiment and / or for implementing its modules or units. Circuit 1110 includes a memory 1122 for storing programming code, data, etc. A part of memory 1122 may be read-only. Circuit 1110 may include a communication element 1126, such as an antenna, a connector, or both. Circuit 1110 may include an application-specific integrated circuit 1124 for performing some or all of the processing defined by the method. Processor 1120, memory 1122, application-specific IC 1124, and communication element 1126 may be connected to each other via an interconnect 1130, such as a bus. Processor system 1110 may be configured for contact and / or non-contact communication using an antenna and / or a connector, respectively.

[0270] For example, in an embodiment, a processor system 1140, for example, a device for performing encrypted calculations or compilations, may include a processor circuit and a memory circuit, and the processor is configured to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In an embodiment, the processor circuit may be an ARM Cortex M0. The memory circuit may be a ROM circuit or, for example, a non-volatile memory such as a flash memory. The memory circuit may be a volatile memory, for example, an SRAM memory. In the latter case, the device may include a non-volatile software interface configured to provide software, such as a hard drive, a network interface, etc.

[0271] Device 1110 is shown as including one of each of the described components, but various components may be replicated in various embodiments. For example, processor 1120 may include a plurality of microprocessors configured to independently execute the methods described herein or to perform steps or subroutines of the methods described herein such that multiple processors cooperate to implement the functions described herein. Further, when device 1110 is implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor in a first server and a second processor in a second server.

[0272] Note that the above-described embodiments are not intended to limit the subject matter disclosed herein, but rather to illustrate, and those skilled in the art will be able to design many alternative embodiments.

[0273] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The use of the verb “comprise” and its conjugations does not exclude the presence of elements or steps other than those recited in the claim. The article “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” following a list of elements represent a selection of any one or any subset of the elements from the list. For example, the expression “at least one of A, B, and C” shall be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The subject matter disclosed herein may be implemented by hardware including several distinct elements and by a suitably programmed computer. In the claims of a device enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0274] In the claims, the reference signs in parentheses refer to reference signs in the drawings of the exemplary embodiments or to the formulae of the embodiments and thus enhance the understanding of the claims. These references are not to be construed as limiting the claims.

Claims

1. A computer-implemented method (900) for determining parameters of an encrypted computation for performing an encrypted computation on a noisy ciphertext, comprising: - accessing data representing a computation graph of the encrypted computation (910); - obtaining a partitioning of the computation graph into a plurality of subgraphs (920), wherein a subgraph represents a subcomputation that yields an output ciphertext with noise independent of the input, and is defined by a type from one or more sets and zero or more instantiation parameters of that type (920); - defining respective sets of parameters of the encrypted computation for each type (930); - optimizing the parameters of the encrypted computation (940), wherein: - the parameters of the encrypted computation are optimized to minimize a computational cost of performing the encrypted computation according to the parameters of the encrypted computation; - the parameters of the encrypted computation are constrained to satisfy noise constraints with respect to the noise of the ciphertext while performing the encrypted computation, the noise constraints being based on the respective noise constraints of each subgraph, and the noise constraint of a given type of subgraph being defined by a noise constraint function of the given type that takes as input at least the parameters of the encrypted computation and the instantiation parameters of the subgraph for the given type (940); - determining that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph based on the instantiation parameters of the first subgraph and the second subgraph; - removing the noise constraint of the second subgraph from the optimization; and the method (900).

2. The first subgraph and the second subgraph are parameterized by a noise limit and the 2-norm of the applied linear mapping, the noise limit of the first subgraph being at most that of the second subgraph, and the 2-norm of the first subgraph being at least that of the second subgraph, the method (900) according to claim 1. **Claim 3** The computational cost is minimized based on a cost function, the cost function being based on the respective costs of the respective subgraphs, the cost of a given type of subgraph taking as input at least the parameters of the encrypted computation for the given type and being independent of the instantiation parameters, defined by a cost function for the given type, the method (900) according to claim 1 or 2. **Claim 4** The parameters of the encrypted computation include one or more of a programmable bootstrapping decomposition basis, a programmable bootstrapping decomposition level, a key switching decomposition basis, and a key switching decomposition level, the method (900) according to any one of claims 1 to 3. **Claim 5** The subgraph among the plurality of subgraphs includes programmable bootstrapping that yields an output ciphertext and noise rounding of the output ciphertext, the method (900) according to any one of claims 1 to 4. **Claim 6** The optimization of the parameters of the encrypted computation is performed by a branch and bound method, the method (900) according to any one of claims 1 to 5. **Claim 7** The encrypted computation parameters identify respective key-switching keys and / or bootstrapping keys used for respective subgraphs, and if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the key-switching key and / or bootstrapping key for the first subgraph is constrained to add at most the same amount of noise as the key-switching key and / or bootstrapping key for the second subgraph, the method (900) according to any one of claims 1 to 6.

8. The encrypted computation parameters indicate respective numbers of programmable bootstrapping performed during application of respective linear maps, for respective subgraphs to which respective linear maps are applied, the method (900) according to any one of claims 1 to 7.

9. The method (900) according to claim 8, further comprising dividing each linear map into a respective number of linear maps corresponding to the number of programmable bootstrapping by minimizing the maximum 2-norm of each linear map.

10. If the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the number of programmable bootstrapping for the first subgraph is constrained to be greater than or equal to the number of programmable bootstrapping for the second subgraph, the method (900) according to claim 8 or 9.

11. - Converting the non-encrypted computation graph into an encrypted computation graph, and / or - Compiling the encrypted computation graph into a set of instructions for an encrypted computation engine, and / or - Executing the encrypted computation according to the determined encrypted computation parameters The method (900) according to any one of claims 1 to 10, further comprising.

12. A configuration device (110) for determining parameters of an encrypted calculation for performing an encrypted calculation on a noisy ciphertext, comprising: - A storage (130) for storing data representing a computation graph of the encrypted computation; - A processor subsystem (140), comprising: - Obtaining a division of the computation graph into a plurality of subgraphs, the subgraphs representing sub-computations that result in output ciphertexts with noise independent of the input, defined by a type from one or more sets and zero or more instantiation parameters of that type; - Defining respective sets of parameters of the encrypted computation for each type; - Optimizing the parameters of the encrypted computation such that the parameters of the encrypted computation are optimized to minimize the computational cost of performing the encrypted computation according to the parameters of the encrypted computation, and the parameters of the encrypted computation are constrained to satisfy noise constraints with respect to the noise of the ciphertext while performing the encrypted computation, the noise constraints being based on the respective noise constraints of each subgraph, and the noise constraint of a given type of subgraph being defined by a noise constraint function of the given type that takes as input at least the parameters of the encrypted computation and the instantiation parameters of the subgraph for the given type; - Determining that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph based on the instantiation parameters of the first subgraph and the second subgraph; - Removing the noise constraint of the second subgraph from the optimization; A processor subsystem (140) configured as such; A configuration device (110) comprising the same.

13. Instructions that cause a processor system to perform the method according to any one of claims 1 to 11 when executed by the processor system, and / or data (1020) representing encrypted calculation parameters and / or instructions for an encrypted calculation engine determined according to the method according to any one of claims 1 to 11, a temporary or non-temporary computer-readable storage medium (1000).

Images