Optimizing the parameters of encrypted calculations

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 for determining parameters of an encrypted computation, a corresponding device, and a computer-readable medium. [Background technology]

[0002] Homomorphic encryption allows a person to perform encrypted computations, e.g., circuit evaluation, performed on data that has been encrypted by a party and that the party cannot decrypt. For example, input data and computation results may be received and returned in encrypted form. Intermediate data, e.g., the internal state of a computation, may also be in encrypted form.

[0003] Although the computational results are returned in encrypted form, when decrypted the output is expected to be the same or very close to what would have been obtained if the operation had been performed on unencrypted data. Homomorphic encryption can be used for privacy-preserving outsourced storage and computation. It allows data to be encrypted and outsourced to a cloud environment for processing and / or storage, all while remaining encrypted.

[0004] For example, homomorphic encryption may find application in areas such as healthcare, where privacy regulations may make it difficult to share plain data, but computations on encrypted medical data may be permissible. For example, a medical model developed to classify medical data may be configured to receive the medical data in encrypted form from a third party, e.g., a hospital. The medical model may, for example, classify the medical data as, for example, normal or abnormal, or as having a particular medical syndrome, disease, or other disorder. Using homomorphic encryption, the medical model may be applied to the medical data received in encrypted form. This means that the party providing the medical model does not have access to the plain medical data that corresponds to the encrypted medical data. Users of the service can decrypt the results of the medical model application.

[0005] In particular, homomorphic encryption techniques exist that can, at least in principle, be used to compute arbitrary functions on encrypted data. Such techniques are called "fully homomorphic encryption" (FHE) techniques.

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

[0007] When a data item is just encrypted, there is little noise—the encryption is fresh. For example, the amount of noise is so small that if the data item were to be decrypted, the noise could be removed at some point in the decryption process, for example, by rounding. On the other hand, the noise should be large enough to make attacks on the system sufficiently difficult. For example, assuming no noise, many homomorphic encryption schemes can be attacked with linear algebra or other efficient algorithms, such as lattice reduction algorithms. Noise is added when the data item is encrypted, and the noise is chosen so that homomorphic operations can still be performed and decryption is still possible but difficult to attack.

[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 such that unique decryption is no longer possible. It is commonly known to use a technique called bootstrapping to reduce noise in homomorphically encrypted values. Bootstrapping may use a public key called a bootstrapping key. By using bootstrapping to reduce 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 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), Lecture Notes in Computer Science, volume 12716, pp. 1-19, Springer, 2021 (incorporated herein by reference). TFHE-like schemes differentiate themselves from other FHE schemes by supporting relatively highly efficient techniques for bootstrapping; further, they allow for concurrent function evaluation during the bootstrapping operation, referred to as programmable bootstrapping. Regular bootstrapping corresponds to programmable bootstrapping with an identity function.

[0010] Interestingly, the output of programmable bootstrapping has an amount of noise that is independent of the noise of the input ciphertext. Thus, by performing programmable bootstrapping, the noise of the input ciphertext can be reduced by a fixed amount, possibly while simultaneously applying a function to the input ciphertext. By performing programmable bootstrapping at the appropriate time, encrypted calculations of unlimited multiplicative complexity can be performed.

[0011] The techniques of encrypted computation, and in particular the operation of TFHE-like schemes, are influenced by various encrypted computation parameters, including various parameters of the encryption scheme itself, such as the number and modulus of mask values ​​used for LWE, and parameters that affect the particular encrypted computation, such as the decomposition level used in the programmable bootstrap computation.

[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 greater the number of mask values, the more difficult it is to break the encryption scheme); the precision of the result of the computation (e.g., the size of the polynomial affects the number of bits of precision with which the computation can be performed); and the computational and storage requirements for performing the computation (e.g., the decomposition level and LWE parameters of programmable bootstrapping affect the size of the bootstrapping key and the computational complexity of performing this operation).

[0013] This means that the choice of parameters involves various trade-offs. For example, to reduce the minimum noise while maintaining security, some other parameters of the encryption scheme, such as the size of the polynomial and / or the dimension of the GLWE, may be increased. At the same time, the cost of the operators of the various encrypted calculations depends on the size of the polynomial and / or the dimension of the GLWE, leading to a trade-off between noise and cost: using little noise is desirable to ensure the correctness of the calculation, but at the same time, using little noise increases the computational cost, since other parameters must be increased. [Prior art documents] [Non-patent literature]

[0014] [Non-Patent Document 1] I. Chilotti et al., “Programmable bootstrapping enables efficient homomorphic inference of deep neural networks,” Cyber ​​Security Cryptography and Machine Learning (CSCML 2021), Lecture Notes in Computer Science, volume 12716, pp. 1-19, Springer, 2021. [Non-patent document 2] M. Albrecht et al., “On the concrete hardness of Learning with Errors,” Journal of Mathematical Cryptology, 9(3):169-203, 2015. [Non-patent document 3] R. Rothblum, "Homomorphic encryption: From private-key to public-key," Theory of Cryptography (TCC 2011), volume 6597 of Lecture Notes in Computer Science, pp. 219-234, Springer, 2011. [Non-patent document 4] [DM15] L. Ducas et al. “FHEW: bootstrapping homomorphic encryption in less than a second”, proceedings EUROCRYPT 2015 [Non-patent document 5] [CGGI16] I. Chilotti et al., “Faster fully homomorphic encryption:Bootstrapping in less than 0.1 seconds”, proceedings ASIACRYPT 2016 [Non-patent document 6] [CGGI17] I. Chilotti et al., “Faster packed homomorphic operations and efficient circuit bootstrapping for TFHE”, proceedings ASIACRYPT 2017 [Non-Patent Document 7] C. Boura et al., “CHIMERA:Combining Ring-LWE-based Fully Homomorphic Encryption Schemes”, J.Math.Cryptol., 14(1):316-338, 2020. [Non-patent document 8] J. Fan and F. Vercauteren, “Somewhat Practical Fully Homomorphic Encryption”, http: / / eprint.iacr.org / 2012 / 144 [Non-Patent Document 9] Jung Hee Cheon et al., “Homomorphic Encryption for Arithmetic of Approximate Numbers”, proceedings ASIACRYPT 2017 [Non-Patent Document 10] I. Chilotti et al., “Improved programmable bootstrapping with larger precision and efficient arithmetic circuits for TFHE,” proceedings ASIACRYPT 2021 [Non-Patent Document 11] Z. Liu et al. “Large-precision homomorphic sign evaluation using FHEW / TFHE bootstrapping”, Cryptology ePrint Archive 2021 / 1337 [Non-Patent Document 12] M.Joye, “Balanced non-adjacent forms”, proceedings ASIACRYPT 2021 Summary of the Invention [Problem to be solved by the invention]

[0015] It is therefore desirable to provide an automated technique for determining appropriate values ​​for encrypted computation parameters for performing a given encrypted computation. [Means for solving the problem]

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

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

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

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

[0020] The inventors have considered using this type of recurring pattern to efficiently optimize the parameters of encrypted computations. That is, they have considered performing optimizations based on dividing the computation graph into subgraphs according to the recurring patterns. Accordingly, a subgraph is defined by a type from a set of one or more types that corresponds to the pattern the subgraph follows; and zero or more instantiation 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 the two-norm of the coefficients, which often provides sufficient information for optimization).

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

[0022] Interestingly, security and accuracy requirements may be expressed in terms of a subdivision of the computation graph into subgraphs with respective types and instantiation parameters. That is, the optimization may constrain the parameters of the encrypted computation to satisfy a noise constraint on the noise of the ciphertext computed while performing 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 the particular subgraph. Thus, the overall noise constraint may include the respective constraints of each subgraph given by the noise constraint function.

[0023] Interestingly, defining noise constraints in terms of noise constraint functions for each subgraph type allows optimization to be performed efficiently. Expressing the optimization problem in terms of subgraphs instead of individual encrypted operations significantly reduces the size of the constraint satisfaction problem to be solved. Furthermore, by using noise constraint functions, the optimization problem is expressed in terms of multiple instantiations of the same constraint function to be satisfied. This formulation makes the optimization easier to perform, especially since it allows constraints that are subordinate to other constraints to be eliminated, either explicitly or automatically by the optimizer used.

[0024] The noise constraints can explicitly constrain the noise of the ciphertexts, for example by specifying that the noise of each ciphertext be below a respective limit, but can also be implicitly constrained by the parameters of the encryption scheme used, in particular the product of the dimension of the GLWE and the size of the polynomial, which, as known per se, is inversely proportional to the noise at a given level of security. By enforcing that the noise of each ciphertext be greater than the minimum noise required to achieve a particular level of security 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 the 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 in terms of type and instantiation parameters, since for a given type, it may be determined based on the instantiation parameters 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. In some cases, such a determination may also be made for subgraphs of different types, as shown in the examples provided 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, making it much more efficient to solve.

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

[0027] For example, the subgraph represented by these parameters may include: application of a linear map, key switching; modulus switching; and blind rotation and sampling. This is a common pattern in encrypted computations, and in fact, in some cases the entire encrypted computation may consist of instantiations of subgraphs of this type.

[0028] In such cases, it can be particularly efficiently determined that a subgraph has a stricter noise constraint than another subgraph. That is, this may be the case if the noise limit of a first subgraph is at most the noise limit of a second subgraph (in combination with conditions on other parameters, if any), and if the 2-norm of the first subgraph is at least the 2-norm of the second subgraph. This allows for a significant reduction in the number of required constraints. In particular, the noise limit may be represented by a discrete parameter. This discrete parameter 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 kept, and the remaining subgraphs are 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, therefore, the complexity of satisfying at least this type of subgraph noise constraint can be made independent of the size of the computation, resulting in efficient improvements, especially 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 the encrypted computation.

[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 respective costs of each subgraph, with the cost of a subgraph of a given type being defined by a cost function for the given type. This cost function may take as input at least the parameters of the encrypted computation for the given type. Using a cost function instead of simulation or measurement significantly increases the efficiency of optimization, not only because such functions can be evaluated much more efficiently than performing simulations or measurements, but also because it allows optimization techniques that rely on having a functional expression to be used, such as branch-and-bound using lower and upper bounds based on the functional expression; optimization based on changing variables; or elimination of non-optimal solutions based on the arguments of the functional expression.

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

[0032] In embodiments, a subgraph may represent a subcomputation that results in an output ciphertext with input-independent noise, i.e., noise that does not depend on the noise of the subgraph's input ciphertext or on the number of, e.g., linear operations, applied to the input ciphertext in the subgraph. Such an output ciphertext may then be used as an input for a further subgraph. This simplifies the optimization problem because it allows the noise constraint of a subgraph to be defined independently of the specific amount of noise of the inputs; in other words, input noise need not be an instantiation parameter. In particular, all inputs to a subgraph throughout a computation, or at least all inputs to a subgraph of a given type, 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 be particularly useful for eliminating noise constraints that are less stringent than other noise constraints.

[0033] In particular, a subgraph may have a final portion that results in an output ciphertext with input-independent noise: typically a blind rotation and sampling, optionally followed by rounding, as discussed in more detail elsewhere. Apart from this final portion, the subgraph typically does not contain any cryptographic operations that result in input-independent noise. In particular, the noise may monotonically increase within the subgraph until the final portion is reached. This again simplifies the optimization problem, since it may be sufficient to determine the noise of the input to the final portion that is the noisiest during the subcomputation and constrain this noise, e.g., to provide sufficient precision.

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

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

[0036] In an embodiment, a subgraph may include programmable bootstrapping, which results in 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, noise rounding may achieve that programmable bootstrapping is deterministic, in particular in the sense that it is independent of the specific implementation of the Fast Fourier Transform (FFT) used in the programmable bootstrapping.

[0037] Indeed, the inventors have observed that, without rounding, at least some of the least significant bits of the ciphertext, which represent noise in the ciphertext, typically depend on the rounding errors of the FFT implementation used. While such rounding errors may not affect the security or correctness of the encrypted computation itself, it may still be desirable for the computation to be deterministic. For example, a deterministic computation makes it possible to have the same encrypted computation performed by different parties, possibly using different software and / or hardware configurations, and check whether the resulting ciphertext is the same, thus providing some assurance that the correct computation was performed.

[0038] In particular, in embodiments, the encrypted calculation may be performed by a miner device of the blockchain, and rounding allows the results of the encrypted calculation determined by multiple miner devices to be compared to each other without the need for decryption. In this way, it may be possible to reach a consensus on the encrypted output of the calculation and, accordingly, to prove that the intended encrypted calculation was actually performed.

[0039] In embodiments, optimization of the parameters of the encrypted calculation may be performed by a branch and bound method, which may allow optimization to be performed significantly more efficiently than brute force, while at the same time ensuring that the best possible values ​​of the parameters of the encrypted calculation are obtained.

[0040] In embodiments, optimization may be used to determine the key switching keys and / or bootstrapping keys to be used for each subgraph. A predefined number of key switching keys and / or bootstrapping keys may be used. Each key may add a different amount of noise and may have a different computational cost. Adding less noise may be more computationally expensive, resulting in a trade-off to be made. For a given subgraph, parameters of the encrypted computation may identify which of the predefined key switching keys and / or bootstrapping keys should be used in the subgraph. In this way, a respective optimal selection may be made for each subgraph, 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 the given subgraph were predefined.

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

[0042] In an embodiment, the encrypted computation parameters may indicate the respective number of programmable bootstrappings performed during the application of each linear map for each subgraph to which the respective linear map is applied. By performing programmable bootstrapping during the application of the linear map, noise may be reduced at the expense of incurring significant computational cost. By making the number of bootstrappings a parameter that can be optimized, an optimal choice can be made regarding this tradeoff as well.

[0043] In an embodiment, when at least one programmable bootstrapping is to be performed on a linear map, it may be automatically determined how to split the linear map into multiple linear maps. As the inventors have realized, this can be done by minimizing the maximum 2-norm of each linear map. This is advantageous because it minimizes the noise after each linear map and makes it easier to satisfy the noise constraint.

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

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

[0046] In general, the encrypted computations may be performed in a TFHE setting. This means that the ciphertext used to encrypt the values ​​allows for programmable bootstrapping operations. In particular, the ciphertext may be LWE (Learning With Errors) encryption, i.e., encryption based on the cryptographic assumption that the Learning With Errors problem is hard. As known per se, programmable bootstrapping may, for example, evaluate LWE decryption with the exponent of a GLWE-encrypted monomial implemented as a so-called blind rotation. In particular, programmable bootstrapping may involve calculating an encrypted polynomial product of a bootstrapping monomial, which represents the plaintext value as an exponent, with 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 allows for programmable bootstrapping but does not allow for decryption of the ciphertext.

[0047] The provided techniques for improved computation on encrypted data can be applied to a wide range of practical applications. Such practical applications include encrypted evaluation of software programs without access to the plain data. For example, medical diagnostic software may be evaluated against medical data without actually having access to the medical data. The medical data may include medical images. The medical images may include, for example, multidimensional image data, e.g., two-dimensional (2D), three-dimensional (3D), or four-dimensional (4D) images, 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).

[0048] In embodiments, the provided techniques may be used to evaluate neural networks against encrypted inputs. Parties evaluating the neural network may or may not have cleartext access to the neural network's trained parameters, e.g., weights and biases. In general, the techniques provided herein, e.g., improved encrypted computational parameters, improve the efficiency of neural network evaluation and / or reduce the storage and transmission requirements of the ciphertext or key material used.

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

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

[0051] Further details, aspects, and embodiments will now be described, by way of example only, with reference to the drawings, in which elements are illustrated for simplicity and clarity and are not necessarily drawn to scale, and in which elements corresponding to elements already described may have the same reference numerals. [Brief explanation of the drawings]

[0052] [Figure 1a]1A and 1B are schematic diagrams illustrating examples of embodiments of configuration devices. [Figure 1b] FIG. 1 is a schematic diagram illustrating an example embodiment of an encryption computing device. [Figure 1c] 1 is a diagram illustrating an example embodiment of a cryptographic computing system. [Figure 2] FIG. 10 shows a detailed example of how the parameters should be determined. [Figure 3] FIG. 10 shows a detailed example of constraints on noise in ciphertext. [Figure 4a] FIG. 10 illustrates detailed examples of subgraph types. [Figure 4b] FIG. 10 is a diagram showing a detailed example of noise in a ciphertext. [Figure 4c] FIG. 10 is a diagram showing a detailed example of encrypted calculation parameters. [Figure 5] FIG. 10 illustrates a detailed example of removing noise constraints. [Figure 6a] FIG. 10 illustrates detailed examples of subgraph types. [Figure 6b] FIG. 10 illustrates detailed examples of subgraph types. [Figure 7a] FIG. 10 illustrates a detailed, but non-limiting, example of determining the key switching and / or bootstrapping keys used. [Figure 7b] FIG. 10 illustrates a detailed example of determining the number of programmable bootstrappings. [Figure 8] FIG. 10 shows a detailed example of programmable bootstrapping with noise rounding. [Figure 9a] FIG. 1 illustrates a schematic example of an embodiment of a method for determining parameters of an encrypted calculation. [Figure 9b] FIG. 1 illustrates a schematic example of an embodiment of a cryptographic method for performing encrypted calculations. [Figure 10] 1 is a diagram illustrating a computer-readable medium having a writable portion according to an embodiment; [Figure 11] FIG. 1 is a diagram illustrating a processor system according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0053] While the subject matter disclosed herein is susceptible to embodiment in many different forms, one or more specific embodiments are shown in the drawings and described in detail herein, with the understanding that the present disclosure is to be considered as an example of the principles of the subject matter disclosed herein and is not intended to limit the subject matter disclosed herein to the specific embodiments shown and described.

[0054] In the following, elements of an operational embodiment are described for the sake of understanding, but 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 the embodiments only, but also includes any other combination of features described herein or recited in mutually different dependent claims.

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

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

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

[0059] In particular, the private 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 GLWE dimension k and the polynomial size N; the amount of noise in the fresh ciphertext; and the modulus q. Given these parameters, it is known per se how to estimate the degree of security provided; 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] It may be noted that there is a connection between the dimension k of the GLWE, the size N of the polynomial, and the standard deviation σ of the Gaussian noise (e.g., minimum noise for a given number of bits of security), so one of these variables can be calculated from the others. In particular, throughout this specification, given a particular distribution of the private key (e.g., binary, ternary, or Gaussian); the product k·N; and a level of security λ, the minimum noise of the fresh ciphertext to achieve that level of security may be calculated, i.e.,

number

[0062] It is noted that although the integer q is used throughout this specification to represent the modulus of a ciphertext, multiple ciphertext moduli may be used in an encrypted multiplication, e.g., using modulus switching to align ciphertexts under the same q when needed.

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

[0064] Various embodiments operate in a TFHE setting, i.e., ciphertexts that support programmable bootstrapping (PBS) are used. Programmable bootstrapping may take a ciphertext as input and output a ciphertext of the same message with noise that is independent of the input, or a function and / or lookup table of that message. PBS may involve evaluating homomorphic decryption of the input ciphertext at the exponent of a polynomial. Examples of encryption schemes in a 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. Chilotti et al., "Faster fully homomorphic encryption: Bootstrapping in less than 0.1 seconds", proceedings ASIACRYPT 2016, - [CGGI17] I. Chilotti et al., “Faster packed homomorphic operations and efficient circuit bootstrapping for TFHE”, proceedings ASIACRYPT 2017.

[0065] Throughout this document, plaintexts may be represented as integers modulo the modulus q. Such values ​​modulo integers may be considered equivalently as elements of a discretized torus, as is done in some of the references mentioned above. In particular, various publications have proposed the use of a real torus

number

number

number

number

number

[0066] The programmable bootstrapping operations of TFHE-like schemes make them attractive options for a wide range of applications. Bootstrapping is relatively efficient compared to many other FHE schemes, making it much more feasible to perform relatively complex calculations, e.g., with a multiplicative depth of at least 10, at least 50, or at least 100. In particular, cryptographic parameters for TFHE-like schemes can be selected based on the desired accuracy and resulting computational cost, without necessarily requiring a large amount of homomorphic operations and circuit depth. In contrast, bootstrapping in other FHE schemes is highly inefficient, so in practice, these schemes are typically applied in a levelled manner, i.e., their parameters are selected depending on a given computation so that the given computation can be performed without the need for bootstrapping. However, such a levelled approach is infeasible for more complex computations, and thus, TFHE-like schemes are particularly beneficial in such cases.

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

[0068] In particular, LWE-based ciphertexts and / or GLWE-based ciphertexts used in the TFHE settings herein 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., depending on desired accuracy and / or efficiency. The parameters N, k, and / or σ may be predefined or may be the output of 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, where such values ​​significantly limit the computations that can be performed; instead, in non-TFHE-like schemes, q and N are typically both selected based on the level of security desired, such that q can be much larger.

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

number

number

number

[0070] The standard scores may be applied to the confidence intervals of a central normal distribution as follows:

number

number

number

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

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

[0073] The device 110 may communicate internally with other devices, external storage, input devices, output devices, and / or one or more sensors via a computer network. 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, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G, or 5G antenna. Communications, e.g., internal communications, may use other communication protocols or media, e.g., 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 a computation performed in encrypted form. For example, device 110 may obtain data representing a computation graph of an unencrypted or encrypted computation, the latter optionally being divided into subgraphs as previously described herein when received. Device 110 may determine encrypted computation parameters for optimally performing this computation in encrypted form. Device 110 may transmit data representing the encrypted computation parameters, in particular, instructions for an encryption computation engine to perform the computation in encrypted form according to the determined encrypted computation parameters.

[0075] Execution of device 110 may be implemented in processor system 130, e.g., one or more processor circuits, e.g., microprocessors, examples of which are provided 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 computation parameters for each type. The processor subsystem 130 may further be configured to perform an optimization of the encrypted computation parameters, including the respective sets of encrypted computation parameters for each type. In this optimization, the encrypted computation parameters may be optimized to minimize the computational cost of performing the encrypted computation according to the encrypted computation parameters. Furthermore, in this optimization, the encrypted computation parameters may be constrained to satisfy a noise constraint on the noise of the ciphertext while performing the encrypted computation. The noise constraint may be based on a respective noise constraint for each subgraph. The noise constraint for a subgraph of a given type may be defined by a noise constraint function for the given type that takes as input at least the encrypted computation parameters for the given type and the subgraph instantiation parameters.

[0077] Some of the diagrams illustrate functional units that may be functional units of a processor system. For example, the diagrams may be used as blueprints for possible functional organizations of a processor system. Processor circuitry is not shown separately from the units in most of the diagrams. For example, the functional units illustrated in Figures 2-6 (see below) may be implemented in whole or in part by a device such as device 110, e.g., computer instructions stored in electronic memory of device 110 and executable by a microprocessor of device 110. In hybrid embodiments, the functional units are implemented partially in hardware, e.g., as a coprocessor, e.g., an arithmetic coprocessor and / or a cryptographic coprocessor, and partially in software stored and executed on device 110.

[0078] 1b schematically illustrates an example embodiment of an encryption computing device 119. The encryption computing device 119 may be for performing an encrypted computation. The encrypted computation may use homomorphic encryption. For example, the device 119 may be used to perform the encrypted computation; for example, the device may perform the computation even if the data is received in encrypted form, e.g., from a data provider, and even if the device 119 is unable to decrypt the data. The computation is performed according to encrypted computation parameters determined as described herein, e.g., by the device 110 of FIG. 1a. The device 119 may determine the parameters itself; for example, the device 119 may be combined with the device 110 of FIG. 1a.

[0079] Device 119 may include processor system 139, storage 149, and communication interface 159. Processor system 139, storage 149, and communication interface 159 may be implemented as discussed for each component in FIG. 1a. Storage 149 may be for storing a representation of an encrypted computation to be performed and / or encrypted computation parameters according to which the encrypted computation is to be performed. Thus, device 119 may include storage 149 that stores encrypted computation parameters. The encrypted computation parameters may be included in the representation of the encrypted computation.

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

[0081] The communications interface 159 may be used to receive a representation of the encrypted computation to be performed and / or parameters of the encrypted computation according to which the computation should be performed. The communications interface 159 may be further configured to receive encrypted data on which to perform the computation. The communications interface 159 may further be used to transmit an encrypted output resulting from the encrypted computation.

[0082] The processor subsystem 139 may be configured to perform the encrypted calculations. This may be done as known per se in the art. Interestingly, because the processor subsystem 139 uses the parameters of the encrypted calculations as described herein, improved encrypted calculations may be performed, for example, with improved computational efficiency, as discussed throughout this specification.

[0083] Instead of or in addition to using the parameters of the encrypted calculation as described herein, the processor subsystem 139 may apply a noise rounding operation to the ciphertext with implementation-dependent noise, e.g., the output of programmable bootstrapping, as discussed in connection with FIG. 8.

[0084] 1c illustrates schematically an example embodiment of an encrypted computation system 100. System 100 is configured to perform encrypted computations using homomorphic encryption, for example, fully homomorphic encryption.

[0085] The system 100 of this example includes a compiler device 111, a data provider device 113, and an encryption computing device 112. The compiler device 111 may be combined with the encryption computing device 112 or the data provider device 113 in a single device. 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 a homomorphic executable for performing the encrypted computation from the compiler device 111.

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

[0087] Interestingly, device 112 may perform the encrypted computation according to the parameters of the encrypted computation determined as described herein. For example, the parameters of the encrypted computation may be determined by compiler device 111, and the homomorphic executable may be according to the parameters of the encrypted computation. 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. It is also possible in principle for the determination of the parameters of the encrypted computation to be performed by device 112 or device 113 or a different device, in which 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 cryptographic computing device 112 to perform encrypted calculations, including, for example, a bootstrapping key for performing programmable bootstrapping as discussed herein. The device that generates the key material may provide bootstrapping key 151 to device 112, for example, by transmitting bootstrapping key 151 over computer network 150, uploading bootstrapping key 151 to shared storage, etc. The key material may also be generated by a separate key generation device (not shown in this figure).

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

[0090] Homomorphic encryption schemes may be applied in many settings. For example, the encrypting computing device 112 may be operated by a cloud provider. The cloud provider may provide computational and storage services to clients. By employing homomorphic encryption, a data provider device 113, e.g., a client of the cloud provider, may transmit the client's data in encrypted form. The cloud provider may still perform the required computation and / or required storage, but may not know the correspondence to the plain data. For example, the data provider device 113 may use an encryption key type that corresponds to the particular homomorphic encryption system used to encrypt the data item. When the computation result is received by the data provider 113 from the encrypting computing device 112, a corresponding decryption key may be used to decrypt the encrypted data item. The encryption key and decryption key may—and typically are—the same.

[0091] For example, the cryptographic computing system 100 may be configured to train a machine learning model, e.g., an image classifier, e.g., a medical model, even though the cryptographic computing device does not have access to the plain data items. 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 that owns the decryption key. This allows multiple providers of medical data to pool their data by sending it to a cloud provider, which then returns the model parameters even though it does not have access to the plain data. The encryption key may be equal to the decryption key.

[0092] After the model is trained, the encrypted computing system 100 may be used to provide the model for use with, for example, medical data. This can be done with plain model parameters or encrypted model parameters—in either case using encrypted data, e.g., encrypted input data, intermediate data, and output data. Using plain model parameters is typically much more efficient. In either case, the effect of the system is that computations, e.g., image classification, e.g., medical image classification, are performed without the computer knowing the plain data items. For example, a mammogram may be evaluated for cancer without the image even existing in the plain on the encryption computing device 112, and without the encryption computing device 112, or any cooperation of such devices, knowing what the results of the cancer evaluation were. From a privacy perspective, it may be acceptable to operate a plain model on encrypted privacy-related data, but not on plain privacy-related data.

[0093] Other uses include, for example, a database service that searches encrypted data in an encrypted database; for example, the calculation may be a comparison between an input item and a database item. For example, multiple calculations may be combined to create a database index that matches the index. For example, the database may be a genome database, and the input may be a gene sequence. For example, the system 100 may be used for secured control of devices. For example, a device, even a large-scale device such as a power plant, may send sensor values ​​to the encryption computing device 112 and receive encrypted control signals in return. The control signals are computed from the sensor signals. An attacker of the system may be able to determine the content of data going to and coming from one or more encryption computing devices 112, or even access intermediate data from these devices, but the attacker would not be aided by this because the data is encrypted. Even a complete breach of all encryption computing devices 112 in the system 100 would not reveal the data because the decryption key is unknown to these devices. Computing the control signal may involve mathematical operations such as linear algebra, averaging, matrix multiplication, and polynomial evaluation, all of which can be performed by homomorphic encryption operations.

[0094] For example, a pool of encrypted data items may be maintained in a cryptographic computing system; a subset of these may be received, and another subset may be the results, e.g., intermediate results, of the encrypted computation. For example, the cryptographic computing device 112 may be configured to apply a homomorphic encryption operation to one, two, or more encrypted data items in a pool, e.g., a collection of input values ​​and / or intermediate values ​​and / or output values. The result may be a new encrypted data item that may be stored in the pool. The pool may be stored in the cryptographic computing system's storage, which may be local storage or distributed storage. In the latter case, it may occur that one or more encrypted data items are represented multiple times in the pool. Encrypted data items may be transmitted from one computing device to another, e.g., if their values ​​are needed elsewhere. The pool may be implemented in various ways, e.g., as a register file, an array, various data structures, etc.

[0095] An encrypted data item may represent any kind of data. For example, an encrypted data item may represent numbers that need to be averaged or used in linear regression, etc. For example, an encrypted data item may represent an image. For example, each pixel of the image may correspond to one or more encrypted data items. For example, a grayscale pixel may be represented by a gray level, which may be represented by a single encrypted data item. For example, 256 gray levels may be encoded into a single encrypted data item. For example, a color pixel may be represented as multiple color levels, e.g., RGB levels, which may be represented by a tuple of encrypted data items. For example, three 256-level colors may be encrypted as respective encrypted values.

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

[0097] FIG. 2 shows a detailed, but non-limiting, example of how to determine the parameters of an encrypted computation for performing an encrypted computation on 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 executable code, as a list of instructions, etc. The encrypted computation graph ECG may be a directed acyclic graph of encrypted operations, also referred to as "FHE operators." An encrypted operation may take one or more ciphertexts and / or plaintexts as inputs and may provide one or more ciphertexts as outputs.

[0099] In the following, G is used to denote the FHE graph ECG constructed from FHE operators. Mathematically, G = (V, E) is a graph of the FHE operators {O i} i∈I where V={O i} i∈Iis the set of vertices that are FHE operators; E is the set of edges in G. For ease of exposition, if the set of edges E is not required, a graph may be identified with its set of vertices, and G=V.

[0100] For example, an FHE operator may represent homomorphic addition (of ciphertext and / or plaintext), homomorphic multiplication with a plain value, key switching, modulus switching, blind rotation, sampling, etc. In various examples, for simplicity, blind rotation and sampling 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 performing a compilation COMP 220 that takes the unencrypted computation graph PROG 210 as input and transforms the graph into an encrypted computation graph ECG. The compilation COMP may operate on a graph PROG of plain operators. By using the provided techniques, this graph PROG can be transformed into a corresponding graph ECG of FHE operators with the correct optimized set of parameters ECP 280.

[0102] In the graph PROG, plain operators may be operators that operate on data marked as confidential and / or data marked as plain data and output 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 the following: Addition of sensitive data; Adding sensitive data to plain data; Multiplication of secret data; Multiplication of the secret data with the plain data; and Application of unary functions.

[0103] The compilation COMP may map a plain operator to a respective set of one or more FHE operators. Both the plain operator and the set of FHE operators may compute the same operation, the former operating on plain data and secret data, and the latter operating on plaintext and ciphertext. For this, techniques known per se in the art may be used. Interestingly, for the resulting graph ECG, the techniques described herein may be used to find the parameters of the best encrypted computation.

[0104] In the division operation DIV, a computation graph G, ECG, is divided into multiple subgraphs {G i}. A subgraph may be defined by a type from a set of one or more types and zero or more instantiation parameters for 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 Figure 4a and elsewhere, several additions and scalar multiplications together may be considered as a single FHE operator representing a linear mapping. In this case, when a subgraph contains a linear mapping, the linear mapping applied (or its 2-norm, which is sufficient for various optimizations) may be, for example, one of the instantiation parameters. The type of a subgraph is also called an atomic pattern (AP) species.

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

[0106] In particular, a subgraph may represent a sub-computation that results in an output ciphertext with input-independent noise. For example, the output ciphertext can be the output of programmable bootstrapping, or of rounding the output of programmable bootstrapping. Thus, a division operation DIV may operate on the encryption computation graph ECG by dividing the graph into subgraphs at the output of each set of operations that result in input-independent noise, e.g., at each instance where blind rotate+sample extract, or blind rotate+sample extract+round, is applied.

[0107] By way of example, the diagram shows an encrypted computation graph ECG that includes 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 division DIV results in a representation REP 250 of the encrypted computation graph with instantiation parameters IP-S1 251; IP-S3 253 for instantiating the first type T1 to obtain the respective subgraphs S1, S3, and IP-S2 252 for instantiating the second type T2 to obtain the respective subgraphs S2.

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

[0109] In general, the way in which the FHE computation of the encrypted computation graph ECG is performed may depend on the values ​​of a 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 parameters of the encryption scheme used, such as, for example, the dimension k of GLWE and / or the size N of the polynomials and / or their product k·N. The number of global parameters can be, for example, at most or at least two, or at most or at least five.

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

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

[0113] The subgraph-specific parameters ECP-Si do not usually provide values ​​for cryptographic parameters such as the decomposition base or level: these are usually defined as type-specific encrypted computation parameters EPCi, or even global encrypted computation parameters ECPG. This improves the efficiency of the optimization and also limits the number of different values ​​such parameters can have, thereby limiting, for example, the number of different key-switching and bootstrapping keys needed to perform the encrypted computation.

[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 a value of the encrypted computation parameter ECP that minimizes the computational cost Cost(G,x) of performing the encrypted computation G according to the encrypted computation parameter x, while ensuring a desired level of security and correctness of the computation result (up to a given probability).

[0115] Optimization OPT can ensure security and correctness by constraining the parameters of the encrypted computation to satisfy noise constraints on the noise of the resulting ciphertext while the encrypted computation is being performed. An example of defining such noise bounds is discussed in connection with FIG. 3.

[0116] In particular, the noise bound may ensure a desired level of security by setting the noise of the ciphertext of the fresh encryption based on the security parameters of the encryption scheme such that the desired level of security is provided. In particular, as discussed elsewhere, given a level of security λ and encryption parameters k·N contained in, for example, a global parameter EPG, the noise of the fresh ciphertext may be determined by a mapping defined such that the fresh ciphertext contains enough noise to hide the plaintext.

number

[0117] With regard to the correctness of the computation result, it is noted that if the noise in the ciphertext becomes greater than a threshold, decryption no longer returns the correct plaintext with sufficient probability. This threshold for the amount of noise in the ciphertext may be referred to as the noise limit. The noise limit may be global or may vary between portions of the computation depending on the desired accuracy at that point in the computation, in which case it may be defined, for example, based on the instantiation parameters IP-Si of the subgraph. The noise limit may be manually specified or 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 that OPT seeks to solve can be defined as follows: For a parameter x of a given encrypted computation, a corresponding set of possible values ​​is defined, and E x and is sometimes called the search space of x. The search space is usually discrete. The Cartesian product of the search space is E Gand may be referred to as the search space of the encrypted computation graph G. In this specification, graph G may be abbreviated for brevity such that the search space of the encrypted computation graph is denoted as E.

[0119] In general, some solutions in the search space will generate too much noise. A noise feasible set is defined as a set of encrypted computation parameters ECP that satisfy the noise constraint, e.g.,

number

number

[0120] In addition to the noise constraint, there may be further constraints that the optimization OPT is configured to take into account, for example, limits on the size of the public key and / or the ciphertext. The constraints may, for example, relate parameters of one or more encrypted computations to one another. In general, such further constraints may be added to the further feasible set S other (G) can be defined.

[0121] Therefore, the optimization problem is

number

number

[0122] Interestingly, by dividing the computation graph into subgraphs of each type, the optimization problem can be simplified. In particular, this division is important because it allows solutions to be divided into feasible sets.

number

[0123] In particular, the noise constraint may be defined as being based on the respective noise constraints of the respective subgraphs S i , where the noise constraint of a subgraph S i of a given type T j may be defined by noise constraint functions NCF1 268; NCF2 269 for that given type T j , T j . The noise constraint functions NCF j may take as input at least the encrypted computation parameters ECP j for the given type T j and the instantiation parameters IP-S i of the subgraphs S i .

[0124] More precisely, the noise constraint is

number

number

[0125] In general, a type of noise constraint for a subgraph may be obtained by propagating noise estimates of the inputs of the subgraph through the operations of the subgraph. In general, if a graph ECG is divided into subgraphs with outputs with noise that do not depend on the inputs, such as PBS outputs or rounded PBS outputs, the inputs of the subgraphs may be assumed to have fixed noise, derived, for example, from parameters ECPG of the global encrypted calculation, and the noise may be assumed to increase throughout the subgraph so that the noise constraint can, for example, constrain the noise of the inputs of the PBS (or other noise-fixing operation) to be small enough to ensure sufficient accuracy. A detailed example is provided in connection with FIG. 4b.

[0126] Interestingly, the noise constraints of each subgraph of the same type are therefore defined by the same function NCFj, making the satisfaction of these constraints more suitable for manual or automatic simplification. In particular, a constraint removal operation CE 222 may be performed, which may determine that the noise constraint of the first subgraph Si1 is at least as strict as the noise constraint of the second subgraph Si2 based on the instantiation parameters IP-Si1 of the first subgraph and the instantiation parameters IP-Si2 of the second subgraph. As illustrated elsewhere herein, this may be true not only when the subgraphs are of the same type, but also when the subgraphs are of different types. In any case, the noise constraint of the second subgraph can be removed from the optimization, making the optimization Opt more accessible. In other words, the noise feasible set

number

number

[0127] Further feasible set S other It is noted that if , is used, the same technique can also be used to remove the constraints of each subgraph from the computation of its feasible set.

[0128] In general, the optimizing OPT may evaluate the computational cost of performing the encrypted computation in various ways, for example, by performing a simulation or by measuring the actual computational cost of performing the encrypted computation.

[0129] A particularly efficient way to evaluate the computational cost is by using a cost function that can be calculated, for example, as a closed formula, based on the encrypted computation parameters ECP without simulation or measurement. In particular, the cost function may be based on the respective costs of the respective subgraphs. Such costs of subgraphs of a given type Tj may be defined by cost functions CF1 278, CF2 279 for given types T1, T2. The cost function typically depends on the encrypted computation parameters ECPj for a given type Tj, allowing these parameters ECPj to be optimized relative to the cost function.

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

[0131] As an example, consider subgraph types including linear mapping (in other words, multisum), key switching, modulus switching, blind rotation, and sampling. Each of these operations generally has a respective cost that depends at least on the parameter ECP of the encrypted computation. For key switch, modulus switching, blind rotation, and sampling, the cost function is typically independent of the instantiation parameters.

[0132] With respect to linear mappings, it is possible to define a 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 does depend on the linear mapping.

[0133] In the first case, a simplification of the optimization problem solved by the optimization OPT is possible, since the cost of the linear mapping does not depend on the number of additions / multiplications, but only on the non-instance-specific parameters ECPG, ECPi. For example, the cost of a subgraph may be defined as the sum of the costs of its respective operations, which 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 cost of different subgraphs of the same type in G is the same.

number

number

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

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

[0136] A preferred method for determining the encrypted computation parameter ECP is a branch and bound method. As is known per se, a branch and bound method may be used to find an optimal solution in terms of computational cost, based on given upper and lower bounds on the computational cost. Given these bounds, a branch and bound method may be much more efficient than a brute force search.

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

[0138] As an example, consider a cryptographic computation graph that includes one or more subgraphs of the type shown in Figure 4a. As discussed in relation to this figure, such a subgraph can be i =A(νi ,t i ), and ν i is the 2-norm of the applied linear map, and t i is the noise limit. A feasible parameter set is a set of all subgraphs of this type, max ==max{ν i} i∈I and t min =min{t i} i∈I A single subgraph A is i =A(ν max ,t min ) With this construction, solving the optimization problem on this graph can be guaranteed to output a feasible solution for the input graph G. The optimization problem can then be solved on this graph and the optimal parameters stored.

[0139] ∀i,ν i ∈I norm and t i ∈I p Given an encrypted computation graph G={A(ν i ,t i ) i}, a table of feasible parameters can be constructed by performing the optimization Opt for each subgraph. That is, the optimization problem can be solved by, for example, solving the optimization problem |I norm |·|I p | times, and ν∈I norm and t∈I p For each graph G={A(v,t)}, where A(v,t)=A(v,t), the following equation can be solved: For each pair (v,t), each admissible set of parameters can be determined.

[0140] In particular, lower and upper bounds derived from the noise and cost models may be used to perform optimizations on the subgraphs. As an illustrative example, the noise function

number

number

[0141] After determining the table of feasible parameters, the table is max =max{ν i} i∈I and t min =min{t i} i∈I

[0042] The above-mentioned table may be used to efficiently derive upper and lower bounds for the encrypted computation graph G, where G is a vector of scalars. Furthermore, an initial solution for the optimization may be determined based on the table. Interestingly, this table allows for efficiently determining a relatively good initial solution, which improves the efficiency of the optimization.

[0142] As an illustrative example, the lower and upper bounds can take into account the number of programmable bootstrappings for a linear mapping, as discussed in connection with FIG. 7b below.

[0143] The lower bound can be derived based on a parameter corresponding to the maximum number of programmable bootstrappings, without taking into account the cost of programmable bootstrapping. In particular, the maximum possible split can be taken, reducing the noise of the output of each split multisum. Ignoring the cost of added PBSs, the input graph can be transformed accordingly, taking the maximum 2-norm for the minimum noise bound.

number

number

[0144] The upper bound can be derived based on 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 split and taking into account the cost of the added PBSs, the input graph can be transformed accordingly, such that (ν max ,t min ) can be obtained from a table of feasible parameters. In this way, an upper bound on the complexity can be obtained.

[0145] After determining the encrypted computation parameters ECP, a combining operation COMB 224 may be applied, substituting the parameters ECP into the parameterizing encrypted computation graph ECG. The computation graph ECG may then be compiled into a set of instructions HE 290 for the encrypted computation engine. By executing the instructions HE, the encrypted computation may be performed according to the determined encrypted computation parameters ECP, either 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 a constraint on ciphertext noise. In particular, an example is provided of deriving a noise bound from a desired accuracy given the encoding of a value into ciphertext and a desired maximum error probability. Such a noise bound may be used to define a subgraph noise constraint, as also discussed in connection with Figure 2. In particular, a noise constraint may be defined by determining the maximum ciphertext noise for a subgraph type and constraining this maximum noise to stay below the noise bound.

[0147] In particular, the noise limit t(·) may be a threshold applied to the noise in the ciphertext. The noise limit may be parameterized by an error probability, which may be user-configurable. 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 party performing the encrypted computation. However, this party typically knows the variance of the probability distribution of the noise at a particular 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 error in the ciphertext. In general, the noise limit may depend on the number of bits of precision used to represent the message and the desired probability that the decryption is correct.

[0148] As an illustrative example, the figure shows a noise bound 310 for an LWE type ciphertext based on an encoding 320 of a message m. The presented method of deriving the noise bound applies to various cryptographic computation techniques proposed, for example, in the following documents: - 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 illustrated example, message m 322 has bit length p and is encrypted into the most significant bits of a single ciphertext. In particular, the LWE ciphertext is

number

number

number

number

number

[0150] In this example, the noise term e 326 is sampled from a Gaussian distribution. A noise limit may be defined based on a threshold in the variance of the noise term, such that if the noise remains below this threshold, the calculation is err Correct up to now.

[0151] In particular, this diagram shows: - ciphertext modulus q 327, e.g., 2 32 , 2 64 , or 2 128 powers of two such as ℓ, or non-powers of two such as prime numbers; - precision p, for example, message m 322 with the number of bits used to encode the message; - MSB 321 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 of 330 * (p err )=4.

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

[0153] The above example can be adapted to various other encodings as desired. For example, the MSB 321 can be removed if the programmable bootstrapping does not require it, as proposed in 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. Programmable bootstrapping without padding bits 321 is also referred to herein as "WOPBS." This allows for a two-fold higher noise limit, e.g.,

number

[0154] More generally, the noise limit is

number

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

[0156] Figure 4a shows a detailed, but non-limiting example of a type of subgraph, also called a type 1 atomic pattern.

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

[0158] In addition to linear mapping 420, subgraph 400 includes key switching 430; in this case, programmable bootstrapping, performed by modulus switching 440 and subsequent blind rotation and sampling 450, resulting in output ciphertext 460. Interestingly, because output ciphertext 460 results from programmable bootstrapping, its noise can be independent of the input (at least when the noise constraint is satisfied), e.g., independent of the noise of input ciphertexts 410-412 and the 2-norm of linear mapping 420. For purposes of this illustration, blind rotation and sampling are represented by a single node 450; however, it is also possible to represent them as respective nodes.

[0159] In many cases, the overall computation graph can be divided into subgraphs that contribute input-independent noise. For example, the input ciphertexts 410-412 may be obtained as a result of an encryption operator or programmable bootstrapping (optionally with rounding). In such cases, the noise of the inputs may be assumed to be limited by the maximum input-independent noise used, e.g., the noise resulting from programmable bootstrapping. Each operation 420-450 may contribute its respective ciphertext noise while performing the computation represented by the subgraph, which may be obtained by propagating the input noise (e.g., by a considered limit or given as an instantiation parameter) throughout the graph, as discussed in connection with FIG. 4b.

[0160] Besides the 2-norm of the applied linear map 420, the subgraph 400 may be further parameterized by instantiation parameters representing noise bounds 421, 431, 441, 451 that the ciphertexts output by operations 420-450 may be required to satisfy. Interestingly, it may be observed that while operations 420, 430, 440 typically increase noise, the output noise of blind rotation 450 does not depend on the noise of its inputs. Therefore, to verify that the subgraph satisfies the noise constraint, it may be sufficient to verify this bound 451 only with respect to the noise of the inputs of blind rotation 450.

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

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

[0163] Optionally, the number of possible values ​​of decomposition base and decomposition level for key switching and / or blind rotation may be reduced by eliminating possible parameter sets that have worse noise and / or complexity than other parameter sets. In particular, a key switch may add linear noise to the input noise, and a blind rotation may reset the input noise; thus, in either case, the noise of the operation may be considered independent of the input noise. Furthermore, for both operations, the computational cost may increase with increasing level. Thus, (base, level) combinations that are worse than the combination in terms of both noise and complexity may be eliminated. 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} Blind rotation noise

number

number

number

[0165] For example, in your concrete case, the number of possible parameter values ​​for the blind rotation is #Ω β,l may be reduced from 280 to 35, and the number of key switching values ​​may be reduced from 280 to 46.

[0166] Figure 4b shows a detailed, but non-limiting, example of ciphertext noise during evaluation of a subgraph of an encrypted computation, in which a subgraph of the type shown in connection with Figure 4a is performed. In particular, the figure shows a linear map 420 being applied to one or more input ciphertexts 410, 411, followed by key switching 430, modulus switching 440, and blind rotation and sampling 450, resulting 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 output ciphertext of the FHE operation relates to the noise of the input ciphertext. The noise model may generally have as input the encrypted computation parameters and instantiation parameters for the respective operation. In this particular example, the noise model of linear map 420 may depend on the linear map being applied, and in particular, on the 2-norm v of the linear map being applied. That is, the noise variance of the output of linear map 420 Σ(v) is the sum of the input noise variance v 2 The noise of the remaining operations in the subgraph 400 may depend only on the parameters of the encrypted computation.

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

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

[0170] The noise of the ciphertext while evaluating subgraph 400 is shown in graph 499. As shown by line 490, noise 429, 439, 449 may generally grow with each operator of the subgraph until, in this case, it reaches its peak 449 after modulus switching 440. Blind rotate and sample 450 may then result in output ciphertext 460 having input-independent noise 459 that corresponds to the noise 419 of the input of the subgraph. Graph 499 also shows a noise limit 492 for noise 490 based, for example, on the desired precision of the computation. Because the noise increases until blind rotate and sample 450 is performed, the noise constraint for subgraph 400 may therefore dictate that the noise 449 of the input to the blind rotate be less than noise limit 492.

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

[0172] In particular, the diagram shows the following parameters (along with ranges for the following parameters, including start and end values): k: dimension of the GLWE of the output of the blind rotation, for example an integer with at most or at least 5, at most or at least 10 possible values, for example a value between 1 and 10; this may be a parameter of the global encrypted calculation; N: the size of the GLWE polynomial of the output of the blind rotation, for example, a power of 2 with at most or at least 5 or at most or at least 10 possible exponent values, for example, 2 8From 2 14 up to a power of 2. Sampling 450 may result in an LWE ciphertext of dimension k·N, which may be a parameter of the global encrypted computation; -n small : The dimension of the LWE of the output of the key switching 430, for example an integer with at least 100 or at least 1000 possible values, for example an integer between 256 and 2048. For efficiency of the 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. It may be a parameter of the global encrypted computation; -β KS a decomposition base for the key switching 430, e.g., an integer with 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, a parameter of the encrypted calculation that is specific to the subgraph type 400 and can possibly be shared with one or more other subgraph types, so that 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 with 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, a parameter of the encrypted calculation that is specific to the subgraph type 400 and can possibly be shared with one or more other subgraph types, so that the remaining subgraph types may use different values ​​for this parameter; -β BRa decomposition base of the programmable bootstrapping 450, for example an integer with 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 computational parameter specific to the subgraph type 400, possibly shared with one or more other subgraph types, so that the remaining subgraph types may use different values ​​for this parameter; -l BR : The decomposition level of the programmable bootstrapping 450, for example, an integer with up to or at least 32 or up to or at least 64 possible values, for example, an integer between 1 and 64; this is, for example, an encrypted computational parameter specific to the subgraph type 400 and possibly can be shared with one or more other subgraph types, so that the remaining subgraph types may use different values ​​for this parameter.

[0173] For example, in the range of parameters considered above, the number of possible values ​​of this parameter combination is approximately 2 41 This highlights the relevance of efficient optimization of parameters.

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

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

[0176] In such cases, it may be noted that if two instantiations of the same subgraph have the same noise bound, then in general the instantiation with the smaller 2-norm will have less ciphertext noise and therefore may also satisfy the constraint if the other instantiation satisfies the constraint. Similarly, if two instantiations have the same 2-norm and the first instantiation has a higher noise bound, or in other words, a noise bound that is easier to meet, then it may be sufficient to ensure that the noise bound of the second instantiation is met.

[0177] In other words, the noise constraint may be removed 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. Mathematically, if v1, v2 are 2-norms such that v1≦v2, and t1, t2 are noise limits such that t2≦t1, then

number

[0178] For example, in the diagram: - Subgraph A4 can be removed either by virtue of subgraph A1 or by virtue of subgraph A2; - Subgraph A5 can be removed thanks to subgraph A2 or thanks to subgraph A3; - Subgraph A6 can be eliminated thanks to subgraphs A1, A2, A3, A4, or A5; Thus, the non-pruned subgraphs in this example may be subgraphs A1, A2, and A3. The set of non-pruned subgraphs is sometimes called the "Pareto front" of a type of subgraph.

[0179] As a result of removing noise constraints for some subgraphs, it may no longer be necessary to check as many feasible set constraints as there are subgraphs; instead, it may be sufficient to check the constraints for the subgraphs that are not removed. In examples where subgraphs are defined by two instantiation parameters, at least one of which has a limited number of values, e.g., a noise limit and a 2-norm, this is particularly beneficial, since the number of subgraphs that are not removed is at most the number of values ​​of that instantiation parameter. For example, with respect to a type of subgraph, the number of noise limits, and therefore the number of subgraphs that are not removed, may be at most 5 or at most 10.

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

[0181] Interestingly, also for that type of subgraph 600, the noise constraint of the second subgraph may be removed 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.Furthermore, interestingly, a subgraph can be of type 600, but also of type 400 shown in connection with FIG.

[0182] In particular, the subgraph types 400 in FIG. 4a, such as multisum, keyswitch, modulus switch, blind rotation, and sample extraction, are represented by A 1 It is also called a "Type 1 atomic pattern" and is written as follows. The subgraph type 600 in this figure is A 2 Thus, types 400 and 600 may be distinguished in that the KS 620 and the linear mapping Σ(ν) 630 are permuted.

[0183] For example, the encrypted computation graph G may be composed entirely of APs of these two types. For each type independently, subgraphs may be removed as described in connection with FIG.

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

[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 the input noise, e.g., PBS, WOPBS; - operators that add input-independent noise to the input noise, e.g., key switch 620, modulus switch 640; -Operators that output noisy ciphertext that depends (e.g., nonlinearly) on the input noise, e.g., multisum630, GLWE multiplication, etc.

[0186] In particular, consider two types of subgraphs where the Type 2 and Type 3 FHE operators are permuted, as is the case for the multisum 630 and keyswitch 620 of subgraphs Type 400 and 600. Note that non-Type 1 FHE operators increase noise within the ciphertext. Type 3 FHE operators increase noise depending on the input noise, so the larger the input noise, the larger the output noise.

[0187] From this, the following conclusions can be drawn: A 1 and A 2 contains the same operations, but A 1 In, the type 2 FHE operator precedes the type 3 FHE operator, while in A 2 are two types of subgraphs that are distinguished by the fact that the same FHE operator of type 2 is followed by an operator of type 3. Then, A 2 The noise of A 1 For example, A 2 corresponds to the subgraph type 600 in Figure 6a, and A 1 Let A correspond to the subgraph type 400 in Figure 4a. Let ν be the 2-norm and t be the noise limit. Then, since the noise of type 2 operators is amplified by type 3 operators, A 2 The noise in (ν,t) is A 1 It is larger than the noise in (ν,t).

[0188] The above example shows how a subgraph of one type can be used to remove the noise constraint of a subgraph of another type, particularly when the subgraph types differ by permutations between type 2 and type 3 FHE operators, in this case KS and Multisum. In particular, let v1, v2 denote the 2-norm such that v1 ≤ v2, and let t1, t2 denote the noise bounds such that t2 ≤ t1. Then,

number

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

[0190] 6b shows a detailed, but non-limiting, example of a 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; followed by leveled encrypted multiplication 670; key switching 631; and programmable bootstrapping 651. The leveled encrypted multiplication 670 may include, for example, a packing key switch, a tensor product, and a relinearization, as known per se, and may also be represented by respective nodes for each sub-operation. Similarly, programmable bootstrapping is represented by a single node 651 in this example, but may also be represented by a node for each of its sub-operations, as in FIG. 6a, for example. This type of subgraph may be represented by a 3 This is sometimes called a "Type 3 atomic pattern" written as follows.

[0191] Thus, subgraph type 601 may be based on subgraph type 400 and further includes multiplication 670. Similarly, a fourth subgraph type may be defined based on subgraph type 600 of Figure 6a and further includes encrypted multiplication between linear mapping 630 and modulus switching 640.

[0192] Interestingly, a subgraph of a first type may be removed based on a subgraph of a third type, and similarly, a subgraph of a second type may be removed based on a subgraph of a fourth type. More generally, a subgraph of a particular type may be removed based on a subgraph of that type with additional leveled encrypted multiplication. In effect, the leveled encrypted multiplication adds additional noise and therefore leads to a stricter noise constraint.

[0193] For example, A 1 (ν,t) is a subgraph of the first type, and A 3 Let (ν1,ν2,t) be a subgraph of the third type.

number

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

[0195] As discussed elsewhere, the key-switching and bootstrapping keys may be specific to a particular set of parameters of the encrypted computation, e.g., level and decomposition key parameters. As discussed in connection with FIG. 4a, these parameters may be shared between different instantiations of the same type of subgraph. In particular, in some cases, the same key-switching and / or bootstrapping key may be used throughout the encrypted computation. This has the advantage of leading to smaller key material, but on the other hand, in this case, it may be noisier in the subgraph where this is possible, and it may be impossible to use faster key switching or bootstrapping, which may have a negative impact on computational complexity.

[0196] There are several ways to support multiple key-switching and / or bootstrapping keys in the same encrypted computation. As also discussed in connection with Figure 4a, one way is to define different types of subgraphs that have the same structure but use different key-switching and / or bootstrapping keys, with particular subgraphs being pre-configured to have particular types. A drawback of this approach is that it is not possible to automatically optimize which keys are used in which subgraphs.

[0197] Another approach is to define the key switching and / or bootstrapping cryptographic parameters (e.g., level / base) as parameters of the encrypted computation for a particular instance of a subgraph, rather than for the type of subgraph. In such a case, 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, making the optimization problem much more complex.

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

[0199] This is shown below for key switching: Suppose the number of key switching keys to use is X and the number of subgraphs that use them is Y. The optimization of the key switching keys to use is ∀i∈[1,Y], δ i ∈[1,X], which may correspond to determining Y This leads to an additional search space of ≡ ...

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

[0201] In particular, the key switching keys used may be ordered according to the amount of noise they add, e.g., in the sequence (KSK0, KSK1, ...) where KSK0 adds less noise than KSK1, which adds less noise than KSK2, etc. In such cases, a key switch using KSK0 will typically be more computationally expensive than a key switch using KSK1, leading to a trade-off between cost and noise.

[0202] As an example, consider multiple subgraphs G = {A(ν0,t),A(ν1,t),A(ν2,t)} 770-772 with the same noise limit t and different 2-norms (e.g., of type 1 or 2 as considered herein), where ν0 < ν1 < ν2. Furthermore, consider two key-switching keys KSK0 and KSK1, where KSK1 adds more noise during key switching than KSK0. The key-switching keys used in each subgraph are determined by the parameters (δ0, δ1, δ2), δ i ∈{0,1},780-782.

[0203] Note that in this example, (δ0, δ1, δ2) = (0, 1, 0) cannot be the optimal solution. This can be demonstrated as follows: As discussed in connection with Figures 4a and 6a, in this case,

number

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

[0205] Now consider the solution (δ0,δ1,δ2) = (1,1,0), in which case the noise constraint on A(ν0,t) can be removed from the optimization since the noise constraint on A(ν1,t) is at least as strict.

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

number

number

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

number

[0208] The above argument can be extended to graphs with any number of subgraphs with the same noise bound. In such a case, identifying each key-switching key may correspond to determining the number of 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 and assume that two key switching keys are used. Then, the optimal δ = (δ0,...,δ Y ) is of the form (1,...,1,0,...,0). Therefore, 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 of size 2 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 argument also holds 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 {γ j} j∈[[1,X-1]] It may be sufficient to determine the size X Y Instead of having to search in a search space of size

number

[0210] The above technique involves generating a key identifier vector (δ0,...,δ) for each set of subgraphs as described above. Y ) can be applied to each set of subgraphs that share a respective noise bound.

[0211] Additionally, the above techniques can also be applied to identify each bootstrapping key to use in each subgraph, where the bootstrapping keys are ordered according to the amount of noise added.

[0212] It is also possible to determine, for a given subgraph, both the key-switching key and the bootstrapping key to be used. In such a case, if the noise constraint for the first subgraph is at least as strict as the noise constraint for the second subgraph, then the key-switching key and the bootstrapping key for the first subgraph may be constrained such that they do not both add more noise than the key-switching key and the bootstrapping key for the second subgraph. For example: v > v, where t is the noise limit,

number

number

number

number

[0213] Figure 7b shows a detailed, but non-limiting, example of determining the number of programmable bootstrappings performed during the application of a linear mapping. The example in this figure is based on the subgraph type of Figure 4a, but the technique applies equally to other types of subgraphs that involve the application of a linear mapping, such as the subgraph type shown in Figure 6a.

[0214] Shown in the figure is a subgraph 700 of the type shown in connection with FIG. 4a, including a linear mapping 720 applied to one or more input ciphertexts 710; followed by key switching 730; and programmable bootstrapping 740 (shown here as a single node, but typically implemented as modulus switching; blind rotation; and sample extraction) resulting in an output ciphertext 760.

[0215] Also shown is a different subgraph 700' that computes the same output ciphertext 760 from the same input ciphertext 710, but in this case does so by using programmable bootstrapping 750 during the application of a linear map that is split into two parts 721, 722. The inserted programmable bootstrapping 750 in this example applies an identity function, but could also incorporate, for example, scalar multiplication and / or addition of a public value. Similar to subgraph 700, key switching and programmable bootstrapping 730 (shown here as a single node for simplicity) is applied to the output of linear maps 721-722 to obtain the output ciphertext.

[0216] Inserting the PBS 750 into the subgraph may increase computational complexity, in this case during the application of a linear mapping. On the other hand, the noise of the ciphertext while evaluating the subgraph is reduced by the PBS 750, which in this case reduces the 2-norm of the multisums 721, 722, thus allowing for noisier but faster parameters.

[0217] Interestingly, the inventors have realized that it is possible to optimize for this trade-off, thereby automatically determining, for each subgraph of a given type, the respective number of programmable bootstrappings to be performed during the application of each linear map in the subgraph, e.g., as in this example. Thus, subgraph types may be defined that have a variable number d of programmable bootstrappings. For example, the computation graph of the encrypted computation input to the optimization may not include programmable bootstrappings during the application of each linear map, in which case the optimization will insert them appropriately.

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

number

[0219] When it is determined that one or more programmable bootstrappings are performed during a linear mapping, the linear mapping may be automatically divided into a number of respective linear mappings corresponding to the number of programmable bootstrappings. This can be done by minimizing the largest 2-norm of each linear mapping, e.g., v≈v. In this way, the insertion of programmable bootstrappings is most effective in allowing for noisier parameters.

[0220] In particular, the linear maps may be split by minimizing the largest 2-norm of each linear map. This provides a good approximation of the optimal solution in terms of noise and complexity, by virtually ignoring the cost of the multisums (and in particular the number of inputs to which each multisum applies). In particular, to split a multisum into two multisums, such as subgraph 700′, the following optimization problem may be solved, for example, using a suitable solution method known per se:

number

number

[0221] Another technique for splitting the multisum is as follows: This technique assumes that the weights are close to a uniform distribution, e.g., w i ∈[-2 p ,2 p

[0010] is particularly effective when

[0011] . According to this technique, each weight may be radix-decomposed into digits, and the digits may be applied to the input and combined. For example, the radix decomposition may be similar to Algorithm 1 in I. Chillotti et al., "Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 seconds," proceedings ASIACRYPT 2016 (incorporated herein by reference), or may use 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

[0222] Interestingly, the number of programmable bootstrapping steps for each subgraph i is d iIn determining the number of programmable bootstrappings d for the second subgraph, if the noise constraint for the first subgraph i is at least as strict as the noise constraint for the second subgraph j, j The number of programmable bootstrappings of the first subgraph d i By constraining d i The parameter space of may be significantly reduced.

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

number

number

number

number

number

[0224] Figure 8 shows a detailed, but non-limiting, example of programmable bootstrapping with noise rounding, which can be combined with any subgraph type that includes programmable bootstrapping, such as the subgraph types of Figures 4a, 6a, 6b, or 7b.

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

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

[0227] As the inventors have realized, by applying a rounding operation to the results of programmable bootstrapping, it is possible to make the rounded results 879 of programmable bootstrapping independent of the particular Fast Fourier Transform (FFT) implementation used to perform the programmable bootstrapping, as long as the FFT implementation has a given precision. This may make the PBS effectively deterministic. This may result in, or at least contribute to, the complete encrypted computation being deterministic.

[0228] That is, the inventors have noticed that the output 869 of the sampling before rounding 870 may differ between FFT implementations. This was indeed observed in an experiment where a PBS implementation on a CPU using FFTW was compared with an implementation on a GPU using a custom FFT. Both outputs, while correct in themselves, may differ in terms of the exact output noise produced. It was observed that for many coefficients in the PBS output, the most significant bits, which contain the message, are the same, while the least significant bits (which contain the noise) contain some differences.

[0229] The number of bits to which rounding is applied, in other words, the location where the rounding should occur, can be pre-configured, but this location can also be determined as a parameter of the encrypted computation, e.g., a global encrypted computation parameter or a parameter specific to the type of subgraph. That is, rounding can add a certain amount of noise; the higher the rounding is applied to the MSB, the more noise is added to the plaintext. For a given implementation of the FFT, optimization may use a limit in terms of the error in the ciphertext coefficients that the implementation introduces. Thus, the parameters of the encrypted computation may be optimized taking into account the FFT error model in addition to the noise and cost models.

[0230] To take into account the implementation-dependent errors of the FFT, a constraint can be included in the optimization of the parameters of the encrypted calculation. This constraint defines an additional feasible set S that is taken into account in the optimization. other (G) The condition is:

number

number

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

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

[0233] The FFT error may be calculated based on other cryptographic and / or encrypted calculation parameters, e.g.

number

[0234] It is noted that 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 FFTs, or in general, other FHE operations that introduce implementation-dependent noise, thus contributing to making the encrypted computation act deterministically on 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, we contemplate a cryptographic method of performing an encrypted computation, and a corresponding encrypted computation device, in which a noise rounding operation 870 is applied to the output of an FHE computation that includes implementation-dependent noise, such as FFT-dependent noise of programmable bootstrapping 840-853. The encrypted computation performed by this method and device may use the parameters of the encrypted computation as described herein, but this is not required.

[0236] In particular, cryptographic methods for performing encrypted calculations, including noise rounding, may be performed by mining devices of a distributed ledger, e.g., a blockchain. In particular, multiple such mining devices may perform the encrypted calculations. Using rounding 870 may achieve that each mining device calculates the exact same ciphertext as the output of the encrypted calculation, i.e., not only is the plaintext the same, but the ciphertext that encrypts the plaintext is also the same. When used in combination with the optimizations described herein, it is still possible for each mining device to use parameters for its respective encrypted calculation that are optimal for noise, e.g., FFT errors, that depend on the implementation of each system configuration. In particular, by using rounding 870, miners may achieve consensus on the output of the encrypted calculation without requiring decryption.

[0237] The following numbered paragraphs include contemplated non-limiting examples:

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

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

[0240] 3. The method (900) of paragraph 2, wherein the first subgraph and the second subgraph are parameterized by a noise limit and a 2-norm of an applied linear mapping, the noise limit of the first subgraph being at most the noise limit of the second subgraph, and the 2-norm of the first subgraph being at least the 2-norm of the second subgraph.

[0241] 4. The method (900) of any preceding clause, wherein the computational cost is minimized based on a cost function, the cost function being based on a respective cost of each subgraph, and the cost of a subgraph of a given type being defined by a cost function for the given type that takes as input at least the parameters of the encrypted computation for the given type and is independent of the instantiation parameters.

[0242] 5. The method (900) of any preceding clause, wherein the subgraph represents a subcomputation that results in an output ciphertext with noise that is independent of the input.

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

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

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

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

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

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

[0249] 12. Item 10. The method (900) of item 11, wherein 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 if the noise constraint for the first subgraph is at least as strict as the noise constraint for the second subgraph.

[0250] 13. - transforming a non-encrypted computation graph into a computation graph of encrypted computations, and / or - Compiling the computation graph of the encrypted computation into a set of instructions for an encrypted computation engine; and / or - performing an encrypted calculation according to the determined encrypted calculation parameters; The method (900) of any preceding claim, further comprising:

[0251] 14. A configuration device (110) for determining encrypted computation parameters for performing an encrypted computation on a noisy ciphertext, comprising: - a storage (130) for storing data representing the computation graph of the encrypted computation; a processor subsystem (140), - obtaining a partition of a computation graph into multiple subgraphs, where the subgraphs are defined by a type from a set of one or more types and by zero or more instantiation parameters of the type; - defining a set of cryptographic calculation parameters for each type; a processor subsystem (140) configured to: optimize parameters of the encrypted computation, the parameters of the encrypted computation being optimized to minimize a computational cost of performing the encrypted computation according to the parameters of the encrypted computation; and constrain the parameters of the encrypted computation while performing the encrypted computation to satisfy a noise constraint on the noise of the ciphertext, the noise constraint being based on a respective noise constraint of each subgraph, the noise constraint of a subgraph of a given type being defined by a noise constraint function for the given type that takes as input at least the parameters of the encrypted computation for the given type and instantiation parameters of the subgraph. A configuration device (110) comprising:

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

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

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

[0255] The method 900 may include obtaining 920 a partitioning of the computation graph into multiple subgraphs. A subgraph may be defined by a type from a set of one or more types and zero or more instantiation parameters of the type.

[0256] The method 900 may include defining 930 a respective set of parameters for each type of encrypted computation.

[0257] The method 900 may include optimizing 940 parameters of the encrypted computation. In the optimization, the parameters of the encrypted computation may be optimized to minimize the computational cost of performing the encrypted computation according to the parameters of the encrypted computation. Furthermore, the parameters of the encrypted computation may be constrained to satisfy a noise constraint on the noise of the ciphertext while performing the encrypted computation. The noise constraint may be based on a respective noise constraint of each subgraph. The noise constraint of a subgraph of a given type may be defined by a noise constraint function for 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 illustrates schematically an example embodiment of a cryptographic method 950 for performing encrypted computations.

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

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

[0261] As will be apparent to one skilled in the art, there may be many different ways of performing methods 900, 950. For example, while the order of steps may be performed in the order shown, the order of steps may be changed, or some steps may be performed in parallel. Furthermore, other method steps may be inserted between steps. The inserted steps may represent improvements to the methods as described herein or may be unrelated to the methods. For example, some steps may be performed at least partially in parallel. Furthermore, a given step may not be fully completed before the next step is initiated. Methods 900, 950 may also be combined; for example, method 950 for performing an encrypted calculation may be performed according to encrypted calculation parameters previously determined according to method 900.

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

[0263] It will be understood that the subject matter disclosed herein also extends to computer programs, particularly computer programs on or within a carrier wave configured to carry out the subject matter disclosed herein. The program may be in the form of object code, such as source code, object code, intermediate source code, and partially compiled form, or any other form suitable for use in implementing method embodiments. An embodiment relating to a computer program product includes computer-executable instructions corresponding to each of the processing steps of at least one of the described methods. These instructions may be subdivided into subroutines and / or stored in one or more files, which may be 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 described systems and / or products.

[0264] Typically, devices described herein, e.g., in Figures 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 corresponding memory, e.g., volatile memory such as RAM or non-volatile memory such as Flash. Alternatively, the system may be implemented in whole or in part in programmable logic, e.g., as a field programmable gate array (FPGA). The system may also be implemented in whole or in part as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their specific application. For example, the circuit may be implemented in CMOS using, e.g., a hardware description language such as Verilog, VHDL, etc. In particular, the system may include circuitry for evaluation of cryptographic primitives.

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

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

[0267] Alternatively or additionally, data 1020 may represent encrypted computation parameters and / or instructions for an encryption computation engine determined according to an embodiment.

[0268] The data 1020 may be embodied on the computer-readable medium 1000 as physical marks or by magnetization of the computer-readable medium 1000. However, any other suitable embodiment may be envisioned. Furthermore, although the computer-readable medium 1000 is shown here as an optical disk, it will be understood that the 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 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 shown schematically in the figure. The circuit 1110 includes a processing unit 1120, e.g., a CPU, for executing computer program components for performing methods according to embodiments and / or implementing modules or units thereof. The circuit 1110 includes a memory 1122 for storing programming code, data, etc. A portion of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126, e.g., an antenna, a connector, or both. The circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the dedicated IC 1124, and the communication element 1126 may be connected to each other via an interconnect 1130, e.g., a bus. The processor system 1110 may be configured for contact and / or contactless communication using an antenna and / or connector, respectively.

[0270] For example, in an embodiment, the processor system 1140, e.g., a device for performing encrypted calculations or compilation, may include a processor circuit and a memory circuit, where 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, or the like. In an embodiment, the processor circuit may be an ARM Cortex M0. The memory circuit may be a ROM circuit or may be a non-volatile memory, e.g., flash memory. The memory circuit may be a volatile memory, e.g., SRAM memory. In the latter case, the device may include a non-volatile software interface, e.g., a hard drive, a network interface, or the like, configured to provide the software.

[0271] Although device 1110 is shown as including one of each described component, various components may be duplicated in various embodiments. For example, processor 1120 may include multiple microprocessors configured to independently perform methods described herein, or configured to cooperatively perform steps or subroutines of methods described herein to achieve the functionality described herein. Furthermore, when device 1110 is implemented in a cloud computing system, various hardware components may reside in 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] It should be noted that the above-described embodiments illustrate rather than limit the subject matter disclosed herein, and that those skilled in the art will be able to design many alternative embodiments.

[0273] In the claims, any reference signs placed in parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. A phrase such as "at least one of" following a list of elements denotes selection of all or any subset of the elements from the list. For example, the phrase "at least one of A, B, and C" should be understood as including A only, B only, C only, 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 comprising several distinct elements and by a suitably programmed computer. In a device claim reciting 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, reference signs in parentheses refer to the reference signs in the drawings of the illustrated embodiments or to the formulas of the embodiments, thus facilitating the understanding of the claims, and these references shall not be construed as limiting the claims.

Claims

1. 9. A computer-implemented method (900) for determining encrypted computation parameters for performing an encrypted computation on noisy ciphertext, comprising: accessing (910) data representing the computation graph of the encrypted computation; Obtaining a partitioning of a computation graph into a plurality of subgraphs (920), where a subgraph represents a subcomputation that results in an output ciphertext with input-independent noise and is defined by a type from a set of one or more types and by zero or more instantiation parameters of that type; storing (930) each set of encrypted computational parameters for each type; - optimization of the parameters of the encrypted calculation (940), - the parameters of the encrypted calculation are optimized to minimize the computational cost of performing the encrypted calculation according to the parameters of the encrypted calculation; the parameters of the encrypted computation are constrained to satisfy a noise constraint on the noise of the ciphertext while performing the encrypted computation, the noise constraint being based on the respective noise constraints of the respective subgraphs, the noise constraint of a subgraph of a given type being defined by a noise constraint function for 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 subgraphs (940); determining, based on instantiation parameters of the first subgraph and the second subgraph, whether the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph; If so, remove the noise constraint of the second subgraph from the optimization of the parameters of the encrypted computation. The method (900) includes:

2. 9. The method (900) of claim 1, wherein the first subgraph and the second subgraph are parameterized by a noise limit and a 2-norm of an applied linear mapping, the noise limit of the first subgraph being at most the noise limit of the second subgraph, and the 2-norm of the first subgraph being at least the 2-norm of the second subgraph.

3. 3. The method (900) of claim 1 or 2, wherein the computational cost is minimized based on a cost function, the cost function being based on a respective cost of each subgraph, the cost of a subgraph of a given type being defined by a cost function for the given type that takes as input at least the parameters of the encrypted computation for the given type and is independent of instantiation parameters.

4. 3. The method (900) of claim 1 or 2, wherein the parameters of the encrypted computation include one or more of a programmable bootstrapping decomposition base, a programmable bootstrapping decomposition level, a key switching decomposition base, and a key switching decomposition level.

5. 3. The method (900) of claim 1 or 2, wherein a subgraph of the plurality of subgraphs includes programmable bootstrapping that results in an output ciphertext and noise rounding of the output ciphertext.

6. The method (900) according to claim 1 or 2, wherein the optimization of the parameters of the encrypted calculation is performed by a branch and bound method.

7. 3. The method (900) of claim 1 or 2, wherein the parameters of the encrypted computation identify respective key-switching and / or bootstrapping keys to be used for respective subgraphs, and wherein the key-switching and / or bootstrapping keys for a first subgraph are constrained to add at most the same amount of noise as the key-switching and / or bootstrapping keys for a second subgraph if the noise constraint for the first subgraph is at least as stringent as the noise constraint for the second subgraph.

8. 3. The method (900) of claim 1 or 2, wherein the encrypted computation parameters indicate, for each subgraph to which each linear map is applied, a respective number of programmable bootstrappings to be performed during the application of each linear map.

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

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

11. - transforming a non-encrypted computation graph into an encrypted computational graph, and / or Compiling the computation graph of the encrypted computation into a set of instructions for the cryptographic computation engine; and / or - performing an encrypted calculation in accordance with the determined encrypted calculation parameters; The method (900) of claim 1 or 2, 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 the computation graph of the encrypted computation; a processor subsystem (140), obtaining a partition of the computation graph into a number of subgraphs, each subgraph representing a subcomputation resulting in an output ciphertext with input-independent noise, defined by a type from a set of one or more types and by zero or more instantiation parameters of that type; storing a respective set of encrypted computational parameters for each type; optimizing parameters of the encrypted computation, wherein 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 a noise constraint on the noise of the ciphertext while performing the encrypted computation, the noise constraint being based on a respective noise constraint of each subgraph, and the noise constraint of a subgraph of a given type is defined by a noise constraint function for the given type that takes as input at least the parameters of the encrypted computation for the given type and instantiation parameters of the subgraph; determining, based on instantiation parameters of the first subgraph and the second subgraph, whether the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph; If so, remove the noise constraint of the second subgraph from the optimization of the parameters of the encrypted computation. A processor subsystem (140) configured to A configuration device (110) comprising:

13. A non-transitory computer-readable storage medium (1000) comprising instructions that, when executed by a processor system, cause the processor system to perform the method of claim 1.

Images