Optimizing encryption computation parameters

Abstract

Some implementations involve methods for determining cryptographic computation parameters for a computer to perform cryptographic computations on noisy ciphertext. A computation graph is divided into multiple subgraphs, each defined by a type and instantiation parameters of that type. Cryptographic computation parameters for a corresponding group are defined for the corresponding type. Optimization of the cryptographic computation parameters is performed to minimize the computational cost of performing the cryptographic computation based on these parameters. The cryptographic computation parameters are constrained to satisfy noise constraints on the ciphertext noise when performing the cryptographic computation. These noise constraints are based on corresponding noise constraints of the corresponding subgraph, wherein the noise constraints are defined by a noise constraint function of the type, which takes at least the cryptographic computation parameters of the type and the instantiation parameters of the subgraph as input.

Description

Technical Field

[0001] The currently disclosed subject matter relates to computer-implemented methods, devices, and computer-readable media for determining cryptographic computation parameters. Background Technology

[0002] Homomorphic cryptography allows for encrypted computations: computations (e.g., circuit evaluations) are performed by one party on encrypted data that that party cannot decrypt. For example, input data and computation results can be received and returned in encrypted form. Intermediate data (e.g., the internal state of the computation) can also be encrypted.

[0003] Even if the computation result is returned in encrypted form, the expected output upon decryption is the same or very close, as if the operation were performed on unencrypted data. Homomorphic encryption can be used to protect privacy during outsourced storage and computation. This allows data to be encrypted and outsourced to a cloud environment for processing and / or storage, while remaining encrypted at all times.

[0004] For example, homomorphic cryptography can be applied in various fields such as healthcare, where privacy regulations make it difficult to share plaintext data, but computations on encrypted medical data may be permitted. For instance, a medical model developed to classify medical data can be configured to receive encrypted medical data from a third party (e.g., a hospital). The medical model can classify the medical data, for example, as normal or abnormal, or as having a specific medical syndrome, disease, or other condition. Using homomorphic encryption, the medical model can be applied to the received medical data in encrypted form. This means that the party possessing the medical model has no access to the plaintext medical data corresponding to the encrypted medical data. Users of the service can decrypt the results of the medical model application.

[0005] Specifically, there exist homomorphic cryptographic techniques that can, at least in principle, be used to compute any function of encrypted data. This technique is called "fully homomorphic encryption" (FHE).

[0006] For security reasons, known implementations of FHE use noisy ciphertext. For example, encrypting a data item may involve mapping the data item to a point in a lattice associated with a key, to which noise is added. Specifically, many known implementations of FHE use LWE-type ciphertext, whose security depends on the cryptographic difficulty of the fault-tolerant learning problem. Such LWE-type ciphertext may include one or more mask values ​​(e.g., values ​​modulo a modulus q or torus elements), plus a body value derived from the mask values ​​and from the plaintext using an encryption key, and the body value contains noise. A generalization of this is GLWE-type ciphertext, which encrypts data using polynomial rather than scalar values. RLWE-type ciphertext is another type of GLWE ciphertext.

[0007] When data items are first encrypted, the noise is low, and the encryption is recent. For example, the amount of noise is low enough that if the data item is to be decrypted, the noise can be removed at some point during the decryption process (e.g., by rounding). On the other hand, the noise should be high enough to make attacks on the system sufficiently difficult. For example, many homomorphic encryption schemes might be vulnerable to attacks by linear algebra or other efficient algorithms (e.g., lattice reduction algorithms) assuming no noise. When data items are encrypted, noise is added, and this noise is chosen to make attacks difficult, while homomorphic operations can still be performed, and decryption is still possible.

[0008] Most homomorphic operations add noise to the homomorphically encrypted data item. When many of these operations are performed, the noise can reach a level where unique decryption is no longer possible. Typically, it is known to use a technique called bootstrapping to reduce the noise in homomorphic encrypted values. Bootstrapping uses a public key called a bootstrap key. By using bootstrapping to reduce noise when needed, in principle any desired number of homomorphic operations can be computed.

[0009] One specific class of fully homomorphic encryption schemes is the TFHE class of homomorphic encryption schemes. This scheme is described in I. Chillotti et al., “Programmable bootstrapping enables efficient homomorphicinference of deep neural networks,” Cyber ​​Security Cryptography and Machine Learning (CSCML 2021), Lecture Notes in Computer Science, Vol. 12716, pp. 1–19, Springer, 2021 (included in this paper by citation). The TFHE class schemes differ from other FHE schemes in that they support a relatively efficient technique for bootstrapping; furthermore, they can simultaneously evaluate functions during bootstrapping operations, a process known as programmable bootstrapping. Regular bootstrapping is equivalent to programmable bootstrapping with an identity function.

[0010] Interestingly, the output of the programmable bootstrapping has a certain amount of noise, which is independent of the noise in the input ciphertext. Therefore, by executing the programmable bootstrapping, the noise in the input ciphertext can be reduced to a fixed amount, while potentially applying a function to the input ciphertext simultaneously. By executing the programmable bootstrapping at the appropriate time, cryptographic computations with infinite multiplication complexity can be performed.

[0011] The operation of cryptographic computation techniques, and specifically TFHE-type schemes, is affected by a variety of cryptographic computation parameters. These include various parameters of the cryptographic scheme itself (e.g., the mask value and the number of moduloes used for LWE), as well as parameters that affect specific cryptographic operations (such as the decomposition levels used in programmable bootstrap operations).

[0012] The selection of encryption computation parameters requires careful consideration. In general, parameters can affect the security of encryption computations (e.g., the more noise added during encryption, or the larger the number of mask values, the harder it is to crack the encryption scheme), the accuracy of the computation results (e.g., the polynomial size affects the number of bits of accuracy, and computations can be performed at the number of bits of said accuracy), and the computational and storage requirements for performing the computations (e.g., the decomposition level of the programmable bootstrap and the LWE parameter affect the size of the bootstrap key and the computational complexity of performing this operation).

[0013] This means that parameter selection involves several trade-offs. For example, while maintaining security, some other parameters of the encryption scheme (e.g., polynomial size and / or GLWE dimension) can be increased to minimize noise. Simultaneously, the cost of various encryption computation operators depends on the polynomial size and / or GLWE dimension, leading to a trade-off between noise and cost: the goal is to use less noise to ensure computational correctness, while using a small amount of noise increases computational cost due to the need to increase other parameters. Summary of the Invention

[0014] Therefore, the desired goal is to provide automated techniques to determine appropriate cryptographic computation parameter values ​​for performing a given cryptographic computation.

[0015] According to one aspect of the invention, a computer-implemented method for determining encrypted computation parameters is provided, as defined in claim 1. According to another aspect, an apparatus corresponding to the computer-implemented method is provided, as defined in claim 2. According to another aspect, a computer-readable medium is provided, as defined in claim 3.

[0016] Several implementations involve optimizing cryptographic computation parameters for performing cryptographic computations on noisy ciphertext. For example, such parameters may include global parameters used throughout the cryptographic computation, such as parameters of the cryptographic scheme used to encrypt the noisy ciphertext, like the polynomial size and / or GLWE dimension.

[0017] Interestingly, parameters can be optimized for a given existing computation. Optimization of cryptographic parameters can be based on the representation of the cryptographic computation to be performed. The computation can be considered to correspond to a computation graph, where nodes represent operations to be performed on encrypted data, and edges represent the inputs and outputs of those operations. For example, nodes can correspond to homomorphic linear operations, key switching, modulus switching, blind rotations, and / or sample extraction, etc. Typically, corresponding edges can have a corresponding impact on the security, accuracy, and / or efficiency of the cryptographic computation, for example, by incurring specific computational costs, by providing outputs with specific accuracy, etc.

[0018] Interestingly, the inventors realized that the computation graph of cryptographic computation is often composed of specific patterns that can appear multiple times throughout the cryptographic computation. For example, a pattern could be applying a cryptographic linear mapping to one or more inputs, followed by a key switch, then a modulus switch, and then blind rotations and sample extraction.

[0019] The inventors envision using the recurrence of patterns from these categories to efficiently optimize the parameters of cryptographic computation. That is, the inventors envision performing optimization based on dividing the computation graph into multiple subgraphs according to recurring patterns. Thus, a subgraph can be defined by one of a set of one or more types (corresponding to the pattern followed by the subgraph) and by zero or more instantiation parameters of said type. For example, continuing with the embodiment above with a subgraph having a linear mapping, the subgraph can be parameterized by a set of coefficients representing the applied linear mapping (or simply the 2-norm of the coefficients, which has proven to be sufficient information for performing optimization in many cases).

[0020] The optimization can then be expressed based on this representation of the computation by type and instantiation parameters. The optimization can take computational cost, security, and accuracy into account. Specifically, the optimization can minimize computational cost while ensuring that the computation is sufficiently secure and accurate. This yields a solution that is computationally most efficient given the security and accuracy requirements. The optimization can be configured to ensure that additional constraints are met, such as constraints on storage requirements (which are, for example, related to the number of different bootstrap keys or key-switching keys used in the cryptographic computation). However, in many cases, this is unnecessary; for example, storage requirements can be encoded as part of the optimization problem so that it is not necessary to ensure they are met separately.

[0021] Interestingly, security and accuracy requirements can be expressed by subdividing the computation graph into subgraphs with corresponding types and instantiation parameters. In other words, optimization can constrain the cryptographic computation parameters to satisfy noise constraints on the ciphertext noise computed during the cryptographic computation. This noise constraint can be defined by a noise constraint function specific to the subgraph of the corresponding type. The noise constraint function can take at least the cryptographic computation parameters of the given type and the instantiation parameters of the specific subgraph as input. Therefore, the total noise constraint can include the corresponding constraints of the corresponding subgraphs given by the noise constraint function.

[0022] Interestingly, constraining noise constraints based on noise constraint functions corresponding to the subgraph type allows optimization to be performed efficiently. Expressing the optimization problem based on the subgraph rather than on individual cryptographic operations significantly reduces the size of the constraint satisfaction problem to be solved. Furthermore, by using noise constraint functions, the optimization problem is expressed based on multiple instances of the same constraint function to be satisfied. Specifically, this formulation makes optimization easier to perform because it allows constraints dominated by other constraints to be eliminated, either explicitly or automatically by the optimizer used.

[0023] Noise constraints can be explicitly imposed on ciphertext noise, for example, by specifying that the noise of the corresponding ciphertext must be below a certain limit. Noise constraints can also be implicitly imposed on ciphertext noise based on the parameters of the encryption scheme used. Specifically, at a given security level, the product of the GLWE dimension and the polynomial size (as is known per se) is inversely proportional to the noise. By forcing the noise of the corresponding ciphertext to be greater than the minimum noise required to achieve a specific security level and less than the maximum noise required to achieve a specific accuracy, both security and accuracy can be ensured.

[0024] In one implementation, the noise constraint of the first subgraph can be determined to be at least as strict as the noise constraint of the second subgraph based on the instantiation parameters of the first and second subgraphs. That is, if the noise constraint of the first subgraph is satisfied for a given set of cryptographic computation parameters, it implies that the noise constraint of the second subgraph is also satisfied. Interestingly, this can be achieved by computation based on the type and the expression of the instantiation parameters, since for a given type, it can be determined whether the noise constraint of the first subgraph of that type is at least as strict as the noise constraint of the second subgraph of that type based on the instantiation parameters. In some cases, such a determination can also be made for different types of subgraphs, as illustrated in the embodiments given herein. In any case, determining that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph allows the noise constraint of the second subgraph to be eliminated from the optimization. This allows for a significant reduction in the size of the optimization problem, making it more efficient to solve.

[0025] In one implementation, the first and second subgraphs can be parameterized by a noise bound and by the 2-norm of the applied linear mapping. The noise bound corresponds to the expected minimum precision of the encrypted value, and thus to the maximum amount of noise. The 2-norm can be used as a parameter because the increase in noise due to the application of the linear mapping can be expressed according to the 2-norm.

[0026] For example, the subgraphs represented by these parameters can include applications such as linear mapping, key switching, modulus switching, blind rotation, and sample extraction. This is a common pattern for cryptographic computation, and in fact, in some cases, the entire cryptographic computation can be constructed from instances of this type of subgraph.

[0027] In this case, it is particularly efficient to determine that one subgraph has a stricter noise constraint than another. That is, this can be the case if the noise bound of the first subgraph is at most the noise bound of the second subgraph and if the 2-norm of the first subgraph is at least the 2-norm of the second subgraph (combined with other parametric conditions, if present). This allows for a significant reduction in the number of constraints required. Specifically, the noise bound can be represented by a discrete parameter. This discrete parameter can 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 bound, the subgraph with the highest 2-norm can be preserved along with the remaining subgraphs that have been eliminated. Therefore, the number of remaining subgraphs can be at most equal to the number of possible values ​​of the noise bound, regardless of the size of the cryptographic computation. Thus, interestingly, at least for this type of subgraph, the complexity of satisfying the noise constraints can be made independent of the size of the computation, which improves efficiency, especially for large cryptographic computations.

[0028] In principle, computational costs can be determined in several ways, such as by simulating or measuring the real-time runtime of performing encrypted computations.

[0029] However, in one implementation, computational costs can be minimized based on a cost function. Similar to noise constraints, the cost function can also be based on the corresponding costs of the corresponding subgraphs, where the cost of a given type of subgraph is constrained by a cost function of a given type. This cost function can take at least the encrypted computational parameters of the given type as input. Using a cost function instead of simulation or measurement greatly improves the efficiency of optimization, not only because evaluating such a function is more efficient than performing simulation or measurement, but also because it allows the use of optimization techniques that depend on the function expression with the optimization objective, such as branch and bound methods using lower and upper bounds based on the function expression, optimization based on variable variation, or elimination of non-optimal solutions based on the independent variables of the function expression.

[0030] Specifically, in one implementation, the cost function of a subgraph of a given type can be independent of the instantiation parameters of that subgraph. In other words, the computational cost of a subgraph of a given type can be assumed to be independent of the instantiation parameters. In many cases, this is a reasonable approximation. For example, the noise bound of a subgraph may not affect its performance because it does not change how computation is performed, and the applied linear mapping may have only a limited effect, such as constituting at most 10% or at most 1% of the computational cost of performing the cryptographic computation corresponding to the subgraph. Interestingly, this approximation greatly simplifies the optimization problem because only a single instance of the cost function is needed to express the cost of the corresponding instance.

[0031] In one implementation, a subgraph can represent a subcomputation that produces an output ciphertext with noise independent of the input; that is, the noise is independent of the noise in the input ciphertext of the subgraph, and also independent of the number of linear operations, for example, applied to the noise in the subgraph. This output ciphertext can then be used as input to other subgraphs. This simplifies the optimization problem because it allows the noise constraints on the subgraph to be limited independently of a specific amount of noise in the input; in other words, the input noise does not need to be an instantiation parameter. Specifically, all inputs to the subgraph throughout the computation, or at least all inputs to subgraphs of a given type, can be assumed to have the same amount of noise. As illustrated by using the 2-norm and noise bounds as instantiation parameters, this can be particularly helpful in eliminating some noise constraints (which are less stringent than others).

[0032] Specifically, the subgraph may have a final portion that produces an output ciphertext with noise independent of the input: typically, blind rotation and sample extraction, optionally followed by rounding, as discussed in more detail elsewhere. Apart from this final portion, the subgraph typically does not include cryptographic operations that produce noise independent of the input. Specifically, the noise may monotonically increase in the subgraph until it reaches the final portion. This again simplifies the optimization problem, since determining the noise of the input to the final portion (which is the maximum noise during the sub-computation) and constraining this noise is sufficient to, for example, provide adequate accuracy.

[0033] In one implementation, the cryptographic computation parameters may include one or more of the following: a programmable bootstrap decomposition base, a programmable bootstrap decomposition level, a key-switching decomposition base, and a key-switching decomposition level. These parameters may be defined as global cryptographic computation parameters or may be specifically defined for a given type. A trade-off is made between the noise generated and the efficiency of performing the corresponding operations for these parameters. For example, increasing the level increases computational complexity but reduces noise. Furthermore, these operations constitute a significant portion of the total computational power of the cryptographic computation. Therefore, optimizing these parameters has a particularly significant effect on the resulting cryptographic computation.

[0034] Note that different types of subgraphs can share the same base and / or level parameters, corresponding to them using the same key switching key and / or bootstrap key. On the other hand, different subgraphs can have the same cryptographic structure but different base and / or level parameters, corresponding to performing the same operations but with different bootstrap keys and / or key switching keys. Therefore, by appropriately limiting the types and parameters, optimizations with an appropriate level of flexibility can be achieved.

[0035] In one implementation, the subgraph may include a programmable bootstrap that generates an output ciphertext, and noise rounding of the output ciphertext. In other words, the ciphertext can be rounded so that it encrypts the same value with different noise. Interestingly, by performing noise rounding, it is possible to make the programmable bootstrap deterministic, specifically, independent of the specific implementation of the Fast Fourier Transform (FFT) used in the programmable bootstrap.

[0036] The inventors note that, indeed, without rounding, at least several least significant bits representing ciphertext noise in the ciphertext typically depend on the rounding error of the FFT implementation used. While such rounding error may not affect the security or correctness of the cryptographic computation itself, it may still be desirable that the computation be deterministic. For example, it allows the same cryptographic computation to be performed by different parties, possibly using different software and / or hardware settings, and allows verification that the resulting ciphertexts are identical, thus providing some guarantee that the computation was performed correctly.

[0037] Specifically, in one implementation, cryptographic computation can be performed using blockchain mining equipment, while rounding allows the results of the cryptographic computation, as determined by the mining equipment, to be compared with each other without decryption. This enables agreement on the cryptographic output of the computation, thereby confirming that the intended cryptographic computation was indeed performed.

[0038] In one implementation, the optimization of the cryptographic computation parameters can be performed using the branch and bound method. Compared to brute force, the branch and bound method can perform optimization significantly more efficiently while ensuring that the possibly optimal values ​​of the cryptographic computation parameters are obtained.

[0039] In one implementation, optimization can be used to determine the key switching keys and / or bootstrap keys to be used for a corresponding subgraph. A predetermined number of key switching keys and / or bootstrap keys can be used. Each key adds a corresponding amount of noise and has a corresponding computational cost. The computational cost of adding less noise may be higher, requiring a trade-off. For a given subgraph, the cryptographic computation parameters can identify which predetermined key switching keys and / or bootstrap keys are used in the subgraph. Thus, for the corresponding subgraph, a corresponding optimal choice can be made, allowing for a better overall solution compared to using the same key switching keys and / or bootstrap keys throughout the cryptographic computation, or if the key switching keys and / or bootstrap keys for a given subgraph are predetermined.

[0040] Interestingly, optimizing the key-switching key and / or bootstrap key to be used for a corresponding subgraph can significantly reduce the parameter space of the parameters indicating the key to be used. That is, if the noise constraint of the first subgraph is at least as strict as that of the second subgraph, the key-switching key and / or bootstrap key of the first subgraph can be constrained to add at most as much noise as the key-switching key and / or bootstrap key of the second subgraph. Therefore, when subgraphs are sorted according to their noise constraints, selecting the key-switching key or bootstrap key essentially corresponds to a linear search of this sorted list (unlike selecting individually for each subgraph), making the optimization problem very efficient.

[0041] In one implementation, for a corresponding subgraph to which a corresponding linear mapping is applied, a cryptographic computation parameter can indicate the number of programmable bootstraps to be executed during the application of the corresponding linear mapping. By executing programmable bootstraps during the application of the linear mapping, noise can be reduced at the cost of significant computational cost. An optimal choice can be made for this trade-off by using the number of bootstraps as an optimizable parameter.

[0042] In one implementation, when at least one programmable bootstrapping is to be performed in a linear mapping, it can be automatically determined how to split the linear mapping into multiple linear mappings. As the inventors have realized, this can be done by minimizing the maximum 2-norm of the corresponding linear mapping. This is advantageous because it minimizes the noise following the corresponding linear mapping, making it easier to satisfy noise constraints.

[0043] Interestingly, the inventors realized that the parameter space of the parameter indicating the number of programmable bootstraps to be executed can be greatly reduced. That is, if the noise constraint of the first subgraph is at least as strict as that of the second subgraph, the number of programmable bootstraps in the first subgraph can be constrained to be greater than or equal to the number of programmable bootstraps in the second subgraph. Therefore, by sorting the subgraphs by noise constraints, searching for the optimal number of programmable bootstraps for each subgraph essentially corresponds to a linear search within this sorted list, unlike the individual selection of each subgraph.

[0044] In one implementation, the computation graph can be obtained by transforming an unencrypted computation graph. For this purpose, techniques known per se can be used. The transformation can directly output a computation graph for encrypted computation, such that the computation graph has been divided into multiple subgraphs. In one implementation, the computation graph for encrypted computation can be compiled into a set of instructions for an encrypted computation engine. The instructions can be based on determined encrypted computation parameters. Therefore, a compiler can be configured to take plaintext or ciphertext computation as input and output instructions for an encrypted computation engine that executes the given computation in an optimal manner. In one implementation, the encrypted computation can be executed based on determined encrypted computation parameters, which allows the encrypted computation to be executed in a combination of efficiency, accuracy, and security.

[0045] Typically, cryptographic computations can be performed within a TFHE setup. This means that the ciphertext used to encrypt the value allows for programmable bootstrapping computations. Specifically, the ciphertext can be LWE (Learning for Fault Tolerance) encryption, that is, encryption based on the cryptographic assumption that the learning for fault tolerance problem is difficult. As is known per se, programmable bootstrapping can evaluate LWE decryption in the exponent of a GLWE encrypted monomial, for example, implemented as a so-called blind rotation. Specifically, programmable bootstrapping can involve computing a cryptographic polynomial product of a bootstrapping monomial and a test polynomial, where the bootstrapping monomial represents the plaintext value as an exponent. The test polynomial can represent the evaluation value of a function and / or lookup table applied to the input via programmable bootstrapping. Programmable bootstrapping can use a bootstrapping key that enables programmable bootstrapping, rather than the decryption of the ciphertext.

[0046] The improved computational encryption technology provided can be applied to a wide range of practical applications. These applications include encrypted evaluation of software programs without access to plaintext data. For example, medical diagnostic software can be evaluated using medical data without access to that data. Medical data may include medical images. Medical images may include, for example, multi-dimensional image data, such as two-dimensional (2D), three-dimensional (3D), or four-dimensional (4D) images, obtained through various acquisition methods, such as, but not limited to, standard X-ray imaging, computed tomography (CT), magnetic resonance imaging (MRI), ultrasound imaging (US), positron emission tomography (PET), single-photon emission computed tomography (SPECT), and nuclear medicine (NM).

[0047] In one implementation, the provided techniques can be used to evaluate neural networks with regard to encrypted inputs. The party evaluating the neural network may or may not have access to the plaintext of the neural network's training parameters (e.g., weights and biases). Overall, the techniques provided herein (e.g., improved encrypted computation parameters) improve the efficiency of evaluating neural networks and / or reduce the storage and transmission requirements of the ciphertext or key material used.

[0048] Implementations of the method may be carried out on a computer as a computer-implemented method, or on dedicated hardware, or in a combination of both. Executable code for implementations of the method may be stored on a computer program product. Embodiments of the computer program product 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 implementations of the method when the program product is executed on a computer.

[0049] In one embodiment, the computer program includes computer program code that, when run on a computer, is adapted to perform all or part of the steps of the embodiment of the method. Preferably, the computer program is contained on a computer-readable medium. Attached Figure Description

[0050] Other details, aspects, and embodiments will be described by way of example only with reference to the accompanying drawings. For simplicity and clarity, elements in the drawings are illustrated and not necessarily drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. In the drawings,

[0051] Figure 1a An embodiment of one implementation of the configuration device is illustrated schematically;

[0052] Figure 1b An embodiment of one implementation of an encrypted computing device is illustrated schematically;

[0053] Figure 1c An embodiment of one implementation of an encrypted computing system is illustrated schematically;

[0054] Figure 2 A detailed embodiment of how to determine the parameters is shown;

[0055] Figure 3 A detailed embodiment of constraining ciphertext noise is shown;

[0056] Figure 4a A detailed embodiment of one type of subgraph is shown;

[0057] Figure 4b A detailed embodiment of ciphertext noise is shown;

[0058] Figure 4c A detailed embodiment of the encryption calculation parameters is shown;

[0059] Figure 5 A detailed embodiment for eliminating noise constraints is shown;

[0060] Figure 6a A detailed embodiment of one type of subgraph is shown;

[0061] Figure 6b A detailed embodiment of one type of subgraph is shown;

[0062] Figure 7a Detailed, but not limiting, embodiments for determining the key switching key and / or bootstrapping key to be used are shown;

[0063] Figure 7b A detailed embodiment for determining the number of programmable bootstraps is shown;

[0064] Figure 8 A detailed embodiment of a programmable bootstrap with noise rounding is shown;

[0065] Figure 9a An embodiment of one implementation of a method for determining cryptographic computation parameters is illustrated schematically;

[0066] Figure 9b An embodiment of one implementation of a cryptographic method for performing cryptographic computation is illustrated schematically;

[0067] Figure 10 A computer-readable medium having a writable component is schematically illustrated according to one embodiment;

[0068] Figure 11A representation of a processing system according to one implementation is shown schematically. Detailed Implementation

[0069] Although the subject matter disclosed herein may have many different implementations, the figures shown and described in detail herein represent one or more specific implementations. This disclosure should be understood as an example of the principles of the subject matter disclosed herein and is not intended to limit it to the specific implementations shown and described.

[0070] In the following text, for the purpose of understanding, the elements of the implementation scheme are described in the operation. However, it will be apparent that the corresponding elements are arranged to perform the functions described as being performed by them.

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

[0072] Several implementation schemes relate to the encryption computation of noisy ciphertext. When generating noisy encryption that produces unencrypted values ​​(in other words, when determining recently encrypted ciphertext), the noise used can be obtained from a distribution denoted as χ(σ), parameterized by the parameter σ. As an example, the distribution χ can be a central normal distribution, and the parameter σ can be the standard deviation.

[0073] When encryption operations are performed on ciphertext, the noise it contains is typically modified as a side effect. The relationship between the input noise and the output noise of the operation can be represented by a noise formula. This formula models the evolution of noise as a result of the operation. Specifically, the noise distribution within the ciphertext typically changes during the operation. Specifically, if the noise within the ciphertext comes from a normal distribution with a large standard deviation σ, then the ciphertext can be said to contain more noise than another ciphertext.

[0074] Specifically, several implementations use LWE (Learning Tolerant Message) encryption. Typically, LWE ciphertext may include one or more mask values ​​and a body value derived from the mask values, plaintext value, and key, and the body value includes noise. The value is typically an integer modulo a given modulus q. Several implementations also use GLWE (Generalized Learning Tolerant Message) ciphertext. GLWE ciphertext may include one or more mask polynomials and a body polynomial derived from the mask polynomial, plaintext polynomial, and key, and the body polynomial includes polynomial noise. GLWE ciphertext can be defined as modulo a modulus q and a quotient polynomial p(X). LWE ciphertext can be considered a specific type of GLWE ciphertext where the quotient polynomial has an order of 1. Another specific type of ciphertext is RLWE (Ring Learning Tolerant Message) ciphertext, where the number of mask polynomials is 1.

[0075] Specifically, based on the key News The GLWE ciphertext can be limited as follows:

[0076]

[0077] here, It is the key, where the coefficients are sampled from, for example, a uniform binary distribution, a uniform ternary distribution, or a Gaussian distribution. It is the appropriate encoding of the input message (e.g., scaling). yes A polynomial within, where the coefficients are, for example, from Sampling is performed in a uniform distribution within the range, where E is The noise (error) polynomial within the range, such that its coefficients are derived from, for example, a Gaussian distribution χ. σ Medium sampling. The parameter k is a positive integer representing the number of polynomials in the GLWE key. To simplify the notation, S... k+1 It can be limited to -1. In this embodiment, the LWE ciphertext is the GLWE ciphertext, where N = 1. In this case, the parameter n = k can represent the size of the LWE key, and both the ciphertext and the key can be represented in lowercase, for example, ct q And s. In this embodiment, the RLWE ciphertext is the GLWE ciphertext, where k = 1 and N > 1, for example, powers of 2.

[0078] Typically, the security of GLWE-type encryption depends on the key distribution (e.g., binary, ternary, or Gaussian distribution), the product k·N of the GLWE dimension k and the polynomial size N; the amount of noise in the recent ciphertext; and the modulus q. Given these parameters, it is known how to evaluate the 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 (included in this paper by reference), and evaluator software is available at https: / / github.com / malb / lattice-estimator. In summary, the larger the product k·N, the smaller the minimum noise required for security.

[0079] It can be noted that, due to the relationship between the GLWE dimension k, polynomial size N, and standard deviation σ of the Gaussian noise (e.g., the minimum noise for a given level of security), one of these variables can be calculated from the others. Specifically, throughout this specification, given a specific distribution of the key (e.g., binomial, trinomial, or Gaussian), the product k·N, and the security level λ, the minimum noise achieving a certain security level in the recently encrypted text can be calculated as:

[0080] Although the integer q is used throughout this specification to represent the ciphertext modulus, it should be noted that multiple ciphertext moduli can be used in encrypted multiplication, for example, modulus switching is used to align ciphertexts according to the same q when needed.

[0081] The above embodiments describe a key, a symmetric variant of GLWE. As is known per se, the techniques presented herein are equally applicable to public-key variants. In the latter case, for example, the key above can be used as a private key, where the public key comprises encryption of one or more 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).

[0082] Multiple implementations operate within a TFHE setup, implying the use of ciphertext supported by Programmable Bootstrapping (PBS). A programmable bootstrapping system takes ciphertext as input and outputs ciphertext of the same message, or a function and / or lookup table of that message, with noise independent of the input. PBS may include homomorphic decryption of the input ciphertext in the exponent of an evaluation polynomial. The following references provide embodiments of encryption schemes in a TFHE setup, which may be combined with the techniques presented herein:

[0083] -[DM15] L.Ducas et al., "FHEW: bootstrapping homomorphic encryption in less than a second", proceedings EUROCRYPT 2015;

[0084] -[CGGI16]I.Chillotti et al., "Faster fully homomorphic encryption:Bootstrapping in less than 0.1seconds", proceedings ASIACRYPT 2016;

[0085] -[CGGI17] I. Chillotti et al., "Faster packed homomorphic operations and efficient circuit bootstrapping for TFHE", proceedings ASIACRYPT 2017.

[0086] Throughout this specification, plaintext can be represented as integers modulo q. These integer modulo values ​​can be equivalently considered as elements of a discrete torus, as done in several of the references mentioned above. Specifically, several references use a real torus. To represent the message space and ciphertext space, and using the arithmetic modulus 2 32 Or 2 64 To implement The discretization. This can be equivalently viewed as corresponding to using Integers in (use q=2 32 Or q = 2 64 The calculation is performed. Therefore, it is alternatively possible to use integers modulo the given modulus and the discrete torus elements, specifically, in and There are isomorphisms, as also noted in the literature, for example, see C. Boura et al., “CHIMERA: Combining Ring-LWE-based Fully Homomorphic Encryption Schemes”, J. Math. Cryptol., 14(1): 316-338, 2020.

[0087] The programmable bootstrapping operations in TFHE-type schemes make them an attractive option for a wide range of applications. Because bootstrapping is relatively efficient compared to many other FHE schemes, performing relatively complex computations (e.g., with multiplication depths of at least 10, 50, or 100) is more feasible. Specifically, the cryptographic parameters of TFHE-type schemes can be chosen based on the desired precision and the computational cost incurred, without increasing the amount of homomorphic operations or circuit depth. In contrast, bootstrapping can be very inefficient in other FHE schemes, leading these schemes to be typically applied in a balanced manner, meaning their parameters are chosen based on the given computation, allowing them to be performed without bootstrapping. However, such a balanced approach is not feasible for more complex computations, making TFHE-type schemes particularly advantageous in such cases.

[0088] In the embodiments described herein, the parameters of the TFHE class based on LWE and GLWE ciphertexts can be selected based on the desired level of security and the accuracy of the desired operations (such as linear combinations of LWE ciphertexts and / or the application of programmable bootstrapping) (in other words, the noise level generated by applying these operations). Interestingly, in the TFHE setting, the security parameters can be selected independently of the size of the computation (e.g., independent of the multiplication depth of the computation). This differs from non-TFHE class schemes, where security parameters are typically selected to limit or eliminate bootstrapping.

[0089] Specifically, the LWE-based and / or GLWE-based ciphertext used in the TFHE setup described herein may use a relatively small modulus (e.g., at most 32 bits, at most 64 bits, or at most 128 bits). This modulus is typically chosen independently of the computation to be performed; for example, it depends on the desired precision and / or efficiency. Parameters N, k, and / or σ may be predefined or may be the optimized output described herein. For example, N may be set to at least 512 and / or at most 2048, 4096, or 16384, such as 1024. For example, in one embodiment, RLWE is used, where N is at least 512 and / or at most 2048 or 4096, such as 1024, and k = 1. This value of N is typically not used in non-TFHE cryptographic schemes, where it would severely limit the computations that can be performed; instead, in non-TFHE cryptographic schemes, q and N are typically chosen based on the desired level of security, allowing q to be larger.

[0090] Throughout this instruction manual, the term "standard score" may be used as follows: Let be the error probability, and Φ be the CDF of A. err The standard score can be limited to

[0091]

[0092] Make

[0093]

[0094] Standard scores can be applied to confidence intervals for a centrally normal distribution as follows: Let... And p err ∈[0, 1]. Let z * (p err ) is p err The standard score. Therefore:

[0095]

[0096] Figure 1a An embodiment of one implementation of the configuration device 110 is illustrated schematically. The device 110 can be used to determine encryption calculation parameters to perform encryption calculations on noisy ciphertext.

[0097] Device 110 may include processor system 130, memory 140, and communication interface 150. Memory 140 may include local memory, such as a local hard disk drive or electronic memory. Memory 140 may also include non-local memory, such as cloud storage. In the latter case, memory 140 may include a memory interface to non-local memory. For example, memory 140 may be used to store data representing a computation graph of cryptographic computation. In this representation, the computation graph may be divided into multiple subgraphs. Subgraphs may be defined by one or more types and by zero or more instantiation parameters of said type.

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

[0099] In device 110, communication interface 150 can be used to send or receive digital data. For example, device 110 can be configured to receive or send data representing a computation to be performed in encrypted form. For example, device 110 can obtain data representing an unencrypted computation or a computation graph of an encrypted computation, wherein the data of the computation graph of the encrypted computation may optionally be divided into multiple subgraphs upon reception, as already described herein. Device 110 can determine encrypted computation parameters to optimally perform this computation in encrypted form. Device 110 can send data representing the encrypted computation parameters, specifically, instructions for the encrypted computation engine to perform the computation in encrypted form according to the determined encrypted computation parameters.

[0100] Execution of device 110 may be implemented in processor system 130 (e.g., one or more processor circuits (e.g., multiple microprocessors)), embodiments of which are shown herein. Device 110 may include multiple processors, which may be distributed in different locations. For example, device 110 may use cloud computing.

[0101] Processor subsystem 130 can be configured to define corresponding sets of encryption computation parameters for a given type. Processor subsystem 130 can be further configured to perform optimization of the encryption computation parameters, including corresponding sets of encryption computation parameters for the given type. In this optimization, the encryption computation parameters can be optimized to minimize the computational cost of performing encryption computation based on the encryption computation parameters. Additionally, in this optimization, the encryption computation parameters can be constrained to satisfy noise constraints on ciphertext noise when performing the encryption computation. The noise constraints can be based on corresponding noise constraints of a corresponding subgraph. The noise constraints of a subgraph of a given type can be defined by a noise constraint function of the given type, which takes at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input.

[0102] Some diagrams illustrate functional units, which can be functional units of a processor system. For example, the diagram can be used as a blueprint for the possible functional organization of a processor system. In most diagrams, the processor circuitry is not shown separately from the units. For example, in... Figure 2 The functional units shown in -6 (see below) may be implemented wholly or partially as computer instructions stored in a device such as device 110 (e.g., stored in the electronic memory of device 110) and executable by the microprocessor of device 110. In a hybrid implementation, the functional units are implemented in part in hardware (e.g., a coprocessor, such as an arithmetic and / or cryptographic coprocessor) and partially stored in software and executed on device 110.

[0103] Figure 1b An embodiment of one implementation of an encrypted computing device 119 is schematically illustrated. The encrypted computing device 119 can be used to perform encrypted computations. The encrypted computations may use homomorphic cryptography. For example, the device 119 can be used to perform encrypted computations 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 device can still perform the computation. The computation is performed according to encrypted computation parameters determined as described herein, for example, by... Figure 1a Device 110. Device 119 can determine its own parameters; for example, device 119 can interact with... Figure 1a The equipment is a combination of 110.

[0104] Device 119 may include a processor system 139, a memory 149, and a communication interface 159. The processor system 139, memory 149, and communication interface 159 may be configured as follows: Figure 1aThe corresponding components are discussed in the implementation. The memory 149 can be used to store a representation of the cryptographic computation to be performed, and / or cryptographic computation parameters on which the cryptographic computation is based. Therefore, the device 119 may include the memory 149 storing cryptographic computation parameters. The cryptographic computation parameters may be included in the representation of the cryptographic computation.

[0105] For example, memory 149 may store computed (e.g., received from one or more data providers, or generated as an intermediate or final result (e.g., output)) encrypted data items. Typically, most or all of the data items (for which device 119 performs computations) are encrypted using a key (or multiple keys) unknown to device 119. That is, device 119 may be configured not to obtain plaintext data items corresponding to (e.g., such as those stored in memory 149) encrypted data items. For device 119, the decryption key in plaintext form is a secret, although the encryption / decryption key may be obtained in encrypted form.

[0106] The communication interface 159 can be used to receive a representation of a cryptographic computation to be performed and / or cryptographic computation parameters on which the computation is based. The communication interface 159 can be further configured to receive cryptographic data (on which computation is performed). The communication interface 159 can be further used to send cryptographic output generated from the cryptographic computation.

[0107] Processor subsystem 139 can be configured to perform cryptographic computations. This can be done in a manner known per se in the art. Interestingly, because processor subsystem 139 uses cryptographic computation parameters as described herein, improved cryptographic computations (e.g., with improved computational efficiency) can be performed, as discussed throughout this specification.

[0108] As an alternative to or supplement to using the cryptographic computation parameters as described herein, processor subsystem 139 may apply noise rounding operations to outputs with implementation-related noise (e.g., programmable bootstrapping, e.g., relative to...). Figure 8 The ciphertext (as discussed).

[0109] Figure 1c An embodiment of one implementation of a cryptographic computing system 100 is illustrated schematically. The system 100 is configured to perform cryptographic computations using homomorphic encryption (e.g., fully homomorphic encryption).

[0110] System 100 in this embodiment includes a compiler device 111, a data provider device 113, and a cryptographic computing device 112. The compiler device 111 may be combined with either the cryptographic computing device 112 or the data provider device 113 in a single device. 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 other data items may be received in plaintext form. Device 112 may be configured to receive a homomorphic executable file from the compiler device 111 for performing cryptographic computations.

[0111] Device 112 can perform computations as described herein on received data items and, possibly, on stored data items. Interestingly, computations can be performed on encrypted data by the device without decrypting the data, for example, without needing to convert the encrypted data items into plaintext form.

[0112] Interestingly, device 112 can perform cryptographic computation based on cryptographic computation parameters determined as described in this specification. For example, the cryptographic computation parameters can be determined by compiler device 111, such as a homomorphic executable file, based on the cryptographic computation parameters. In this case, compiler device 111 can be based on... Figure 1a The device 110, for example, may include... Figure 1a The processor system 130, memory 140, and / or communication interface 150. In principle, it may also determine the cryptographic calculation parameters to be performed by device 112 or device 113 or different devices; however, in this case, the device may be based on... Figure 1a Device 110. Device 112 can be based on Figure 1b Device 119, such as device 112, may include Figure 1b The processor system 139, memory 149 and / or communication interface 159.

[0113] Optionally, compiler device 111 or data provider device 113 may be further configured to generate key material for cryptographic computing device 112 to perform cryptographic computations, such as including a bootstrap key for performing programmable bootstrap as discussed herein. The device generating the key material may provide the bootstrap key 151 to device 112, for example, by sending it via computer network 150, uploading it to shared storage, etc. The key material may also be generated by a separate key generation device (not shown in this figure).

[0114] Although not shown in this figure, the encrypted computing system 100 may include multiple encrypted computing devices, for example, two, three, or more than three. Encrypted computing can be distributed across multiple encrypted computing devices. The encrypted computing devices can exchange intermediate computing results (typically encrypted) with each other. Each encrypted computing device may be implemented as encrypted computing device 112 and may perform the encrypted operations described herein.

[0115] Homomorphic encryption schemes can be applied in many settings. For example, encrypted computing device 112 can operate via a cloud provider. The cloud provider can provide computing and storage services to its clients. By employing homomorphic encryption, data provider device 113 (e.g., a client of the cloud provider) can send its data in encrypted form. The cloud provider can still perform the required computations and / or storage, but cannot know the corresponding plaintext data. For example, data provider device 113 can encrypt data items using an encryption key of a type corresponding to the specific homomorphic encryption system used. When the data provider 113 receives the computation result from encrypted computing device 112, the corresponding decryption key can be used to decrypt the encrypted data item. The encryption key and the decryption key can be the same, and typically are.

[0116] For example, the encrypted computing system 100 can be configured to train a machine learning model (e.g., an image classifier, or a medical model) without the encrypted computing device having access to plaintext data items. For example, linear regression can be performed on the input data, even without bootstrapping. Backpropagation can be performed on the input data, for example, with bootstrapping. The resulting model parameters can be returned to an entity possessing the decryption key. This allows multiple providers of medical data to aggregate their data by sending it to a cloud provider. The cloud provider then returns the model parameters without ever using the plaintext data. The encryption key can be equal to the decryption key.

[0117] After the model is trained, the encrypted computing system 100 can be used to provide the model (e.g., for use with medical data). This can be done with plaintext model parameters or encrypted model parameters, in both cases using encrypted data (e.g., encrypted input data, intermediate data, and data from the input). Using plaintext model parameters is generally more efficient. In both cases, the system's effect is to perform computations (e.g., image classification, such as medical image classification) without the computer knowing the plaintext data items. For example, a mammogram can be used to assess cancer without the image appearing in plaintext at the encrypted computing device 112, and without any encrypted computing device 112 or a combination of such devices knowing the outcome of the cancer assessment. From a privacy perspective, running a plaintext model on encrypted privacy-sensitive data is acceptable, while running it on plaintext privacy-sensitive data is unacceptable.

[0118] Other applications involve database services, such as searching for encrypted data in an encrypted database; for example, computations may involve comparing input items with database items. For example, multiple computations may be combined to produce a database index that matches an index. For example, the database may be a genomic database, and the input may be a gene sequence. For example, system 100 may be used for the protection and control of devices. For example, a device (even a large device such as a power supply) may send sensor values ​​to encrypted computing device 112 and receive encrypted control signals in return. The control signals are calculated based on the sensor signals. An attacker of the system may be able to determine the content of data going to and from one or more encrypted computing devices 112, or even have access to intermediate data of these devices, but the attacker will not be able to benefit from said data because it is encrypted. Even if all the encrypted computing devices 112 of system 100 are completely compromised, the data will not be disclosed because the decryption key is unknown to these devices. Computing control signals may involve mathematical operations such as linear algebra, averaging, matrix multiplication, polynomial evaluation, etc., all of which can be performed using homomorphic encryption.

[0119] For example, a pool of encrypted data items can be maintained in a cryptographic computing system; a subset of these can be received, and another subset can be the result of the cryptographic computation (e.g., an intermediate result). For example, cryptographic computing device 112 can be configured to apply homomorphic encryption operations to one, two, or more encrypted data items in the pool (e.g., a set of input values ​​and / or intermediate values ​​and / or output values). The result can be a new encrypted data item, which can be stored in the pool. The pool can be stored in the memory of the cryptographic computing system. This can be local memory or distributed memory. In the case of distributed memory, it is possible that one or more encrypted data items in the pool can be represented multiple times. Encrypted data items can be sent from one computing device to another, for example, if the value of the encrypted data item is needed elsewhere. The pool can be implemented in various ways, such as as a register file, an array, various data structures, etc.

[0120] Encrypted data items can represent all types of data. For example, an encrypted data item can represent numbers that need to be averaged, or numbers used for linear regression, etc. For example, an encrypted data item can represent an image. For example, each pixel of the image can correspond to one or more encrypted data items. For example, a grayscale pixel can be represented by a grayscale value, and that grayscale value can be represented by a single encrypted data item. For example, 256 grayscale values ​​can be encoded in a single encrypted data item. For example, a colored pixel can be represented as multiple color values ​​(e.g., RGB values), which can in turn be represented by tuples of encrypted data items. For example, three 256-value colors can be encrypted into corresponding encrypted values.

[0121] A set of homomorphic encryption operations can be defined for computation. For example, a computation graph (also referred to as an operational circuit or operational network) for encrypted computation can be constructed based on the homomorphic encryption operations, the computation being carried out jointly by compiler device 111 or by computing device 112 itself. For example, the operations may include Boolean operations. The way homomorphic encryption operations are combined (e.g., which operation is applied to which operand in the pool) determines the computation being performed. For example, the computation may be represented as a list of homomorphic encryption operations to be performed along with instructions on which encrypted data item to perform the homomorphic encryption operation on, thereby implicitly defining the computation graph through their input / output relationships.

[0122] Figure 2 A detailed, non-limiting embodiment of how to determine encryption computation parameters for performing encryption computations on noisy ciphertext is shown.

[0123] As illustrated in the figure, cryptographic computation can be considered to correspond to a cryptographic computation graph ECG,230 (also known as "FHEDAG"). The cryptographic computation graph ECG can be explicitly represented in memory or implicitly represented (e.g., as executable code, as a series of instructions, etc.). The cryptographic computation graph ECG can be a directed acyclic graph of cryptographic operations, also known as the "FHE operator". A cryptographic operation can take one or more ciphertexts and / or plaintexts as input and provide one or more ciphertexts as output.

[0124] under, It is used to represent the FHE graph EGC composed of FHE operators. Mathematically, Can represent the FHE operator A directed acyclic graph (DAG) in which It is a set of vertices, and is the FHE operator; and E is A set of edges. For ease of explanation, if the set of edges E is not needed, the graph can be represented by a set of its vertices. To identify.

[0125] For example, the FHE operator can represent homomorphic addition (of ciphertext and / or plaintext), homomorphic multiplication with plaintext values, key switching, modulus switching, blind rotation, sample extraction, etc. In many embodiments, for simplicity, blind rotation and sample extraction are represented together as a single FHE operator because these typically occur together in cryptographic computation.

[0126] Optionally, the encrypted computation graph ECG can be obtained by performing a compilation COMP, 220, which takes an unencrypted computation graph PROG, 210 as input and transforms the graph into an encrypted computation graph ECG. The compilation COMP can be applied to the graph PROG of the plaintext operator. By using the provided technique, this graph PROG can be transformed into a corresponding graph ECG with a correct and optimized set of ECP, 280 parameters for the FHE operator.

[0127] In the graph PROG, a plaintext operator can be an operator that performs operations on data marked as confidential and / or data marked as plaintext and outputs confidential data. The data marked as confidential can be encrypted in the resulting encrypted computation. For example, some or all plaintext operators can be selected from the following:

[0128] • Addition between confidential data;

[0129] • Addition between confidential data and plaintext data;

[0130] Multiplication between confidential data;

[0131] Multiplication between confidential and plaintext data; and

[0132] • Application of univariate functions.

[0133] Compiling COMP maps plaintext operators to a set of one or more corresponding FHE operators. Both the plaintext operators and the set of FHE operators can compute the same operations, with the former operating on both plaintext and encrypted data, and the latter on both plaintext and ciphertext. For this purpose, techniques known in the art can be used. Interestingly, the techniques described herein can be used to discover optimal cryptographic computation parameters in order to generate a graph ECG.

[0134] In the division operation DIV, the calculation graph is... ECG can be divided into multiple subgraphs. Subgraphs can be defined by one or more types from a set of types, and by zero or more instantiation parameters of said type. Subgraphs of a particular type may have in common the application of the same FHE operators in the same order. For this purpose, several additions and scalar multiplications can be collectively considered as a single FHE operator representing a linear mapping, as in... Figure 4a And as illustrated elsewhere. For example, in the case where the subgraph includes a linear mapping, the applied linear mapping (or its 2-norm, which has been shown to be sufficient to perform various optimizations) can be one of the instantiation parameters. One type of subgraph is also known as an atomic pattern (AP) class.

[0135] Examples of various types of subgraphs, for example, regarding Figure 4a , Figure 6a and Figure 6b This is under discussion. A common feature of certain types of subgraphs is that they use the same key material for a particular FHE operator (such as key switching or blind rotation); however, the key material can also be used as a parameter, such as, for example, regarding... Figure 7a The subject of discussion.

[0136] Specifically, a subgraph can represent a subcomputation that yields an output ciphertext with noise independent of the input. For example, the output ciphertext can be the output of a programmable bootstrap or the output of a programmable bootstrap that has been rounded. Therefore, by dividing the encrypted computation graph ECG into multiple subgraphs that yield noise independent of the input at the outputs of corresponding multiple sets of operations (e.g., in the case of blind rotation + sampling, or blind rotation + sampling + rounding), the division operation DIV can be performed on the graph.

[0137] As an example, the diagram illustrates a cryptographic computation graph ECG comprising three subgraphs S1,231, S2,232, and S3,233. In this embodiment, subgraphs S1 and S3 share the same first type T1,258, and subgraph S2 has a second type T2. Therefore, by instantiating parameters IP-S1,251 and IP-S3,253 to instantiate the first type T1 to obtain the corresponding subgraphs S1 and S3, and by instantiating parameter IP-S2,252 to instantiate the second type T2 to obtain subgraph S2, the representation REP,250 of the cryptographic computation graph can be obtained by dividing DIV.

[0138] The number of subgraphs can be relatively large, for example, at least 100, at least 1000, or at least 10000. For example, the number of different types of subgraphs appearing in a given cryptographic computation graph is typically limited to 1, at most or at least 2, or at most or at least 3. The graph can be divided into multiple subgraphs; for example, each node of the graph may appear in only one subgraph. The number of instantiation parameters for a subgraph type can be, for example, 0, 1, 2, at most or at least 3, or at most or at least 5. Different types of subgraphs can have different numbers of instantiation parameters. Several embodiments are given throughout this specification.

[0139] Typically, the way the FHE operation of the cryptographic computation graph ECG is performed can depend on the values ​​of a set of cryptographic computation parameters ECP,280.

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

[0141] The cryptographic computation parameters ECP may further include corresponding cryptographic computation parameters ECP1,285 and ECP2,289 for types T1 and T2. For example, these parameters may include the decomposition base of programmable bootstrapping and / or key switching appearing in the subgraph of the said type. and / or decomposition hierarchy Specifically, the values ​​of these parameters can differ for different types of subgraphs, although they can also be shared between different types. However, the cryptographic computation parameter ECPi is shared between different subgraphs of the same type, thus simplifying the optimization of the cryptographic computation parameters compared to defining these parameters separately for individual FHE operations or subgraphs.

[0142] The cryptographic computation parameter ECP may further optionally include corresponding subgraph-specific parameters ECP-S1,281, ECP-S2,282, and ECP-S3,283 for the corresponding subgraphs S1, S2, and S3. Such parameters can, for example, identify a set of bootstrapping or key-switching keys to be used in the subgraph (e.g., regarding...). Figure 7a As illustrated), and / or instruct several programmable bootstraps to be executed as part of a linear mapping (as per the example). Figure 7b exemplified).

[0143] Specific subgraph parameters ECP-Si typically do not provide values ​​for cryptographic parameters such as the factorization base or factorization level: these are typically limited to specific types of cryptographic computation parameters ECPi or even the global cryptographic computation parameter ECPG. This improves the efficiency of optimization and also limits the number of different values ​​such parameters can have, thereby limiting, for example, the number of different key switches and bootstrap keys required to perform cryptographic computations.

[0144] To determine the value of the cryptographic computation parameter ECP, optimization OPT,223 can be performed. This optimization can be configured to find the value used for the cryptographic computation parameter ECP, which allows cryptographic computation to be performed based on the cryptographic computation parameter x. computational cost Minimize, while ensuring the desired level of security and the correctness of the calculation results (up to a given probability).

[0145] By constraining the encryption computation parameters to meet noise constraints on the ciphertext noise that occurs during encryption computation, optimizing OPT ensures both security and correctness. Several embodiments for establishing such noise limits are provided. Figure 3 It was discussed.

[0146] Specifically, by setting the noise of the recently encrypted ciphertext based on the security parameters of the encryption scheme, a noise bound can guarantee the desired security level, thus providing the desired security level. Specifically, as discussed elsewhere, given a security level λ and cryptographic parameters k·N (e.g., included in the global parameters EPG), the noise of the recently encrypted ciphertext can be mapped... Given that the mapping is constrained to ensure that the newly generated ciphertext contains sufficient noise to hide the plaintext, in other words, by not treating the encryption noise as a variable, but rather as the output of a mapping for a given security level, it can be ensured that the security will be at least the required value.

[0147] Regarding the correctness of the calculation results, it is noted that if the ciphertext noise increases above a threshold, decryption will no longer be able to return the correct plaintext with sufficient probability. This threshold for the amount of ciphertext noise can be called the noise bound. The noise bound can be global or can differ between multiple parts of the computation, depending on the desired precision at a certain moment during the computation, in which case it can be limited, for example, based on the instantiation parameter IP-Si of the subgraph. The noise bound can be specified manually or calculated, for example, based on the desired precision (e.g., representing the number of bits required to encrypt the value) and the maximum expected probability of decryption error.

[0148] Typically, the optimization problem (the optimization problem to find a solution using OPT) can be constrained as follows: For a given encryption computation parameter x, a corresponding set of possible values ​​can be constrained, denoted as ε. x And this is called the search space of x. The search space is usually discrete. The Cartesian product of the search space can be represented as... It can also be called a cryptographic computation graph. The search space. For the sake of brevity, figures are often omitted in this specification. Meanwhile, the search space of the encrypted computation graph is denoted as ε.

[0149] Typically, some solutions in the search space generate too much noise. The noisy feasible set is limited to a set of cryptographic computation parameters (ECPs) that satisfy the noise constraints, for example:

[0150]

[0151] in, It is the FHE operation The noise of the output ciphertext, and t(p) i ) 2 It is the corresponding noise limit, for example, limited to about Figure 3 The topics discussed. Also, regarding... Figure 3 As discussed, it is noted that the noise bound t(·) can be implicitly incorporated into the maximum expected error probability of decryption.

[0152] In addition to noise constraints, there may be further constraints whereby the optimized OPT is configured to take into account limitations on the size of the public key and / or ciphertext. These constraints may, for example, be related to one or more cryptographic computation parameters. Typically, such additional constraints can limit further feasible sets.

[0153] Therefore, the optimization problem can be expressed as:

[0154]

[0155] In summary, expressed in this way, the optimization problem described above has a large search space ε (the number of variables is exponentially distributed) and a noisy feasible set. Given the search space ε, it is not easy to find the feasible set of noise.

[0156] Interestingly, the optimization problem can be simplified by partitioning the computation graph into multiple subgraphs of corresponding types. Specifically, if the solution lies in the feasible set... In this case, this partitioning can reduce the computational cost of testing.

[0157] Specifically, noise constraints can be defined as corresponding noise constraints based on the corresponding subgraph Si. Here, the noise constraints on the subgraph Si of a given type Tj can be defined by noise constraint functions NCF1,268 and NCF2,269 for given types T1 and T2. The noise constraint function NCFj can take at least the encryption calculation parameter ECPj of the given type Tj and the instantiation parameter IP-Si of the subgraph Si as input.

[0158] More precisely, the noise constraint can be defined as

[0159]

[0160] Here, subgraph A i noise constraint Subgraph A for the type described above i The noise constraint function is used to limit it.

[0161] In general, noise constraints for a type of subgraph can be obtained by propagating a noise estimate of the input to the subgraph through the computation of the subgraph. Generally, if a graph ECG is divided into subgraphs with input-independent noise outputs (e.g., PBS outputs or rounded PBS outputs), the input to the subgraph can be assumed to have fixed noise (e.g., derived from the global encryption computation parameters ECPG), and this noise can be assumed to increase across all subgraphs, such that noise constraints can, for example, constrain the noise of the input to the PBS (or other noise-fixed computations) to be sufficiently small to ensure adequate accuracy. Regarding Figure 4b A detailed implementation example is given.

[0162] Interestingly, noise constraints on corresponding subgraphs of the same type are thus limited by the same function NCFj, making the satisfaction of these constraints easier to simplify manually or automatically. Specifically, a constraint elimination operation CE,222 can be performed, where the noise constraints for the first subgraph Si1 can be determined to be at least as strict as the noise constraints for the second subgraph Si2 based on the instantiation parameters IP-Si1 of the first subgraph and IP-Si2 of the second subgraph. This can be the case not only when the subgraphs are of the same type, but also when the subgraphs are of different types. In any case, in such a case, the noise constraints for the second subgraph can be eliminated from the optimization, making the optimization Opt easier to perform. In other words, the noisy feasible set It can be a subset of each corresponding feasible set of the subgraph, so noisy feasible sets (as supersets of another noisy feasible set) do not affect The calculation. Regarding... Figure 5 A detailed embodiment of this is given.

[0163] Note that if another feasible set is used The same technique can also be used to eliminate constraints for the corresponding subgraph from the computation of the feasible set.

[0164] Typically, optimizing OPT can assess the computational cost of performing cryptographic computation in various ways, such as by performing simulations or by measuring the actual computational cost of performing cryptographic computation.

[0165] A particularly effective way to evaluate computational costs is by using cost functions that can be calculated based on cryptographic computational parameters ECP without simulation or measurement (e.g., as a closed formula). Specifically, the cost function can be based on the corresponding cost of the corresponding subgraph. This cost for a subgraph of a given type Tj can be defined by cost functions CF1,278 and CF2,279 for given types T1 and T2. The cost function typically depends on the cryptographic computational parameters ECPj for a given type Tj, which allows for optimization of these parameters ECPj with respect to the cost function.

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

[0167] As an illustrative example, the subgraph types considered include linear mappings (in other words, polynomial sums), key switching, modulus-to-digital switching, blind rotations, and sample extraction. Generally, these corresponding operations have corresponding costs, which depend at least on the cryptographic computation parameters ECP. For key switching, modulus-to-digital switching, blind rotations, and sample extraction, the cost function typically does not depend on the instantiation parameters.

[0168] For a linear mapping, the cost function can be constrained 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 not depend on the linear mapping.

[0169] In the first case, it is possible to simplify the optimization problem solved by optimizing OPT because the cost of the linear mapping does not depend on the number of additions / multiplications, but only on the non-specific instance parameters ECPG and ECPi. For example, the cost of the subgraph can be limited to the sum of the costs of the corresponding operations, which does not depend on the instantiation parameters:

[0170]

[0171] therefore, The cost of different subgraphs of the same type is the same. Therefore, optimization...

[0172]

[0173] This can be simplified into an optimization problem:

[0174]

[0175] The cost function can be limited to the sum of the costs of corresponding subgraphs, but this is not required. More generally, the cost can be limited by combining the costs of corresponding subgraphs or subgraph types. Similarly, the cost Cost(A(v,t),x) or Cost(A(·,·),x) of a particular subgraph does not necessarily have to be the sum of the costs of the corresponding operations. For example, the cost of a subgraph can be limited to a polynomial in the costs of the corresponding operations of the subgraph. This more general cost function can, for example, be optimized for latency, where the cost function can be configured to take into account several operations and / or several subgraphs of subgraphs that can be evaluated in parallel.

[0176] In general, there are many different ways for the optimizer OPT to determine the cryptographic computation parameters ECP. For example, the optimizer can perform a brute-force search. Interestingly, this is particularly feasible when performing constraint elimination CE, as described in this paper.

[0177] The preferred method for determining the cryptographic computation parameter ECP is through branch and bound. As is known by itself, branch and bound can find the optimal solution for computational cost based on a given upper and lower bound. Given these bounds, branch and bound can be more efficient than brute-force search.

[0178] Specifically, the branch and bound method can be performed by first efficiently finding a set of feasible parameters, and then using the feasible parameters to derive the lower bound and / or upper bound.

[0179] As an example, consider cryptographic computation graphs including Figure 4a One or more subgraphs of the type illustrated herein. As discussed with respect to this graph, such a subgraph can be represented as A. i =A(v i , t i ), where v i It is the 2-norm of the applied linear mapping, and t i It is the noise limit. This is achieved by using a single subgraph A(ν) max , t min (where ν) max ==max{ν i} i∈I And t min =min{t i} i∈I Replacing all subgraphs of this type yields a set of feasible parameters. By constructing this graph, it is guaranteed that the optimization problem can be solved on this graph. The output is used to power the input graph. A feasible solution can be found. Therefore, the optimization problem can be solved on this graph to store the optimal parameters.

[0180] For a given cryptographic computation graph (in And t i ∈I p A table of feasible parameters can be constructed by performing optimization Opt on the corresponding subgraphs. In other words, a table of feasible parameters can be constructed for the corresponding subgraphs. (where ν∈I) norm And t∈I p Solving optimization problems, for example, solving the optimization problem |I norm |·|I p | times. In this way, for the corresponding pair (v, t), multiple sets of acceptable parameters can be determined.

[0181] Specifically, to perform subgraph optimization, lower and upper bounds derived from the noise model and cost model can be used. As an illustrative example, for the noise function... The following lower limits can be used:

[0182] Given a table with known feasible parameters, the table can be used to efficiently obtain the encrypted computation graph. (where v) max =max{v i} i∈I And t min =min{t i} i∈I The table defines an upper and lower bound for the optimization. Furthermore, the initial solution used for optimization can be determined based on this table. Interestingly, the table allows for the efficient determination of relatively good initial solutions, which improves the efficiency of the optimization.

[0183] As an exemplary embodiment, the lower and upper limits may take into account the number of programmable bootstraps used for linear mappings, as described below regarding... Figure 7b The subject of discussion.

[0184] The lower bound can be derived based on a parameter corresponding to the maximum number of programmable bootstraps, without taking the cost of the programmable bootstraps into account. Specifically, the maximum splitting probability can be used, which reduces noise at the output of each split polynomial sum. Ignoring the cost of the added PBS, the input graph can be transformed, and the maximum 2-norm can be calculated using the minimum noise bound. Parameters for the situation described You can choose from the table of feasible parameters. Interestingly, although those parameters are... These solutions may be unacceptable, but they provide a lower bound on complexity because... An acceptable solution may have the same cost as at least one solution chosen in this manner.

[0185] The upper limit can be derived based on parameters corresponding to the minimum number of programmable bootstraps, while also including the cost of executing the maximum number of programmable bootstraps. Specifically, by employing the minimum splitting probability and taking into account the cost of the added PBS, the input graph can be transformed, and the parameters (v) of the stated case... max , t min The parameters can be obtained from the table of feasible parameters. In this way, the upper limit of complexity can be obtained.

[0186] Given the determined cryptographic computation parameters ECP, the combinational operation COMB,224 can be applied, where the parameters ECP can be substituted into the cryptographic computation graph ECG (which parameterizes the cryptographic computation graph ECG). Therefore, the computation graph ECG can be compiled into an instruction set HE,290 for the cryptographic computation engine. By executing the instructions HE, cryptographic computation can be performed according to the determined cryptographic computation parameters ECP; either by executing the same device with optimized OPT, or more typically by different devices receiving the instructions HE.

[0187] Figure 3 Detailed, but not limiting, embodiments for constraining ciphertext noise are shown. Specifically, embodiments for deriving noise bounds from desired accuracy are given, given the value being encrypted into the ciphertext and the desired maximum error probability. Such noise bounds can be used to constrain noise in subgraphs, as also concerning... Figure 2 The discussion focuses on this. Specifically, noise constraints can be defined by determining the maximum ciphertext noise of a subgraph of the aforementioned type and constraining this maximum noise to remain below a noise limit.

[0188] Specifically, the noise limit t(·) can be a threshold of noise applied to the ciphertext. The noise limit can be parameterized by an error probability, which can be user-configurable. The error probability can also be hard-coded. Note that, for security reasons, the exact noise included in the ciphertext is unknown to the party performing the cryptographic computation. However, this party typically knows the variance of the probability distribution of the noise at a particular point in time, assuming that the input provided to it has a given variance. Therefore, the noise limit can represent a constraint on the variance of the error in the ciphertext. Typically, the noise limit can depend on the number of bits used to represent the precision of the message and the expected probability of correct decryption.

[0189] As an illustrative example, the figure illustrates a noise limit 310 for an LWE-type ciphertext based on the encoding 320 of message m. The method for deriving the noise limit shown is applicable to various cryptographic computation techniques, such as those proposed in the following references:

[0190] -TFHE: I.Chillotti et al., "Faster fully homomorphic encryption:Bootstrapping in less than 0.1seconds", proceedings ASIACRYPT 2016and IChillotti et al., "Faster packed homomorphic operations and efficient circuitbootstrapping for TFHE", proceedings ASIACRYPT 2017;

[0191] -FHEW: L.Ducas et al., "FHEW: bootstrapping homomorphic encryption less than a second", proceedings EUROCRYPT 2015;

[0192] -BFV: J.Fan and F.Vercauteren, "Somewhat Practical Fully HomomorphicEncryption", http: / / eprint.iacr.org / 2012 / 144;

[0193] -CKKS: Jung Hee Cheon et al., "Homomorphic Encryption for Arithmetic ofApproximate Numbers", proceedings ASIACRYPT 2017.

[0194] In the embodiment illustrated in the figure, message m,322 has a bit length p and is encrypted in the most significant bit within a single ciphertext. Specifically, the LWE ciphertext can be a tuple (a1, ..., a...). n b), where Make:

[0195] - It is the key, where the coefficients are sampled according to a given distribution (e.g., uniform binary distribution, uniform binary distribution, or Gaussian distribution);

[0196] - yes From Integers sampled from a uniform distribution;

[0197] -e+Δm is the message encoding 320, which includes the error e,326 sampled from the central Gaussian distribution χσ, and the message Δm,322 rescaled in the most significant bit.

[0198] In this embodiment, the noise term e,326 is sampled from a Gaussian distribution. The noise bound can be defined based on a threshold of the variance of the noise term, such that if the noise remains below this threshold, the probability of correctness is calculated up to a given probability p. err .

[0199] Specifically, the illustration shows:

[0200] - The ciphertext modulus q, 327, for example, powers of 2 (such as 2... 32 2 64 or 2 128 ), or powers other than 2 (such as prime numbers);

[0201] - Message m, 322, with precision p, for example, the number of bits used to encode the message;

[0202] -MSB,321 is set to 0, as required by various programmable bootstrap implementations;

[0203] - Padding bits 323 are used to prevent noise from contaminating the message during decryption due to rounding;

[0204] - The other digits are 324, corresponding to the standard score z. * (p err ) = 4, corresponding to p err ≈2 -13.9 The error probability is 330.

[0205] As illustrated in the figure, the noise limit 310 can be obtained based on the number of bits required for padding 321, message 322, padding 323, and error tolerance 324. The noise limit 310 can require the variance of the noise 326 to remain below this value. In this particular case, there is a space 325 between the noise limit and the error, such that the noise constraint is satisfied.

[0206] The above embodiments can be adapted to a variety of other encryption methods as desired. For example, MSB 321 can be removed where the programmable bootstrapping does not require it, as proposed, for example, 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 ePrintArchive2021 / 1337. Programmable bootstrapping without padding bit 321 is also referred to in this specification as “WOPBS.” This results in a noise limit that is twice as high, for example:

[0207]

[0208] More typically, the noise limit can be calculated as

[0209]

[0210] Among them, pad left It can be any number of padding bits located on the left side of the message, and pad right It can be any number of padding bits located to the right of the message.

[0211] Interestingly, given the encoding and error probability, the noise bound can depend solely on the expected precision of message m. Specifically, the number of possible values ​​that the noise bound can reach can be relatively small; for example, the number of possible values ​​can be at most 10 or at most 20. As described elsewhere, this limited number of possible values ​​can be advantageously used when optimizing cryptographic computation parameters.

[0212] Figure 4a A detailed, non-limiting embodiment of one type of subgraph is shown. This type of subgraph is also referred to as a type 1 atomic pattern.

[0213] In this embodiment, subgraph 400 includes a linear mapping 420 to one or more input ciphertexts 410-412. The linear mapping may include one or more homomorphic additions of ciphertext to another ciphertext and / or plaintext, and / or one or more homomorphic multiplications of ciphertext to a scalar. Typically, any number of such operations (e.g., ciphertext / plaintext addition or ciphertext / ciphertext addition and plaintext-ciphertext multiplication) can be represented as a dot product between ciphertext vectors and plaintext vectors. Therefore, linear mapping 420 may represent the computation of this dot product. Linear mapping 420 may use the corresponding plaintext vector corresponding to the corresponding input ciphertexts 410-412 as an instantiation parameter; however, interestingly, for optimization purposes, it is sufficient to represent linear mapping 420 simply by the 2-norm of the plaintext vectors. Therefore, the subgraph may use the 2-norm of the plaintext vector corresponding to linear mapping 420 as an instantiation parameter.

[0214] In addition to the linear mapping 420, subgraph 400 includes: key switching 430; and programmable bootstrapping, in this case implemented via modulus-to-digital switching 440, followed by blind rotation and sample extraction 450 to produce output ciphertext 460. Interestingly, because the output ciphertext 460 is generated from the programmable bootstrapping, its noise can be independent of the input (at least when noise constraints are satisfied), for example, independent of the noise of the input ciphertexts 410-412 and the 2-norm of the linear mapping 420. For the purposes of this graph, blind rotation and sample extraction are represented by a single node 450; however, they could also be represented as multiple corresponding nodes.

[0215] In many cases, the overall computation graph can be divided into multiple subgraphs that generate noise independent of the input. For example, the input ciphertext 410-412 can be generated from an encryption operator or a programmable bootstrap (with optional rounding). In such cases, the input noise can be assumed to be defined by the maximum value of the input-independent noise used (e.g., noise generated from the programmable bootstrap). When performing the computation represented by the subgraph, the corresponding operations 420-450 can generate corresponding ciphertext noise, which can be obtained by propagating the input noise (e.g., given by the delimited boundary or as an instantiation parameter) through the graph, as shown, for example, regarding... Figure 4b The subject of discussion.

[0216] In addition to the 2-norm of the applied linear mapping 420, the subgraph 400 can be further parameterized by instantiation parameters representing noise limits 421, 431, 441, 451, possibly requiring the ciphertext output by operations 420-450 to satisfy the noise limits 421, 431, 441, 451. Interestingly, it can be observed that operations 420, 430, and 440 typically increase noise, while the output noise of blind rotation 450 is independent of the noise of its input. Therefore, to verify that the subgraph satisfies the noise constraint, it is sufficient to verify this limit 451 only for the noise of the input of blind rotation 450.

[0217] The encryption calculation parameters of the subgraph 400 of the aforementioned type may include the decomposition base of the programmable bootstrap 450 and the key switching 430. and decomposition hierarchy Typically, these parameters can affect the noise of the output of key switching and programmable bootstrapping: if the noise increases too much, the correctness of the computation will be compromised. Furthermore, the parameters can affect the computational cost of the operation, particularly the computational cost of blind rotation 450. These cryptographic computation parameters can be shared between instances of the subgraph type. Multiple subgraph types can also be defined, having the same structure 400 but different parameters, such as bootstrapping and key switching. This can be implemented, for example, by representing bootstrapping and / or key switching with different parameters as different FHE operations, thereby producing different types of subgraphs.

[0218] The computational cost of performing the calculations for subgraph 400 can be represented by a cost function, as discussed elsewhere. Specifically, the cost can be obtained by combining the costs of the corresponding FHE operations, for example:

[0219] Cost(A(v,t),x) = Cost(Σ(v)x) + Cost(KS,x) + Cost(MS,x) + Cost(BR,x) + Cost(SE,x). The cost Cost(∑(v)x) of the linear mapping 420 can be calculated based on the corresponding 2-norm, and / or the number of inputs, and / or the number of additions and multiplications, as explained elsewhere. The cost of a linear mapping can also be approximated as independent of the specific linear mapping being applied, thus obtaining a cost function independent of the instantiation parameters.

[0220] Optionally, the number of possible values ​​for the decomposition base and decomposition level of key switching and / or blind rotation can be reduced by eliminating possible parameter sets with worse noise and / or complexity than other parameter sets. Specifically, key switching adds linear noise to the input noise, and blind rotation resets the input noise so that, in both cases, the noise of the operation can be considered independent of the input noise. Furthermore, the computational cost increases with level for both operations. Therefore, combinations with worse noise and complexity than other combinations (base, level) can be eliminated. This is illustrated by the following procedure:

[0221]

[0222]

[0223] For example, in a specific case, the possible parameter values ​​for blind rotation The number of values ​​can be reduced from 280 to 35, and the number of values ​​for key switching can be reduced from 280 to 46.

[0224] Figure 4b A detailed, but not limiting, embodiment of ciphertext noise is shown when evaluating a subgraph of cryptographic computation. In this embodiment, an action is performed regarding... Figure 4a The illustrated subgraph illustrates a linear mapping 420 applied to one or more input ciphertexts 410, 411; followed by key switching 430, modulus switching 440, and blind rotation and sample extraction 450, resulting in an output ciphertext 460.

[0225] Specifically, as illustrated in the figure, the corresponding FHE operation may have a corresponding noise model, which defines how the ciphertext noise of the FHE operation's output relates to the input ciphertext noise. The noise model may generally take the encryption computation parameters and instantiation parameters of the corresponding operation as input. In this specific embodiment, the noise model of linear mapping 420 may depend on the applied linear mapping, and specifically on the 2-norm of the applied linear mapping. That is, the noise variance of the output of linear mapping 420,∑(v) can be modeled as equal to v.2 The variance of the input noise during multiplication. The noise of the remaining operations in Figure 400 may depend solely on the encryption computation parameters.

[0226] For example, the key switching 430 and blind rotation 450 in a corresponding instance of subgraph 400 of the aforementioned type can use the same key switching and bootstrap keys. Therefore, the noise constraints of an instance of subgraph 400 may depend only on: the 2-norm of the linear mapping 420 and a noise limit indicating the maximum level of noise allowed, or equivalently, a noise limit indicating the expected precision of the encrypted value, depending on the instantiation parameters of subgraph 400; and the global encryption computation parameters and / or encryption computation parameters depending on the type of subgraph. Therefore, in this case, there are no specific encryption computation parameters for any particular instance. Thus, corresponding instances of the illustrated subgraph type can be distinguished by their 2-norm v and noise limit t(p).

[0227] As illustrated in the figure, the input ciphertext of corresponding instances of subgraph 400 can be assumed to all have the same noise 419, for example, noise 459 corresponding to the output of blind rotation and sample extraction 450 (and optional rounding). This is especially true if the total computation graph is divided into multiple subgraphs representing subcomputations (which produce output ciphertext with noise independent of the input) by splitting the computation at a programmable bootstrapping (and optional rounding) operation. However, this is not strictly necessary; for example, the input noise can be an instantiated parameter.

[0228] In evaluating subgraph 400, ciphertext noise is illustrated in Figure 499. As illustrated by line 490, in this case, noise 429, 439, and 449 can generally increase with the corresponding operator of the subgraph until reaching its peak 449 after modulus switching 440. Blind rotation and sample extraction 450 then produce output ciphertext 460, which has noise 459 independent of the input (corresponding to noise 419 of the subgraph's input). Figure 499 also shows a noise limit 492 for noise 490, for example, based on desired computational accuracy. Because the noise increases until blind rotation and sample extraction are performed, the noise constraint of subgraph 400 indicates that the noise 449 of the blind rotation input is below the noise limit 492.

[0229] Figure 4c A detailed, but not limiting, embodiment of the encryption computation parameters is shown. These parameters are herein for subgraph type 400 (which also includes...). Figure 4a and Figure 4bThe diagram (shown in the figure) illustrates, including linear mapping 420, key switching 430, modulus-to-digital switching 440, and blind rotation and sample extraction 450. It will be understood that the same cryptographic computation parameters also apply to instances using different combinations and / or orders of these operations. The figure illustrates which part of sub-figure 400 several cryptographic computation parameters are used in.

[0230] Specifically, the following parameters are illustrated (where the parameter ranges below include the starting and ending values):

[0231] -k: The GLWE dimension of the blind rotation output, such as an integer (with at most or at least 5, at most or at least 10 possible values, such as values ​​between 1 and 10); this can be a globally encrypted computation parameter;

[0232] -N: The GLWE polynomial size of the output of the blind rotation, such as a power of 2 (with at most or at least 5, or at most or at least 10, possible exponent values, such as in the case of 2). 8 With 2 14 (Powers of 2 between them). Extracting 450 samples can produce LWE ciphertext of dimension k·N. This can be the globally encrypted computation parameters;

[0233] -n small The LWE dimension of the output of key switching 430, for example, an integer (with at least 100 or at least 1000 possible values, such as integers between 256 and 2048). For optimized efficiency, the number of possible values ​​considered can be limited, for example, n. small It can be assumed to be a power of 2, although this is not necessary for the cryptographic computation itself. This can be a global cryptographic computation parameter;

[0234] -β KS The decomposition base of key switching 430, such as an integer (with at most or at least 32, or at most or at least 64 possible values, such as integers between 1 and 64); this may be, for example, a cryptographic calculation parameter specific to subgraph type 400, and may be shared with one or more other subgraph types so that the remaining subgraph types can use different values ​​of this parameter.

[0235] - The decomposition level of key switching 430, such as an integer (with at most or at least 32, or at most or at least 64 possible values, such as integers between 1 and 64); this may be, for example, a cryptographic calculation parameter specific to subgraph type 400, and may be shared with one or more other subgraph types so that the remaining subgraph types can use different values ​​of this parameter;

[0236] -β BRThe decomposition base of the programmable bootstrap 450, such as an integer (having at most or at least 32, or at most or at least 64 possible values, such as integers between 1 and 64); this may be, for example, a cryptographic computation parameter specific to subgraph type 400, and may be shared with one or more other subgraph types so that the remaining subgraph types can use different values ​​of this parameter.

[0237] - The decomposition level of the programmable bootstrap 450 is, for example, an integer (with at most or at least 32, or at most or at least 64 possible values, such as integers between 1 and 64); this may be, for example, a cryptographic computation parameter specific to subgraph type 400, and may be shared with one or more other subgraph types so that the remaining subgraph types can use different values ​​of this parameter.

[0238] For example, given the range of parameters discussed above, the number of possible values ​​for combinations of these parameters can be approximated as 2. 41 This highlights the relevance of efficient optimization of these parameters.

[0239] Figure 5 Detailed, but not limiting, embodiments for eliminating noise constraints are illustrated. Specifically, it illustrates how to determine, based on the instantiation parameters of the first and second subgraphs, that the noise constraints of the first subgraph are at least as stringent as those of the second subgraph. In this case, the noise constraints of the second subgraph can be eliminated from the optimization of the cryptographic computation parameters described herein.

[0240] In this embodiment, the subgraph is parameterized by a noise bound t(p) and by the 2-norm ν of the applied linear mapping, as in, for example Figure 4a , Figure 6a and Figure 8 The example shown is an instance of the subgraph type.

[0241] In this context, it can be noted that if two instances of the same subgraph have the same noise bound, the instance with the lower 2-norm generally has less ciphertext noise, so if the other instance satisfies the constraint, then this instance will also satisfy the constraint. Similarly, if two instances have the same 2-norm, and the first instance has a higher noise bound (in other words, a noise bound that is easier to satisfy), then it is sufficient to ensure that the noise constraint of the second instance is satisfied.

[0242] In other words, if the noise boundary of the first subgraph is at most the noise boundary of the second subgraph, and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph, then the noise constraint can be eliminated. Mathematically, let ν1 and ν2 be the 2-norms satisfying ν1 ≤ ν2, and let t1 and t2 be the noise boundaries satisfying t2 ≤ t1, then...

[0243] For example, in the diagram:

[0244] - Subgraph A4 can be eliminated because of subgraph A1 or because of subgraph A2;

[0245] - Subgraph A5 can be eliminated because of subgraph A2 or because of subgraph A3;

[0246] - Subgraph A6 can be eliminated because of subgraphs A1, A2, A3, A4, or A5.

[0247] Therefore, in this embodiment, the subgraphs that are not eliminated can be subgraphs A1, A2, and A3. The set of subgraphs that are not eliminated can be referred to as the "Pareto front" of the subgraphs of this type.

[0248] Since noise constraints on several subgraphs are eliminated, it is no longer necessary to verify constraints on the same number of feasible sets as the subgraphs. Instead, verifying constraints on the un-eliminated subgraphs is sufficient. This is particularly advantageous in embodiments where the subgraph is defined by two instantiation parameters (e.g., noise bounds and a 2-norm, at least one of which has a finite number of values), since the number of un-eliminated subgraphs is at most the number of values ​​for the instantiation parameters. For example, the number of noise bounds, and thus the number of un-eliminated subgraphs of a type of subgraph, can be at most 5 or at most 10.

[0249] Figure 6a A detailed, non-limiting embodiment of a type subgraph 600 is shown. This type of subgraph may include one or more key switches 620-1, 620-2, 620-3 for corresponding input ciphertexts 611, 612, 613; a linear mapping 630; and a programmable bootstrapping (e.g., analog-to-digital switching 640) applied to the output of the linear mapping, followed by blind rotation and sample extraction 650. The output ciphertext 660 may be the output of the sample extraction (optional rounding may be applied to the output, as explained elsewhere). Therefore, the noise of the output ciphertext 660 may be independent of the noise of the input ciphertexts 611-613.

[0250] Interestingly, also regarding subgraph 600 of the aforementioned type, if the noise boundary of the first subgraph is at most the noise boundary of the second subgraph, and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph, then the noise constraint of the second subgraph can be eliminated. Furthermore, interestingly, the subgraph can have type 600, but can also have... Figure 4a The example is type 400.

[0251] Specifically, Figure 4a Subgraph type 400 (e.g., multinomial sum, key switching, modulus switching, blind rotation, and sample extraction) is also known as "type 1 atomic mode" and is denoted as A. 1The subgraph type 600 of this diagram can be referred to as "atom mode of type 2" and is represented as A. 2 Therefore, the difference between types 400 and 600 is that KS 620 and the linear mapping ∑(v), 630 are replaced.

[0252] For example, encrypted computation graphs It can consist entirely of these two types of APs. Independently for the corresponding type, subgraphs can be eliminated, as per [the relevant clause / reference]. Figure 5 The subject of discussion.

[0253] Interestingly, however, subgraph elimination can be further achieved by comparing subgraphs of two different types of AP 400 and 600. More generally, by determining that the noise constraints of the first subgraph of different types are at least equally stringent, the noise constraints of the second subgraph can be eliminated from the optimization of the encrypted computation parameters.

[0254] Specifically, for the purpose of elimination, the FHE operator can be divided into three categories related to noise:

[0255] - Operators that output noise independent of the input noise, such as PBS and WOPBS;

[0256] - Operators that add noise independent of the input to the input noise, such as key switching 620 and analog-to-digital switching 640;

[0257] - Operators whose output has ciphertext with noise that depends on the input noise (e.g., nonlinearity), such as multinomial sum 630, GLWE multiplication, etc.

[0258] Specifically, consider two types of subgraphs where the type 2 FHE operator is replaced by the type 3 FHE operator, as in instances of multinomial sum 630 in subgraph types 400 and 600, and key switching 620. Note that FHE operators not belonging to type 1 increase the noise within the ciphertext. Because the type 3 FHE operator adds noise that depends on the input noise, the higher the input noise, the higher the output noise.

[0259] Based on this, the following can be inferred. Let A 1 and A 2 There are two types of subgraphs, which include the same operations, but differ in that: in A 1 In the example, the type 2 FHE operator precedes the type 3 FHE operator; however, in A... 2 In this context, the same FHE operator of type 2 follows the same FHE operator of type 3. Therefore, A 2 The noise in A is higher than that in A 1 Noise in the data. For example, let A... 2 Corresponding to Figure 6a The subgraph type is 600, and let A1 Corresponding to Figure 4a The subgraph type is 400. Let V be the 2-norm and let t be the noise bound. Therefore, A 2 The noise in (v, t) is higher than that in A. 1 The noise in (v, t) is amplified by the type 3 operator because the noise of the type 2 operator is amplified by the type 3 operator.

[0260] The above example illustrates how a subgraph of one type can be used to eliminate noise constraints of another type of subgraph, specifically in the case where the difference between multiple subgraph types lies in the permutation between the FHE operator of type 2 and the FHE operator of type 3, in which case it is KS and a multinomial sum. Specifically, let v1, v2 denote the 2-norm satisfying v1 ≤ v2, and let t1, t2 denote the noise bounds satisfying t2 ≤ t1. Therefore,

[0261] More generally, it can be noted that noise constraints can be eliminated regardless of which operations follow the ciphertext with the maximum noise, for example, regardless of what follows the type 1 FHE operator. Specifically, the subgraph 600 shown has a type 1 operator, blind rotation, and sample extraction 650. More generally, in a graph with multiple types of subgraphs, another type of subgraph can use one or more different type 1 operators as final nodes. Because these operators do not affect the maximum noise and thus do not affect the noise constraints, another type of subgraph can be eliminated based on a subgraph of one type, as described herein.

[0262] Figure 6b A detailed, non-limiting embodiment of a type subgraph 601 is shown. This type of subgraph may include: one or more linear mappings 621, 622 to one or more input ciphertexts 614, 615; followed by a balanced cryptographic multiplication 670; a key switching 631; and a programmable bootstrapping 651. The balanced cryptographic multiplication 670 may, for example, include wrapper key switching, tensor multiplication, and relinearization, as known per se, and may also be represented by corresponding nodes for corresponding suboperations. Similarly, in this embodiment, the programmable bootstrapping is represented by a single node 651; however, it may also be represented by nodes for its corresponding suboperations, such as in… Figure 6a In the middle. This type of subgraph can be called a "type 3 atomic pattern" and is represented as A. 3 .

[0263] Therefore, subgraph type 601 may be based on subgraph type 400, additionally including multiplication 670. Similarly, the fourth subgraph type may be defined as based on... Figure 6a The subgraph type 600, and additionally includes encrypted multiplication between linear mapping 630 and modulus switching 640.

[0264] Interestingly, subgraphs of type 1 can be eliminated based on subgraphs of type 3, and similarly, subgraphs of type 2 can be eliminated based on subgraphs of type 4. More generally, subgraphs of a particular type can be eliminated based on subgraphs of that type with additional balanced cryptographic multiplication. In fact, balanced cryptographic multiplication adds additional noise, thus producing a more stringent noise constraint.

[0265] For example, let A 1 (v, t) is a subgraph of type 1, and let A 3 (v1, v2, t) is a subgraph of the third type. If Then A 3 (v1, v2, t) dominates A 1 (v, t), so the latter can be eliminated.

[0266] Figure 7a Detailed, but not limiting, embodiments are shown for identifying the corresponding key switching key and / or bootstrap key to be used in the corresponding subgraph.

[0267] As discussed elsewhere, key switching keys and bootstrapping keys can be specific to a particular set of cryptographic computation parameters, such as hierarchical key parameters and decomposition key parameters. (See also: Regarding...) Figure 4a The parameters discussed can be shared between different instances of the same type of subgraph. Specifically, in some cases, the same key-switching key and / or bootstrapping key can be used throughout the entire cryptographic computation. The advantage of this is that it produces very little key material, but on the other hand, it negatively impacts computational complexity because, in this case, noisier and faster key-switching or bootstrapping cannot be used in the subgraph (even if it were possible).

[0268] Several methods exist to support multiple key switching and / or bootstrapping keys in the same cryptographic computation. (See also: ...) Figure 4a One approach discussed is to limit subgraphs of corresponding types with the same structure, but using corresponding key switching keys and / or bootstrapping keys, where specific subgraphs are pre-configured to have a specific type. The disadvantage of this approach is that it cannot automatically optimize which key to use in which subgraph.

[0269] Another approach is to limit the cryptographic parameters of key switching and / or bootstrapping (e.g., level / base) to cryptographic computation parameters for a specific instance of the subgraph, different from those for the subgraph of that type. In this case, the number of different keys used in the computation can be limited by including this as a constraint in the optimization. However, this approach introduces a large number of additional parameters, further complicating the optimization problem.

[0270] Interestingly, the inventors envision a better way to automatically determine which key-switching keys and / or bootstrap keys are used in which subgraph. That is, multiple sets of parameters (e.g., hierarchy and / or base) corresponding to multiple sets of key-switching keys and / or bootstrap keys can be defined as, for example, a portion of global cryptographic computation parameters, or as parameters of a given type of subgraph. The number of sets to be used can be pre-configured. For a given subgraph 770-772, the cryptographic computation parameters δ, 780-782 of that subgraph can determine which set of parameters is used for that subgraph.

[0271] This is illustrated below for key switching. Assume the number of key switching keys to be used is X, and the number of subgraphs using them is Y. Optimization of the key switching keys to be used corresponds to determining... It produced a size of X Y The additional search space. This is better than having multiple sets of parameters for the corresponding subgraph, but it is still quite large.

[0272] Interestingly, the inventors realized that if the noise constraints of the first subgraph are at least as strict as those of the second subgraph, the search space for the key-switching key (and similarly, the bootstrap key) can be greatly reduced by constraining the key-switching key of the first subgraph to add at most as much noise as the key-switching key of the second subgraph.

[0273] Specifically, the key switching keys to be used can be sorted according to the amount of noise they add, for example, sorted into a sequence (KSK0, KSK1, ...) such that KSK0 adds less noise than KSK1, KSK1 adds less noise than KSK2, and so on. Typically, in this case, key switching with KSK0 is more computationally expensive than key switching with KSK1, creating a trade-off between cost and noise.

[0274] As an example, consider multiple subgraphs (e.g., type 1 or type 2 as discussed herein) having the same noise bound t and different 2-norms, satisfying v0 < v1 < v2. 770-772. Additionally, consider two key switching keys, KSK0 and KSK1, such that KSK1 introduces more noise than KSK0 during key switching. The key switching key used in the corresponding subgraph can be determined by parameters (δ0, δ1, δ2), δ i It is represented as ∈{0,1},780-782.

[0275] In this embodiment, it is noted that (δ0, δ1, δ2) = (0, 1, 0) will not be the optimal solution. This can be explained as follows. (See also: Regarding...) Figure 4a and Figure 6aIn this case, the discussion is ongoing. This means that a feasible solution to A(v0, t) is a feasible solution to A(v1, t).

[0276] Assume that (δ0, δ1, δ2) = (0, 1, 0) is the optimal solution. Furthermore, the noise constraint of A(v0, t) can be eliminated from the optimization, since the noise constraint of A(v2, t) is at least as strict.

[0277] Now, consider the solution (δ0, δ1, δ2) = (1, 1, 0). In this case, the noise constraint of A(v0, t) can be eliminated from the optimization because the noise constraint of A(v1, t) is at least as strict.

[0278] Therefore, in And (δ0, δ1, δ2) = (0, 1, 0), and And in the case where (δ0,δ1,δ2)=(1,1,0):

[0279] (δ0,δ1,δ2) can be equal to (0,1,0) or (1,1,0), and in any case, the result... They are the same:

[0280] · As and The only difference is that the first one used a slower key switch. Because the feasible sets are the same, and It is always faster in terms of computational complexity than Even worse, so it is inferred that (δ0,δ1,δ2)=(0,1,0) will not be the optimal solution.

[0281] The above reasoning can be extended to graphs including any number of subgraphs with the same noise limit. In this case, the identifier corresponding to the key switching key can correspond to the number of subgraphs that determine the maximum noise constraint (the subgraphs using the first key switching key), while the remaining subgraphs use the second key switching key. This greatly reduces the parameter space. Mathematically, let Satisfying v0 < v1 < v2 < ... < v Y And Y = |I|, and assume that two keys are used to switch keys. Therefore, the optimal δ = (δ0,…,δ) Y ) has the form (1, ..., 1, 0, ..., 0). Therefore, optimization does not require finding every possible {δ}. i} i∈I For example, determine γ∈{1,…,Y} that satisfy (1,…,1,0,…,0) and δ i-1 =1 and δ i=0 for γ=i is sufficient. This means that the substitution must be of size 2. Y The search can be performed within the search space of size Y, which is sufficient.

[0282] The above reasoning also applies to any number of key-switching keys. Furthermore, in this case, it is sufficient to determine several subgraphs (ordered from the strictest to the least strictest noise constraints) using the corresponding key-switching keys. Mathematically, let... Satisfying v0 < v1 < v2 < ... < v Y And Y = |I|, and assume X keys are being switched. Therefore, the optimal δ = (δ0, ..., δ... Y) It has the form (Y, ..., Y, Y-1, ..., Y-1, ..., 1, ..., 1, 0, ..., 0). Therefore, it is not necessary to find every possible {δ}. i} i∈I For example, determining whether γ is satisfied j ∈[[1, Y]], γ j =i of {γ j} j∈[[1，X-1]] Simultaneously δ i-1 =x∈[[1,X-1]] and δ i =x+1 and γ0<γ1<… is sufficient. This means that the substitution must be of size X. Y Search within the search space, within the size Searching within the space is sufficient.

[0283] The above method can be applied to multiple sets of subgraphs, by limiting the corresponding key identifier vectors (δ0, ..., δ) of the multiple sets of subgraphs. Y They can share the corresponding noise limits, as described above.

[0284] Furthermore, the above method can also be applied to identify the corresponding bootstrap key used in the corresponding subgraph, wherein the bootstrap key is sorted according to the amount of noise added.

[0285] For a given subgraph, the key switching key and bootstrap key to be used can also be determined. In this case, if the noise constraint of the first subgraph is at least as strict as that of the second subgraph, the key switching key and bootstrap key of the first subgraph can be constrained such that neither adds more noise than the key switching key and bootstrap key of the second subgraph. For example: let ν1 > ν2, and t be a noise limit, and (correspondingly) Identify which key is used for A(v1,t) (and correspondingly for A(v2,t)). In this case, and The solution is suboptimal and can therefore be eliminated.

[0286] Figure 7b A detailed, non-limiting embodiment is shown for determining the number of programmable bootstraps to be executed during the application of a linear mapping. The embodiment in this figure is based on... Figure 4a This technique applies to subgraphs of the type described, but it is equally applicable to other types of subgraphs that include those to which linear mappings are applied, such as... Figure 6a The type of subgraph shown is shown.

[0287] The image shows something about Figure 4a The illustrated subgraph 700 includes a linear mapping 720 applied to one or more input ciphertexts 710, followed by key switching 730 and programmable bootstrapping 740 (in this case, shown as a single node, but typically implemented as analog-to-digital switching, blind rotation, and sample extraction) to produce an output ciphertext 760.

[0288] Further illustrated is a different subgraph 700', which computes the same output ciphertext 760 from the same input ciphertext 710, but does so by using a programmable bootstrap 750 during the application of the linear mapping, in this case, dividing it into two parts 721, 722. The inserted programmable bootstrap 750 in this embodiment applies an identification function, although it may also incorporate, for example, scalar multiplication and / or addition of public values. As in subgraph 700, key switching and a programmable bootstrap 730 (illustrated here as a single node for simplicity) are applied to the output of the linear mappings 721-722 to obtain the output ciphertext.

[0289] In this case, inserting PBS 750 into the subgraph during the application of linear mapping increases computational complexity. On the other hand, PBS 750 reduces ciphertext noise when evaluating the subgraph, thereby reducing the 2-norm of the multinomials and 721, 722, allowing for noisier but faster parameters.

[0290] Interestingly, the inventors realized that this tradeoff could be optimized to automatically determine the corresponding number of programmable bootstraps to be executed during subgraph operations (e.g., during the application of the corresponding linear mapping, as in this embodiment) for a given type of corresponding subgraph. Therefore, the type of subgraph with a variable number of programmable bootstraps d can be limited. For example, the computation graph input to the optimized cryptographic computation during the application of the corresponding linear mapping may not include programmable bootstraps, which the optimization inserts as appropriate.

[0291] Mathematically, the optimization problem in this case can be expressed as:

[0292]

[0293] When it is determined that one or more programmable bootstraps will be executed during a linear mapping, the linear mapping can be automatically split into several corresponding linear mappings corresponding to the number of programmable bootstraps. This can be done by minimizing the maximum 2 norm of the corresponding linear mappings (e.g., ν1 ≈ ν2). In this way, inserting programmable bootstraps is most efficient in allowing for more noise parameters.

[0294] Specifically, the linear mapping can be split by minimizing the maximum 2 norm of the corresponding linear mapping. This provides a suitable approximation of the optimal solution in terms of noise and complexity by effectively ignoring the cost of the multinomial sum (specifically, the number of inputs to which the corresponding multinomial sum is applied). Specifically, to split the multinomial sum into two multinomial sums (as in subgraph 700'), the following optimization problem can be solved, for example, using a suitable solver known per se:

[0295]

[0296] PGCD(w i，1 ,Λ)=1

[0297]

[0298] Here, Λ is an optional additional integer output of the optimization. As another embodiment, the polynomial sum can be split into three polynomial sums using the following optimization:

[0299]

[0300] Another technique for splitting multinomials is as follows. If the weights are approximately uniformly distributed (e.g., w...), then... i ∈[-2 p ,2 p This technique is particularly effective when the corresponding weights are cardinally decomposed into multiple numbers, which can be applied to the input and combined. For example, cardinal decomposition can be performed as Algorithm 1 in I. Chillotti et al., “Faster FullyHomomorphic Encryption: Bootstrapping in less than 0.1 seconds,” procedures ASIACRYPT 2016 (included in this paper by reference), or using signed decomposition as disclosed in M. Joye, “Balanced non-adjacent forms,” procedures ASIACRYPT 2021 (included in this paper by reference). Specifically, the level of cardinal decomposition can be equal to d+1, where d is the number of programmable bootstraps to be applied, and the base logarithm can be... The set. The corresponding Λ i It can be the base. The corresponding power.

[0301] Interestingly, the number d of programmable bootstraps performed by the corresponding subgraph i is determined. i If the noise constraint of the first subgraph i is at least as strict as the noise constraint of the second subgraph j, then the number d programmable bootstraps of the first subgraph can be increased. i Constrain the number of programmable bootstraps d greater than or equal to the number of programmable bootstraps in the second subgraph. j This can greatly reduce d i The parameter space.

[0302] In other words, if inserting a PBS into a subplot does not change the parameters, then the insertion is always suboptimal. More precisely, let Satisfying v0 < v1 < ... . Let and There are two possible solutions. Let and .if (For example, each coordinate is either poor or equal and) Then it can be noted that, It won't be the optimal solution. In other words, it's similar to... Figure 7a The discussion concluded that the two subgraphs have the same noisy feasible set, and that one subgraph has a higher cost than the other because it contains more programmable bootstraps.

[0303] Figure 8 A detailed, but not limiting, embodiment of a programmable bootstrap with noise rounding is shown. This embodiment can be used with any subgraph type that includes programmable bootstrap (e.g., Figure 4a , Figure 6a , Figure 6b or Figure 7b (Subgraph type) combination.

[0304] Specifically, this embodiment illustrates a programmable bootstrapping method comprising analog-to-digital switching 840 applied to an input ciphertext 839 of the programmable bootstrapping method to produce an LWE-encrypted analog-to-digital switching output 849; followed by a blind rotation 851 using a bootstrapping key 854 and a lookup table 855 to produce a GLWE-encrypted monomial 852 (in this embodiment, RLWE encryption); and sample extraction 853 applied to the GLWE-encrypted monomial to obtain a programmable bootstrapping LWE-encrypted output ciphertext 869. These operations can be performed as are known per se.

[0305] Interestingly, as shown in this figure, noise rounding operation 870 can be applied to the sample extraction output 869 to obtain rounded output ciphertext 879. Specifically, the operation can set the least significant bit of a given number of ciphertext values ​​to zero, or in other words, round the ciphertext value to a given power of 2. Note that output ciphertext 869 typically has noise independent of the input, therefore rounded output ciphertext 879 also has noise independent of the input.

[0306] As the inventors realized, by applying rounding operations to the result of the programmable bootstrapping, the rounded result 879 of the programmable bootstrapping can be made independent of the specific Fast Fourier Transform (FFT) implementation used to implement the programmable bootstrapping, provided that the FFT implementation has a given accuracy. Therefore, PBS can be effectively made deterministic. This can lead to, or at least facilitate, making fully cryptographic computation deterministic.

[0307] In other words, the inventors realized that the output 869 extracted from the sample before rounding to 870 would differ across various FFT implementations. This was actually observed in an experiment comparing the implementation of PBS on a CPU with FFTW with that on a GPU with regular FFT. Although both outputs were correct in themselves, they could differ in the exact output noise they produced. For many coefficients of the PBS output, it was observed that the most significant bit containing the message was the same, while the least significant bit (containing noise) contained some differences.

[0308] The number of bits to be rounded can be pre-configured; in other words, the position where rounding occurs. However, this position can also be defined as a cryptographic computation parameter, such as a global cryptographic computation parameter or a parameter specific to a subgraph type. That is, rounding can add a certain amount of noise, with larger rounding values ​​applied in the MSB adding more noise to the plaintext. For a given implementation of the FFT, optimization can utilize the error constraints on the ciphertext coefficients introduced by that implementation. Therefore, the cryptographic computation parameters can be optimized by taking into account the noise model, the cost model, and the FFT error model.

[0309] To account for errors in the FFT depending on the implementation method, constraints can be included in the optimization of the cryptographic computation parameters. This constraint can be achieved by adding a feasible set. (A feasible set will be added during the optimization) (Taking into consideration) can be used to represent this. The condition can be expressed as:

[0310] in yes The error of the coefficients of the output ciphertext.

[0311] Typically, this method can be based on an error model of the ciphertext coefficients in the output of the FHE operator. For example, an FHE operator without FFT can take error-free ciphertext as input and output error-free ciphertext.

[0312] Programmable bootstrapping (or more generally, using the FHE operator of FFT) can reset the error to a minimum level (e.g., produce ciphertext that is not error-free), or can output the maximum amount of error (e.g., re-randomization of the ciphertext) depending on the operator's parameters and the input error. Rounding can preserve the same amount of error or eliminate it, depending on the cryptographic computation parameters and the input error.

[0313] FFT error can be constrained based on other cryptographic and / or cryptographic computation parameters, such as by requiring

[0314] Although noise rounding 870 is applied to the output of the programmable bootstrap in the above embodiment, it is noted that, more generally, noise rounding can be applied to the output of other FHE operations using FFT (or, in general, other FHE operations that produce noise independent of the implementation), thereby helping to make cryptographic computations deterministically applied to the ciphertext.

[0315] It is also noted that noise rounding 870 can be applied to make the cryptographic computation more deterministic, regardless of whether the cryptographic computation parameters are determined through optimizations as described herein. Specifically, the inventors envision a cryptographic method for performing cryptographic computations, and a corresponding cryptographic computation apparatus, wherein noise rounding operation 870 is applied to the output of an FHE operation that includes noise relevant to the implementation (such as FFT-related noise of programmable bootstraps 840-853). The cryptographic computations performed by this method and apparatus may use the cryptographic computation parameters as described herein, but this is not required.

[0316] Specifically, cryptographic methods involving noisy rounding can be performed by mining equipment using a distributed ledger (e.g., blockchain). Multiple such mining equipment can perform the cryptographic computation. Due to the use of rounding 870, it is possible for corresponding mining equipment to compute the exact same ciphertext as the output of the cryptographic computation, meaning that not only is the plaintext identical, but the ciphertext used to encrypt the plaintext is also identical. When used in combination with the optimizations described herein, the corresponding mining equipment can still use the corresponding cryptographic computation parameters that are optimal for the implementation-related noise (e.g., FFT error) of their respective system configurations. Specifically, by using rounding 780, the mining equipment can reach consensus on the cryptographic computation output without requiring decryption.

[0317] The following numbered clauses include conjecture and non-limiting embodiments:

[0318] 1. A computer-implemented method (900) for determining encryption computation parameters for performing encryption computation on noisy ciphertext, comprising:

[0319] - Access (910) represents the data of the computation graph of the encrypted computation;

[0320] - Get (920) divide the computation graph into multiple subgraphs, wherein the subgraphs are defined by a type from a set of one or more types, and the subgraphs are defined by zero or more instantiation parameters of the type;

[0321] - Limit the encryption calculation parameters of the corresponding group (930) according to the corresponding type;

[0322] - Perform optimization of the encryption computation parameters described in (940), wherein:

[0323] - The encryption calculation parameters are optimized so that, according to the encryption calculation parameters

[0324] Minimize the computational cost of performing the cryptographic calculation; and

[0325] The encryption computation parameters are constrained to satisfy noise constraints on ciphertext noise when the encryption computation is performed, wherein the noise constraints are based on corresponding noise constraints of the corresponding subgraph, wherein the noise constraints of a subgraph of a given type are limited by a noise constraint function of the given type, the noise constraint function of the given type taking at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input.

[0326] 2. The method (900) according to Clause 1 includes:

[0327] - Based on the instantiation parameters of the first and second subgraphs, determine that the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph; and

[0328] - Eliminate the noise constraints of the second subgraph from the optimization.

[0329] 3. The method (900) according to Clause 2, wherein the first subgraph and the second subgraph are parameterized by a noise bound and by the 2-norm of the applied linear mapping, wherein the noise bound of the first subgraph is at most the noise bound of the second subgraph, and the 2-norm of the first subgraph is at least the 2-norm of the second subgraph.

[0330] 4. The method (900) according to any of the preceding clauses, wherein the computational cost is minimized based on a cost function, wherein the cost function is based on the corresponding cost of the corresponding subgraph, wherein the cost of a subgraph of a given type is limited by a cost function of the given type, the cost function of the given type taking at least the cryptographic computational parameters of the given type as input and being independent of the instantiation parameters.

[0331] 5. The method (900) according to any of the preceding clauses, wherein the subgraph represents a subcomputation that produces an output ciphertext with noise independent of the input.

[0332] 6. The method (900) according to any of the preceding clauses, wherein the cryptographic computation parameters include one or more of the following: a programmable bootstrap decomposition base, a programmable bootstrap decomposition level, a key-switching decomposition base, and a key-switching decomposition level.

[0333] 7. The method (900) according to any of the preceding clauses, wherein the subgraph includes a programmable bootstrap for generating the output ciphertext and noise rounding of the output ciphertext.

[0334] 8. The method (900) according to any of the preceding clauses, wherein the optimization of the cryptographic computation parameters is performed by a branch and bound method.

[0335] 9. The method (900) according to any of the preceding clauses, wherein the cryptographic computation parameters identify the corresponding key switching key and / or bootstrap key to be used for the corresponding subgraph, wherein if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the key switching key and / or bootstrap key of the first subgraph is constrained to add up to as much noise as the key switching key and / or bootstrap key of the second subgraph.

[0336] 10. The method (900) according to any of the preceding clauses, wherein the cryptographic computation parameter indicates the corresponding number of programmable bootstraps to be executed during the application of the corresponding linear mapping for the corresponding subgraph of the application corresponding linear mapping.

[0337] 11. The method (900) according to Clause 10 further includes splitting the linear mapping into several corresponding linear mappings corresponding to the number of programmable bootstraps by minimizing the maximum 2 norm of the corresponding linear mapping.

[0338] 12. The method (900) according to Clause 10 or 11, wherein if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the number of programmable bootstraps of the first subgraph is constrained to be greater than or equal to the number of programmable bootstraps of the second subgraph.

[0339] 13. The method (900) according to any of the foregoing clauses further comprises:

[0340] - Transform an unencrypted computation graph into an encrypted computation graph; and / or

[0341] - Compile the computation graph of cryptographic computation into a set of instructions for the cryptographic computation engine; and / or

[0342] - Perform cryptographic calculations based on the determined cryptographic calculation parameters.

[0343] 14. A configuration device (110) that determines encryption calculation parameters for performing encryption calculations on noisy ciphertext, comprising:

[0344] - A memory (130) for storing data representing a computation graph of the encrypted computation;

[0345] - Processor subsystem (140), said processor subsystem (140) being configured to:

[0346] - To obtain a computation graph divided into multiple subgraphs, wherein the subgraphs are defined by a type from a set of one or more types, and the subgraphs are defined by zero or more instantiation parameters of the type;

[0347] - Limit the encryption calculation parameters for the corresponding group based on the corresponding type;

[0348] - Optimize the encryption computation parameters, wherein: the encryption computation parameters are optimized such that the computational cost of performing the encryption computation based on the encryption computation parameters is minimized; and the encryption computation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption computation, wherein the noise constraints are based on corresponding noise constraints of corresponding subgraphs, wherein the noise constraints of a given type of subgraph are limited by a noise constraint function of the given type, the noise constraint function taking at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input.

[0349] 15. A temporary or non-temporary computer-readable storage medium (1000) comprising data (1020) representing instructions that, when executed by a processor system, cause the processor system to execute cryptographic computation parameters determined by the method according to any one of clauses 1-13 and / or instructions for a cryptographic computation engine.

[0350] Figure 9aAn embodiment of one implementation of a method 900 for determining encryption computation parameters for performing encryption computation on noisy ciphertext is illustrated schematically.

[0351] Method 900 may include accessing data representing a computation graph of encrypted computation, as indicated by 910.

[0352] Method 900 may include obtaining 920 by dividing the computation graph into multiple subgraphs. Subgraphs may be defined by a type from a set of one or more types, and subgraphs may be defined by zero or more instantiation parameters of said type.

[0353] Method 900 may include limiting the encryption calculation parameters of the corresponding group of 930 for the corresponding type.

[0354] Method 900 may include optimizing 940 encryption computation parameters. During optimization, the encryption computation parameters may be optimized such that the computational cost of performing the encryption computation based on the encryption computation parameters is minimized. Furthermore, the encryption computation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption computation. The noise constraints may be based on corresponding noise constraints of a corresponding subgraph. The noise constraints of a subgraph of a given type are defined by a noise constraint function of the given type, which takes at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input.

[0355] Figure 9b An embodiment of one implementation of a cryptographic method 950 for performing cryptographic computation is illustrated schematically.

[0356] Method 950 may include obtaining 960 cryptographic computation parameters as described herein, and performing 970 cryptographic computation based on the obtained cryptographic computation parameters. For example, the cryptographic computation parameters may be incorporated into a set of obtained instructions for a cryptographic computation engine that performs the 970 cryptographic computation, or the cryptographic computation parameters may be obtained separately from the representation of the cryptographic computation to be performed.

[0357] As an alternative or supplement to using the encryption calculation parameters as described herein, method 950 may apply noise rounding operations to ciphertext having noise relevant to the implementation (e.g., the output of a programmable bootstrap), such as as per the description of... Figure 8 The subject of discussion.

[0358] Many different ways of performing methods 900 and 950 are possible, as will be apparent to those skilled in the art. For example, the steps may be performed in the order shown, while the order of the steps may be changed or some steps may be performed in parallel. Furthermore, other method steps may be inserted between the steps. The inserted steps may represent an improvement on the method as described herein, or may be unrelated to the method. For example, some steps may be performed in parallel at least partially. In addition, a given step may not be fully completed at the start of the next step. Methods 900 and 950 may also be combined; for example, method 950, which performs cryptographic computation, may be performed according to cryptographic computation parameters previously determined according to method 900.

[0359] Implementations of the method can be executed using software, which includes instructions for causing a processor system to execute method 900 or 950. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored on a suitable storage medium, such as a hard disk, floppy disk, memory, optical disk, etc. The software may be transmitted as a signal via wired or wireless means, or using a data network (e.g., the Internet). The software may be downloaded and / or remotely used on a server. Implementations of the method can be executed using a bitstream arranged to configure programmable logic (e.g., a field-programmable gate array (FPGA)) to execute the method.

[0360] It will be understood that the currently disclosed subject matter also extends to computer programs (specifically, computer programs residing on or within a carrier) adapted to put the currently disclosed subject matter into practice. Programs may take the form of source code, object code, intermediate source code, and object code (such as partially compiled forms), or any other form suitable for implementation of the methods. Implementations relating to the computer program product include computer-executable instructions corresponding to each processing step in at least one of the stated methods. These instructions may be subdivided into subroutines and / or stored in one or more files that can be statically or dynamically linked. Another implementation relating to the computer program product includes computer-executable instructions corresponding to each device, unit, and / or portion of at least one of the stated systems and / or products.

[0361] Typically, the descriptions herein (e.g., in) Figures 1a-1cThe device (in the context of the system) includes one or more microprocessors that execute appropriate software stored in the system; for example, the software may have been downloaded and / or stored in corresponding memory, such as volatile memory (e.g., RAM) or non-volatile memory (e.g., Flash). Alternatively, the system may be implemented wholly or partially as programmable logic (e.g., as a field-programmable gate array (FPGA)). The system may be implemented wholly or partially as a so-called application-specific integrated circuit (ASIC), such as an integrated circuit (IC) customized for a specific purpose. For example, the circuitry may be implemented in CMOS, for example, using a hardware description language (such as Verilog, HDL, etc.). Specifically, the system may include circuitry for evaluating cryptographic primitives.

[0362] Processor circuitry can be implemented in a distributed manner (e.g., as multiple sub-processor circuits). Memory can be allocated across multiple distributed sub-memories. Some or all of the memory can be electronic memory, magnetic memory, etc. For example, memory can have volatile and non-volatile portions. Portions of memory can be read-only.

[0363] Figure 10 A computer-readable medium 1000 having a writable portion 1010 is shown. The computer-readable medium 1000 is shown in the form of an optically readable medium. The computer-readable medium 1000 can store data 1020, wherein the data can indicate instructions, which, when executed by a processor system, cause the processor system to perform an embodiment of a method for determining cryptographic computation parameters and / or performing cryptographic computation, according to one embodiment.

[0364] Alternatively or additionally, data 1020 may represent cryptographic computation parameters and / or instructions for the cryptographic computation engine as determined according to an implementation scheme.

[0365] Data 1020 may be implemented on the computer-readable medium 1000 as a physical marker or by magnetization of the computer-readable medium 1000. However, any other suitable implementation is also conceivable. Furthermore, it will be understood that although the computer-readable medium 1000 is shown herein as an optical disc, 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.

[0366] Figure 11A schematic representation of a processor system 110 according to one embodiment of a device for performing cryptographic calculations or determining parameters for cryptographic calculations is shown. The processor system includes one or more integrated circuits 1110. The architecture of the one or more integrated circuits is schematically shown in the figure. Circuit 1110 includes a processing unit 1120 (e.g., a CPU) for running computer program components to perform a method according to one embodiment and / or implement its modules or units. Circuit 1110 includes memory 1122 for storing programming code, data, etc. A portion of memory 1122 may be read-only. Circuit 1110 may include communication elements 1126, such as an antenna, a connector, or both. Circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, memory 1122, dedicated IC 1124, and communication element 1126 may be connected to each other via an internal connection 1130 (e.g., a bus). The processor system 110 may be configured to perform contact communication and / or contactless communication correspondingly using an antenna and / or a connector.

[0367] For example, in one embodiment, the processor system 1140 (e.g., a device for performing cryptographic calculations or compilation) may include processor circuitry and memory circuitry, the processor being configured to execute software stored in the memory circuitry. For example, the processor circuitry may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In one embodiment, the processor circuitry may be an ARM Cortex M0. The memory circuitry may be ROM circuitry or non-volatile memory, such as flash memory. The memory circuitry may also be volatile circuitry, such as SRAM memory. In the latter case, the device may include a non-volatile software interface (e.g., a hard disk, network interface, etc.) configured to provide the software.

[0368] Although device 1110 is shown as including one of the various described components, multiple components may be repeated in various embodiments. For example, processor 1120 may include multiple microprocessors configured to independently execute the multiple methods described herein, or configured to execute steps or subroutines of the methods described herein, such that multiple processors cooperate to achieve the functions described herein. Additionally, when device 1110 is implemented in a cloud computing system, multiple hardware components may belong to separate physical systems. For example, processor 1120 may include a first processor located in a first server and a second processor located in a second server.

[0369] It should be noted that the above-mentioned embodiments are illustrative and not limiting of the subject matter currently disclosed, and those skilled in the art will be able to devise many alternative embodiments.

[0370] In the claims, any reference numerals enclosed in parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of elements or steps other than those recited in the claims. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. When an expression such as "at least one" precedes a list of elements, it indicates the selection of all elements or any subset thereof from the list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The subject matter disclosed herein can be implemented by hardware comprising several different elements, as well as by a suitably programmed computer. In a device claim enumerating several components, several of these components can be implemented by 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 exert an advantage.

[0371] In the claims, the reference numerals enclosed in parentheses refer to reference symbols in the figures of exemplary embodiments or formulas of embodiments, thereby improving the comprehensibility of the claims. These reference numerals should not be construed as limiting the claims.

Claims

1. A computer-implemented method (900) for determining encryption computation parameters for performing encryption computation on noisy ciphertext, comprising: - Access (910) represents the data of the computation graph of the encrypted computation; - Get (920) divide the computation graph into a plurality of subgraphs, wherein a subgraph represents a subcomputation that produces an output ciphertext with noise independent of the input, and the subgraph is defined by a type from a set of one or more types, and the subgraph is defined by zero or more instantiation parameters of the type; - Limit the encryption calculation parameters of the corresponding group (930) according to the corresponding type; - Perform optimization of the encryption computation parameters described in (940), wherein: - The encryption calculation parameters are optimized to minimize the computational cost of performing the encryption calculation according to the encryption calculation parameters; and The encryption computation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption computation, wherein the noise constraints are based on corresponding noise constraints of the corresponding subgraph, wherein the noise constraints of a subgraph of a given type are limited by a noise constraint function of the given type, the noise constraint function of the given type taking at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input. - Based on the instantiation parameters of the first and second subgraphs, determine that the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph; and - Eliminate the noise constraints of the second subgraph from the optimization.

2. The method (900) of claim 1, wherein the first subgraph and the second subgraph are parameterized by a noise limit and by the 2-norm of the applied linear mapping, wherein 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.

3. The method (900) according to claim 1 or 2, wherein the computational cost is minimized based on a cost function, wherein the cost function is based on the corresponding cost of the corresponding subgraph, wherein the cost of a subgraph of a given type is limited by a cost function of the given type, the cost function of the given type taking at least the cryptographic computation parameters of the given type as input and being independent of the instantiation parameters.

4. The method (900) according to claim 1 or 2, wherein the encryption calculation parameters include one or more of the following: programmable bootstrap decomposition base, programmable bootstrap decomposition level, key switching decomposition base, and key switching decomposition level.

5. The method (900) according to claim 1 or 2, wherein one of the plurality of subgraphs includes a programmable bootstrap for generating the output ciphertext and noise rounding of the output ciphertext.

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

7. The method (900) according to claim 1 or 2, wherein the encryption computation parameter identifies the corresponding key switching key and / or bootstrap key to be used for the corresponding subgraph, wherein if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, then the key switching key and / or bootstrap key of the first subgraph is constrained to add at most as much noise as the key switching key and / or bootstrap key of the second subgraph.

8. The method (900) according to claim 1 or 2, wherein the cryptographic computation parameter indicates the corresponding number of programmable bootstraps to be executed during the application of the corresponding linear mapping for the corresponding subgraph of the application corresponding linear mapping.

9. The method (900) of claim 8 further comprises splitting the corresponding linear mapping into a plurality of corresponding linear mappings corresponding to the number of programmable bootstraps by minimizing the maximum 2 norm of the corresponding linear mapping.

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

11. The method (900) according to claim 1 or 2, further comprising: - Transform an unencrypted computation graph into an encrypted computation graph; and / or - Compile the computation graph of cryptographic computation into a set of instructions for the cryptographic computation engine; and / or - Perform cryptographic calculations based on the determined cryptographic calculation parameters.

12. A configuration device (110) that determines encryption calculation parameters for performing encryption calculations on noisy ciphertext, comprising: - A memory (130) for storing data representing a computation graph of the encrypted computation; - Processor subsystem (140), said processor subsystem (140) being configured to: - Obtain the division of the computation graph into multiple subgraphs, wherein each subgraph represents a subcomputation that produces an output ciphertext with noise independent of the input, and the subgraph is defined by a type from a set of one or more types, and the subgraph is defined by zero or more instantiation parameters of the type; - Limit the encryption calculation parameters for the corresponding group based on the corresponding type; - Optimize the encryption computation parameters, wherein: the encryption computation parameters are optimized to minimize the computational cost of performing the encryption computation based on the encryption computation parameters; and the encryption computation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption computation, wherein the noise constraints are based on corresponding noise constraints of a corresponding subgraph, wherein the noise constraints of a subgraph of a given type are limited by a noise constraint function of the given type, the noise constraint function taking at least the encryption computation parameters of the given type and the instantiation parameters of the subgraph as input. - Based on the instantiation parameters of the first and second subgraphs, determine that the noise constraint of the first subgraph is at least as stringent as the noise constraint of the second subgraph; and - Eliminate the noise constraints of the second subgraph from the optimization.

13. A temporary or non-temporary computer-readable storage medium (1000) comprising data (1020) representing instructions, which, when executed by a processor system, cause the processor system to perform the method according to any one of claims 1-11.

Images