Optimizing cryptographic computation parameters

Abstract

Some embodiments relate to a computer-implemented method of determining cryptographic computation parameters for performing cryptographic computation on a noisy ciphertext. The computational graph is divided into a plurality of sub-graphs, which are defined by one type and by instantiation parameters of the type. Encryption calculation parameters of the corresponding groups are defined for the corresponding types. Optimization of the cryptographic calculation parameters is performed such that the calculation cost of performing the cryptographic calculation according to the cryptographic calculation parameters is minimized. The cryptographic calculation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the cryptographic calculation. The noise constraint is based on a corresponding noise constraint of a corresponding sub-graph, where the noise constraint is defined by a noise constraint function of the type that takes at least the cryptographic calculation parameters of the type and the instantiation parameters of the sub-graph as inputs.

Description

Technical Field

[0001] The presently disclosed subject matter relates to computer-implemented methods, corresponding apparatus, and computer-readable media for determining cryptographic calculation parameters. Background Art

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

[0003] Even if the result of a computation is returned in encrypted form, when decrypted, the expected output is the same or very close to it as if the operation was performed on the unencrypted data. Homomorphic encryption can be used to outsource storage and computation to preserve privacy. This allows data to be encrypted and outsourced to a cloud environment for processing and / or storage while always being encrypted.

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

[0005] Specifically, there are homomorphic cryptography techniques that can, at least in principle, be used to compute any function that encrypts data. Such techniques are known as "fully homomorphic encryption" (FHE) techniques.

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

[0007] When a data item has just been encrypted, the noise is low and the encryption is recent. For example, the amount of noise is low so that if the data item is to be decrypted, the noise can be removed at some point in the decryption process (e.g., by rounding). On the other hand, the noise should be high enough to make attacks on the system difficult enough. For example, many homomorphic encryption schemes may be attacked by linear algebra or other efficient algorithms (e.g., lattice reduction algorithms) under the assumption that there is no noise. When the data item is encrypted, noise is added, and the noise is selected to make attacks difficult, while homomorphic operations can still be performed and decryption is still possible.

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

[0009] A specific class of fully homomorphic encryption schemes is the TFHE class homomorphic encryption scheme. This scheme is described in "Programmable bootstrapping enables efficient homomorphic inference of deep neural networks" by I. Chillotti et al., Cyber ​​Security Cryptography and Machine Learning (CSCML 2021), Volume 12716 of Lecture Notes in Computer Science, Pages 1-19, Springer, 2021 (incorporated herein by reference). The TFHE class scheme itself differs from other FHE schemes in that it supports a relatively efficient technique for bootstrapping; in addition, they can simultaneously evaluate functions during the bootstrapping operation, which is called programmable bootstrapping. Conventional bootstrapping is equivalent to programmable bootstrapping with an identity function.

[0010] Interestingly, the output of programmable bootstrapping has a certain amount of noise that is independent of the noise in the input ciphertext. Thus, by performing programmable bootstrapping, the noise in the input ciphertext can be reduced to a fixed amount while possibly applying a function to the input ciphertext. By performing programmable bootstrapping at appropriate times, cryptographic calculations with infinite multiplicative complexity can be performed.

[0011] The operation of cryptographic computing techniques, and in particular the operation of TFHE-like schemes, is affected by a variety of cryptographic computing parameters. These include various parameters of the cryptographic scheme itself (e.g., the number of mask values ​​and moduli used for LWE), as well as parameters that affect specific cryptographic operations (such as the decomposition level used in programmable bootstrap operations).

[0012] The parameters of cryptographic calculations need to be chosen carefully. In general, the parameters can affect the security of the cryptographic calculations (e.g., the more noise added when encrypting, or the larger the number of mask values, the harder it is to break the encryption scheme), the precision of the calculation results (e.g., the size of the polynomial affects the number of bits of precision with which the calculation can be performed), and the computational requirements and storage requirements for performing the calculations (e.g., the decomposition level of programmable bootstrapping and the LWE parameters affect the size of the bootstrapping key and the computational complexity of performing this operation).

[0013] This means that the choice of parameters involves multiple trade-offs. For example, in order to reduce the minimum noise while maintaining security, some other parameters of the encryption scheme (e.g., polynomial size and / or GLWE dimension) can be increased. At the same time, the cost of various encryption calculation operators depends on the polynomial size and / or GLWE dimension, resulting in a trade-off between noise and cost: it is desirable to use less noise to ensure the correctness of the calculation, while at the same time, using a small amount of noise will increase the computational cost due to the need to increase other parameters. Summary of the invention

[0014] It would therefore be desirable to provide automated techniques for determining appropriate cryptographic computation parameter values ​​for performing a given cryptographic computation.

[0015] According to one aspect of the invention, there is provided a computer-implemented method of determining cryptographic calculation parameters, as defined in the claims. According to another aspect, there is provided an apparatus corresponding to the computer-implemented method, as defined in the claims. According to another aspect, there is provided a computer-readable medium, as defined in the claims.

[0016] A number of embodiments relate to performing optimization of encryption calculation parameters for performing encryption calculations on noisy ciphertext. For example, such parameters may include global parameters used during the entire encryption calculation, such as parameters of an encryption scheme related to encrypting the noisy ciphertext, such as the polynomial size used and / or the GLWE dimension.

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

[0018] Interestingly, the inventors have realized that the computation graph of a cryptographic computation is in many cases composed of a specific pattern that can occur multiple times throughout the cryptographic computation. For example, the pattern can be applying a cryptographic linear map to one or more inputs, followed by a key switch, followed by a modulus switch, and followed by a blind rotation and sample extraction.

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

[0020] Then, optimization can be expressed according to the computation by this representation of type and instantiation parameters. Optimization can take into account computational cost, security and accuracy. Specifically, optimization can minimize computational cost while ensuring that the computation is sufficiently secure and accurate. In this way, a solution can be obtained that is the most efficient in computation given security and accuracy requirements. Optimization can be configured to ensure that additional constraints are met, such as constraints on storage requirements (such as the number of different bootstrap keys or key switching keys used in encryption calculations). However, in many cases, this is not necessary, such as storage requirements can be encoded by defining them as part of the optimization problem so that it is not necessary to ensure that they are all met separately.

[0021] Interestingly, security and accuracy requirements can be expressed in terms of subdividing the computation graph into subgraphs with corresponding types and instantiation parameters. That is, the optimization can constrain the cryptographic computation parameters to satisfy a noise constraint on the ciphertext noise computed when performing the cryptographic computation. This noise constraint can be defined by a noise constraint function defined for a subgraph of a corresponding type. The noise constraint function can take as input at least the cryptographic computation parameters of a given type and the instantiation parameters of a specific subgraph. Thus, the overall noise constraint can include the corresponding constraint for the corresponding subgraph given by the noise constraint function.

[0022] Interestingly, the noise constraints are defined in terms of the noise constraint functions of the corresponding subgraph type, which allows the optimization to be performed in an efficient manner. The optimization problem is expressed in terms of subgraphs rather than in terms of separate encryption operations, which greatly reduces the size of the constraint satisfaction problem to be solved. In addition, by using noise constraint functions, the optimization problem is expressed in terms of multiple instances of the same constraint function to be satisfied. In particular, this formulation makes it easier to perform the optimization because it makes it possible to eliminate constraints dominated by other constraints; either explicitly or automatically by the optimizer used.

[0023] The noise constraint can explicitly constrain the ciphertext noise, for example, by stipulating that the noise of the corresponding ciphertext is below a corresponding limit, and the noise constraint can implicitly constrain the ciphertext noise according to the parameters of the encryption scheme used. Specifically, at a given security level, the product of the GLWE dimension and the polynomial size (as 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 certain security level and less than the maximum noise required to achieve a certain accuracy, both security and accuracy can be ensured.

[0024] In one embodiment, 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 subgraph and the second subgraph. That is, if the noise constraint of the first subgraph is satisfied for a given set of encryption calculation parameters, this may mean that the noise constraint of the second subgraph is also satisfied. Interestingly, this can be achieved by calculating the expression according to the type and the instantiation parameters, because for a given type, it can be determined based on the instantiation parameters whether the noise constraint of the first subgraph of the type is at least as strict as the noise constraint of the second subgraph of the type. In some cases, such 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 enables the noise constraint of the second subgraph to be eliminated from the optimization. This allows the size of the optimization problem to be greatly reduced, making it more effectively solved.

[0025] In one embodiment, the first subgraph and the second subgraph can be parameterized by a noise bound and by the 2-norm of the applied linear mapping. The noise bound can correspond to the desired minimum accuracy of the encrypted value, and thus the maximum amount of noise. The 2-norm can be used as a parameter because the increase in noise due to applying the linear mapping can be expressed in terms of the 2-norm.

[0026] For example, the subgraph represented by these parameters may include applications: linear mapping; key switching; modulus switching; and blind rotation and sample extraction. This is a common pattern of cryptographic computations, and in fact in some cases, entire cryptographic computations may consist of 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 subgraph. That is, 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 parameter conditions, if any), then this may be the case. This allows the number of constraints required to be significantly reduced. Specifically, the noise bound can be represented by a discrete parameter. This discrete parameter can have a relatively small number of possible values, such as 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 saved together with the remaining subgraphs that are 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 encryption calculation. Therefore, interestingly, at least for this type of subgraph, the complexity of satisfying the noise constraint can be made independent of the size of the calculation, which improves efficiency, particularly for large encryption calculations.

[0028] In principle, the computational cost can be determined in various ways, for example by simulation or measurement of the real-time runtime of performing the encryption computation.

[0029] However, in one embodiment, the computational cost can be minimized based on a cost function. Similar to the noise constraint, the cost function can also be based on the corresponding cost of the corresponding subgraph, wherein the cost of the subgraph of a given type is defined by the cost function of the given type. This cost function can at least use the encryption calculation 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 rely on function expressions with optimization targets, such as using a branch and bound method based on the use of lower and upper limits of function expressions, optimization based on variable changes, or elimination of non-optimal solutions based on the independent variables of function expressions.

[0030] Specifically, in one embodiment, the cost function of a subgraph of a given type may be independent of the instantiation parameters of the subgraph. In other words, the computational cost of a subgraph of a given type may 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 the way the calculations are performed, and the applied linear mapping may have only a limited impact, such as constituting at most 10% or at most 1% of the computational cost of performing the encryption calculations 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 embodiment, a subgraph may represent a subcomputation that produces an output ciphertext with noise that is independent of the input, that is, the noise does not depend on the noise of the input ciphertext of the subgraph, nor on 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 enables the noise constraints of the subgraph to be defined 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 a subgraph during the entire computation, or at least all inputs to a subgraph of a given type, can be assumed to have the same amount of noise. As illustrated by using the 2-norm and the noise bound as instantiation parameters, this can be particularly helpful in eliminating some noise constraints that are less stringent than other noise constraints.

[0032] In particular, a subgraph may have a last part that produces an output ciphertext with noise that is independent of the input: typically blind rotations and sample extraction, optionally followed by rounding, as discussed in more detail elsewhere. Apart from this last part, the subgraph typically does not include cryptographic operations that produce noise that is independent of the input. In particular, the noise may increase monotonically in the subgraph until the last part is reached. This again simplifies the optimization problem, since it is sufficient to determine the noise of the input of the last part (the noise being the maximum noise during the subcomputation) and to constrain this noise, e.g. to provide sufficient accuracy.

[0033] In one embodiment, the encryption calculation parameters may include one or more of the following: the decomposition base of programmable bootstrap, the decomposition level of programmable bootstrap, the decomposition base of key switching, and the decomposition level of key switching. These parameters can be defined as global encryption calculation parameters, or can be specifically defined for a given type. For these parameters, a trade-off is made between the noise generated and the efficiency of performing the corresponding operation. For example, by increasing the level, the computational complexity increases, but the noise decreases. In addition, these operations form an important part of the total computing power of the encryption calculation. Therefore, optimizing these parameters has a particularly significant effect on the encryption calculation generated.

[0034] Note that different types of subgraphs may 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 may themselves have the same cryptographic operation structure, but with different bases and / or level parameters, corresponding to performing the same operation but with different bootstrap keys and / or key switching keys. Therefore, by appropriately defining the types and parameters, optimization with an appropriate level of flexibility may be achieved.

[0035] In one embodiment, a subgraph may include a programmable bootstrap that produces an output ciphertext, and noise rounding of the output ciphertext. In other words, the ciphertext may be rounded so that it encrypts the same value with different noise. Interestingly, by performing noise rounding, it is achievable that the programmable bootstrap becomes deterministic, and in particular, it becomes 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 a few of the least significant bits in the ciphertext representing the ciphertext noise typically depend on the rounding error of the FFT implementation used. Although such rounding errors may not affect the security or correctness of the cryptographic calculation itself, it may still be desirable that the calculation is deterministic. For example, it allows the same cryptographic calculation to be performed by different parties, possibly using different software and / or hardware settings, and allows verification that the resulting ciphertext is the same, thereby providing some assurance that the calculation was performed correctly.

[0037] Specifically, in one embodiment, cryptographic calculations can be performed by a mining device of a blockchain, while rounding allows the results of the cryptographic calculations as determined by the mining device to be compared with each other without the need for decryption. In this way, consensus can be reached on the cryptographic output of the calculation, thereby confirming that the expected cryptographic calculation was indeed performed.

[0038] In one embodiment, the optimization of the encryption calculation parameters can be performed by a branch and bound method. Compared with the brute force method, by performing the branch and bound method, the optimization can be performed significantly more efficiently, while at the same time ensuring that the best possible values ​​of the encryption calculation parameters are obtained.

[0039] In one embodiment, optimization can be used to determine the key switching key and / or bootstrap key to be used for the corresponding subgraph. A predetermined number of key switching keys and / or bootstrap keys can be used. The corresponding key will add a corresponding amount of noise and will have a corresponding computational cost. The computational cost of adding less noise may be higher, which requires a trade-off. For a given subgraph, the encryption calculation parameters can identify which predetermined key switching key and / or bootstrap key is used in the subgraph. In this way, for the corresponding subgraph, a corresponding optimal choice can be made, allowing an overall better solution, compared to if the same key switching key and / or bootstrap key is used in the entire encryption calculation, or if the key switching key and / or bootstrap key of a given subgraph is predetermined.

[0040] Interestingly, when optimizing the key switching key and / or bootstrap key to be used for the corresponding subgraph, the parameter space of the parameters indicating the key to be used can be greatly reduced. That is, if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph, the key switching 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, in the case where the subgraphs are sorted according to their noise constraints, the selection of a key switching key or bootstrap key essentially corresponds to a linear search of the list so sorted (unlike selecting each subgraph individually), which allows the optimization problem to be solved very efficiently.

[0041] In one embodiment, for a corresponding subgraph to which a corresponding linear mapping is applied, the encryption calculation parameter may indicate a corresponding number of programmable bootstraps to be performed during the application of the corresponding linear mapping. By performing programmable bootstraps during the application of the linear mapping, noise can be reduced at the expense of significant computational cost. By using the number of bootstraps as a parameter that can be optimized, an optimal choice can be made for this trade-off.

[0042] In one embodiment, when at least one programmable bootstrap is to be performed in a linear mapping, it can be automatically determined how the linear mapping is split into multiple linear mappings. As the inventors appreciate, this can be accomplished by minimizing the maximum 2-norm of the corresponding linear mapping. This is advantageous because it minimizes the noise after the corresponding linear mapping, making it easier to satisfy the noise constraint.

[0043] Interestingly, the inventors realized that the parameter space of the parameter indicating the number of programmable bootstraps to be performed can be greatly reduced. That is, 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 can be constrained to be greater than or equal to the number of programmable bootstraps of the second subgraph. Therefore, sorting the subgraphs by the noise constraint, searching for the optimal number of programmable bootstraps for each subgraph can essentially correspond to a linear search in this sorted list, as opposed to individual selection of each subgraph.

[0044] In one embodiment, the calculation graph can be obtained by the transformation of the unencrypted calculation graph. To this end, a technique known per se can be used. The transformation can directly output the calculation graph of the encrypted calculation so that the calculation graph has been divided into a plurality of subgraphs. In one embodiment, the calculation graph of the encrypted calculation can be compiled into a set of instructions for an encrypted calculation engine. The instructions can be based on the determined encrypted calculation parameters. Therefore, a compiler can be set, the compiler uses plaintext calculation or ciphertext calculation as input, and outputs instructions for an encrypted calculation engine, and the encrypted calculation engine performs a given calculation in an optimal manner. In one embodiment, the encrypted calculation can be performed according to the determined encrypted calculation parameters, which allows the encrypted calculation to be performed in a combined manner of efficiency, accuracy, and security.

[0045] Typically, cryptographic computations may be performed in a TFHE setting. This means that the ciphertext used to encrypt the value allows for programmable bootstrapping operations. In particular, the ciphertext may be an LWE (Learning with Errors) encryption, that is, an encryption based on a cryptographic assumption that the learning with errors problem is difficult. As known per se, programmable bootstrapping may evaluate LWE decryption in the exponent of a GLWE encrypted monomial, for example implemented as a so-called blind rotation. In particular, programmable bootstrapping may comprise computing an encrypted polynomial product of a bootstrap monomial and a test polynomial, the bootstrap monomial representing the plaintext value as an exponent. The test polynomial may represent a function and / or lookup table evaluation value applied to the input by programmable bootstrapping. Programmable bootstrapping may use a bootstrap key, which enables programmable bootstrapping to be performed instead of decryption of the ciphertext.

[0046] The improved technology of calculating encrypted data provided can be applied to a wide range of practical applications. These practical applications include the encryption evaluation of software programs without access to plaintext data. For example, people can evaluate medical diagnostic software on medical data without access to the medical 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, and the medical images are obtained by a variety of acquisition forms, 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 embodiment, the provided techniques can be used to evaluate a neural network with respect to encrypted inputs. The party evaluating the neural network may or may not have access to the plaintext of the training parameters of the neural network (e.g., weights and biases). In general, the techniques provided herein (e.g., improved encryption calculation parameters) improve the efficiency of evaluating a neural network and / or reduce the storage requirements and transmission requirements for the ciphertext or key material used.

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

[0049] In one embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer.Preferably, the computer program is embodied on a computer readable medium. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0051] FIG. 1 a schematically illustrates an example of an embodiment of a configuration device;

[0052] FIG. 1 b schematically illustrates an example of an implementation of an encryption computing device;

[0053] FIG. 1c schematically illustrates an example of an implementation of an encryption computing system;

[0054] Figure 2 A detailed embodiment showing how to determine the parameters;

[0055] Figure 3 A detailed embodiment of the constraint on ciphertext noise is shown;

[0056] FIG4a shows a detailed embodiment of a type of sub-graph;

[0057] FIG4 b shows a detailed embodiment of ciphertext noise;

[0058] FIG4c shows a detailed embodiment of encryption calculation parameters;

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

[0060] FIG6 a shows a detailed embodiment of a type of sub-graph;

[0061] FIG6 b shows a detailed embodiment of a type of sub-graph;

[0062] FIG. 7 a shows a detailed but non-limiting embodiment of determining a key switching key and / or a bootstrapping key to be used;

[0063] FIG7 b shows a detailed embodiment of determining the number of programmable bootstraps;

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

[0065] FIG. 9 a schematically illustrates an example of an embodiment of a method of determining encryption calculation parameters;

[0066] FIG9 b schematically illustrates an example of an implementation of a cryptographic method for performing encryption calculations;

[0067] Fig.10 schematically illustrates a computer readable medium having a writable component according to one embodiment;

[0068] Fig.11 A representation of a processing system according to one embodiment is schematically shown. DETAILED DESCRIPTION

[0069] Although the presently disclosed subject matter may be implemented in many different forms, one or more specific embodiments are shown in the drawings and will be described in detail herein, with the understanding that the disclosure should be considered as an example of the principles of the presently disclosed subject matter and is not intended to be limited to the specific embodiments shown and described.

[0070] Hereinafter, for the purpose of understanding, the elements of the embodiments are described in operations. However, it will be apparent that the corresponding elements are arranged to perform the functions described as being performed by them.

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

[0072] Various embodiments relate to cryptographic computations of noisy ciphertext. When generating a noisy encryption of an unencrypted value (in other words, when determining a recently encrypted ciphertext), the noise used may be obtained from a distribution parameterized by a parameter σ, denoted as χ(σ). As an example, the distribution χ may be a central normal distribution, and the parameter σ may be a standard deviation.

[0073] When cryptographic operations are performed on ciphertexts, the noise included in them is typically modified as a side effect. The connection between the input noise and the output noise of an operation can be represented by a noise formula. The noise formula can model the evolution of the noise as a result of this operation. In particular, during the operation on the ciphertext, the distribution of noise within the ciphertext typically changes. In particular, if the noise within the ciphertext is obtained from a normal distribution with a larger standard deviation σ, then the ciphertext can be said to contain more noise than another ciphertext.

[0074] Specifically, multiple implementations use LWE (Learning to Resistant Errors) encryption. Typically, an LWE-type ciphertext may include one or more mask values ​​and a main value, the main value being derived from the mask value, the plaintext value, and the key, and the main value including noise. The value is typically an integer modulo a given modulus q. Multiple implementations also use GLWE (Generalized Learning to Resistant Errors)-type ciphertexts. GLWE-type ciphertexts may include one or more mask polynomials and a main polynomial, the main polynomial being derived from the mask polynomial, the plaintext polynomial, and the key, and the main polynomial including polynomial noise. GLWE-type ciphertexts may be limited to modulo the modulus q and the quotient polynomial p(X). LWE ciphertexts may be considered to be a specific type of GLWE ciphertext in which the order of the quotient polynomial is 1. Another specific type of ciphertext is an RLWE (Ring Learning to Resistant Errors) ciphertext in which the number of mask polynomials is 1.

[0075] Specifically, according to the key News The GLWE ciphertext can be defined as follows:

[0076]

[0077] here, is a key where the coefficients are sampled, for example, from a uniform binary distribution, a uniform ternary distribution, or a Gaussian distribution. is the appropriate encoding (e.g., scaling) of the input message. yes The polynomial in which the coefficients are, for example, Sampling from a uniform distribution within , E is The noise (error) polynomial in , such that its coefficients are, for example, derived from a Gaussian distribution χ σ The parameter k is a positive integer representing the number of polynomials in the GLWE key. To simplify the notation, S k+1 can be limited to -1. In this embodiment, the LWE ciphertext is a 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 lower case, respectively, for example, ct q and s. The RLWE ciphertext in this embodiment is a GLWE ciphertext, where k=1 and N>1, for example, a power of 2.

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

[0079] It may be noted that due to the relationship between the GLWE dimension k of Gaussian noise (e.g., the minimum noise for a given number of bits of security), the polynomial size N, and the standard deviation σ, one of these variables can be calculated from the other. Specifically, throughout this specification, given a particular distribution of keys (e.g., binomial, trinomial, or Gaussian), the product k·N, and the security level λ, the minimum noise in recent ciphertext to achieve a security level can be calculated as:

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

[0081] The above embodiments describe a symmetric variant of the key, GLWE. As known per se, the techniques provided herein are equally applicable to the public key variant. In the latter case, for example, the above key can be used as a private key, wherein the public key comprises an encryption of one or more zeros, see, for example, R. Rothblum, "Homomorphic encryption: From private-key to public-key", Theory of Cryptography (TCC 2011), Volume 6597 of Lecture Notes in Computer Science, pages 219-234, Springer, 2011 (incorporated herein by reference).

[0082] Several embodiments operate in a TFHE setting, which means that a ciphertext that supports programmable bootstrapping (PBS) is used. The programmable bootstrapping can take as input a ciphertext and output a ciphertext of the same message, or a function and / or lookup table of the message with noise independent of the input. The PBS can include homomorphic decryption of the input ciphertext in the exponent of the evaluation polynomial. The following references provide examples of encryption schemes in a TFHE setting, which can be combined with the techniques provided 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 may be represented as integers modulo a modulus q. Such values ​​modulo integers may be equivalently considered to be elements of a discrete torus, as is done in several of the references mentioned above. In particular, several references use the real torus To represent the message space and ciphertext space, and by using the arithmetic modulus 2 32 or 2 64 To implement This can be equivalently viewed as corresponding to using Integers in (use q=2 32 Or q = 2 64 ) is calculated. Therefore, an integer modulo a given modulus and a discrete torus element may be used alternatively, specifically, in and There are isomorphisms between them, as also pointed out 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-like schemes make them an attractive choice for a wide range of applications. Because bootstrapping is relatively efficient compared to many other FHE schemes, it is more feasible to perform relatively complex computations (e.g., with a multiplication depth of at least 10, at least 50, or at least 100). Specifically, the cryptographic parameters of TFHE-like schemes can be selected based on the desired accuracy and the computational cost incurred, without increasing the amount of homomorphic operations and circuit depth. In contrast, the fact that bootstrapping can be very inefficient in other FHE schemes makes these schemes typically applied in a balanced manner, meaning that their parameters are selected in dependence on a given computation so that it can be performed without bootstrapping. However, such a balanced approach is not feasible for more complex computations, so in such cases, TFHE-like schemes are particularly beneficial.

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

[0089] Specifically, the LWE-based ciphertext and / or GLWE-based ciphertext used in the TFHE setting of this document may use a relatively small (e.g., at most 32 bits, at most 64 bits, or at most 128 bits) modulus. This modulus is typically selected independently of the computation to be performed, for example, the modulus is selected depending on the desired accuracy and / or efficiency. The parameters N, k, and / or σ may be predefined or may be outputs of the optimization described herein. For example, N may be set to at least 512 and / or at most 2048, 4096, or 16384, for example, to 1024. For example, in one embodiment, RLWE is used, where N is at least 512 and / or at most 2048 or 4096, for example, 1024, and k=1. Such values ​​of N are typically not used in non-TFHE-type encryption schemes, where such values ​​would severely limit the computations that can be performed; instead, in non-TFHE-type encryption schemes, both q and N are typically chosen based on the desired level of security, so that q can be larger.

[0090] Throughout this specification, the term "standard score" may be used as follows. is the error probability, and Φ is the CDF of A. errThe standard score can be defined as

[0091]

[0092] Make

[0093]

[0094] The standard score can be applied to the confidence interval of the central normal distribution as follows. Let And p err ∈[0,1]. Let z * (p err ) is p err So:

[0095]

[0096] Figure 1a schematically illustrates an example of one implementation of configuring device 110. Device 110 may be used to determine cryptographic computation parameters to perform cryptographic computations on noisy ciphertext.

[0097] The device 110 may include a processor system 130, a memory 140, and a communication interface 150. The memory 140 may include a local memory, such as a local hard drive or an electronic memory. The memory 140 may include a non-local memory, such as a cloud memory. In the latter case, the memory 140 may include a memory interface with the non-local memory. For example, the memory 140 may be used to store data representing a computational graph of an encrypted computation. In this representation, the computational graph may be divided into a plurality of subgraphs. The subgraph may be defined by one of a set of one or more types and by zero or more instantiation parameters of the type.

[0098] The device 110 can communicate internally, communicating with other devices, external memory, 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. The computer network can be the Internet. Optionally, the device may include a connection interface 150, which is 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) can use other communication protocols or media (e.g., an internal data bus).

[0099] In the device 110, the communication interface 150 can be used to send or receive digital data. For example, the device 110 can be configured to receive or send data representing a calculation to be performed in an encrypted form. For example, the device 110 can obtain data representing a calculation graph of an unencrypted calculation or an encrypted calculation, wherein the data of the calculation graph of the encrypted calculation is optionally divided into multiple subgraphs when received, as already described in this document. The device 110 can determine encryption calculation parameters so as to optimally perform this calculation in an encrypted form. The device 110 can send data representing encryption calculation parameters, specifically, instructions for an encryption calculation engine, for performing operations in an encrypted form according to the determined encryption calculation parameters.

[0100] The execution of device 110 may be implemented in a 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 at different locations. For example, device 110 may use cloud computing.

[0101] The processor subsystem 130 may be configured to define corresponding sets of encryption calculation parameters of corresponding types. The processor subsystem 130 may be further configured to perform optimization of encryption calculation parameters, including corresponding sets of encryption calculation parameters of corresponding types. In this optimization, the encryption calculation parameters may be optimized so as to minimize the computational cost of performing encryption calculations according to the encryption calculation parameters. In addition, in this optimization, the encryption calculation parameters may be constrained so as to satisfy noise constraints on ciphertext noise when performing the encryption calculations. The noise constraints may be based on corresponding noise constraints of corresponding subgraphs. The noise constraints of a subgraph of a given type may be defined by a noise constraint function of the given type, and the noise constraint function takes at least the encryption calculation parameters of the given type and the instantiation parameters of the subgraph as input.

[0102] Some of the figures show functional units, which may be functional units of a processor system. For example, the figures may be used as blueprints of possible functional organizations of a processor system. In most of the figures, 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 in whole or in part in computer instructions stored in a device such as device 110 (e.g., stored in an electronic memory of device 110) and executable by a microprocessor of device 110. In a hybrid embodiment, the functional units are implemented partially in hardware (e.g., a coprocessor, such as an arithmetic and / or cryptographic coprocessor) and partially in software stored and executed on device 110.

[0103] FIG. 1 b schematically illustrates an example of an embodiment of an encryption computing device 119. The encryption computing device 119 can be used to perform encryption computing. The encryption computing can use homomorphic encryption cryptography. For example, the device 119 can be used to perform encryption computing, such as 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 computing. The computing is performed according to the encryption computing parameters determined as described herein, for example, by the device 110 of FIG. 1 a. The device 119 can determine the parameters itself, for example, the device 119 can be combined with the device 110 of FIG. 1 a.

[0104] Device 119 may include a processor system 139, a memory 149, and a communication interface 159. Processor system 139, memory 149, and communication interface 159 may be implemented as discussed for the corresponding components of FIG. 1a. Memory 149 may be used to store representations of cryptographic calculations to be performed, and / or cryptographic calculation parameters based on which the cryptographic calculations are performed. Thus, device 119 may include memory 149 that stores cryptographic calculation parameters. The cryptographic calculation parameters may be included in the representation of the cryptographic calculation.

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

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

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

[0108] As an alternative or in addition to using cryptographic calculation parameters as described herein, the processor subsystem 139 may apply a noise rounding operation to the output having implementation-dependent noise (e.g., programmable bootstrap, e.g., relative to Figure 8 The ciphertext of the one being discussed).

[0109] Figure 1c schematically illustrates an example of one implementation of a cryptographic computing system 100. The system 100 is configured to perform cryptographic computing using homomorphic encryption (eg, fully homomorphic encryption).

[0110] The system 100 in this embodiment includes a compiler device 111, a data provider device 113, and an encryption computing device 112. The compiler device 111 can be combined with the encryption computing device 112 or the data provider device 113 in a single device. The device 112 can be configured to receive encrypted data items from the data provider 113. At least one or more data items can be received in encrypted form. One or more other data items can be received in plain text. The device 112 can be configured to receive a homomorphic executable file for performing an encryption calculation from the compiler device 111.

[0111] Device 112 may perform computations as described herein on received data items and possibly also stored data items. Interestingly, computations may be performed by the device on encrypted data without decrypting the data, such as without converting encrypted data items to data in plain text form.

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

[0113] Optionally, the compiler device 111 or the data provider device 113 may be further configured to generate key material for the cryptographic computing device 112 to perform cryptographic computing, such as a bootstrap key for performing programmable bootstrapping as discussed herein. The device generating the key material may provide the bootstrap key 151 to the device 112, such as by sending it via the computer network 150, uploading it to a shared memory, 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 cryptographic computing system 100 may include multiple cryptographic computing devices, for example, two, three, or more than three. The cryptographic computing may be distributed among multiple cryptographic computing devices. The cryptographic computing devices may exchange intermediate computing results (usually encrypted) between each other. Each cryptographic computing device may be implemented as the cryptographic computing device 112 and may perform cryptographic operations as described herein.

[0115] Homomorphic encryption schemes can be applied in many settings. For example, the encryption computing device 112 can be run by a cloud provider. The cloud provider can provide computing and storage services to its clients. By using homomorphic encryption, the data provider device 113 (for example, a client of a cloud provider) can send their data in encrypted form. The cloud provider can still perform the required calculations, and / or the required storage, but cannot know the corresponding plaintext data. For example, the data provider device 113 can encrypt the data item using an encryption key of the type corresponding to the specific homomorphic encryption system used. When the calculation result is received from the encryption computing device 112 by the data provider 113, 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 usually are.

[0116] For example, the encryption computing system 100 may be configured to train a machine learning model (e.g., an image classifier, such as a medical model) without the encryption computing device having access to plaintext data items. For example, even without using bootstrapping, it is possible to perform linear regression on the input data. For example, with bootstrapping, it is possible to perform back propagation on the input data. The generated model parameters may be returned to the entity that owns the decryption key. This enables multiple suppliers of medical data to aggregate their data by sending the data to a cloud supplier. The cloud supplier then returns the model parameters without ever using plaintext data. The encryption key may be equal to the decryption key.

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

[0118] Other applications involve database services, such as looking up encrypted data in an encrypted database; for example, the calculation can be a comparison between an input item and a database item. For example, multiple calculations can be combined to produce a database index that matches the index. For example, the database can be a genome database, and the input can be a gene sequence. For example, the system 100 can be used for protection control of a device. For example, a device (even a large device such as a power supply device) can send a sensor value to an encrypted computing device 112, and receive an encrypted control signal in return. The control signal is calculated based on the sensor signal. An attacker of the system may be able to determine the content of the data going to and from one or more encrypted computing devices 112, or even have access to the intermediate data of these devices, but the attacker will not be helped by the data because the data is encrypted. Even if all the encrypted computing devices 112 of the system 100 are completely damaged, the data will not be disclosed because the decryption key is unknown to these devices. Calculating 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 operations.

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

[0120] Encrypted data items can represent all types of data. For example, an encrypted data item can represent a number that needs to be averaged, or a number 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 the 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 color pixel can be represented as multiple color values ​​(e.g., RBG values), which in turn can be represented by a tuple of encrypted data items. For example, three 256-value colors can be encrypted into corresponding encrypted values.

[0121] A set of homomorphic encryption operations may be defined for computation. For example, based on the homomorphic encryption operations, a computation graph (also referred to as an operation circuit or operation network) of the encrypted computation may be established, which is jointly implemented by the compiler device 111 or by the computing device 112 itself. For example, the operation may include a Boolean operation. The manner in which the homomorphic encryption operations are combined (e.g., which operation is applied to which operation object in the pool) determines the computation being performed. For example, the computation may be represented as a list of homomorphic encryption operations that should be performed together with an indication of which encrypted data item the homomorphic encryption operation is performed on, thereby implicitly defining the computation graph by their input / output relationship.

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

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

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

[0125] For example, an FHE operator may represent homomorphic addition (of ciphertext and / or plaintext), homomorphic multiplication with plaintext values, key switching, modulus switching, blind rotation, sample extraction, etc. In various embodiments, for simplicity, blind rotation and sample extraction are represented together as one FHE operator, as these typically occur together in cryptographic computations.

[0126] Alternatively, the encrypted computation graph ECG may be obtained by executing a compilation COMP, 220 which takes as input an unencrypted computation graph PROG, 210 and transforms it into an encrypted computation graph ECG. The compilation COMP may act on the graph PROG of the plaintext operator. By using the provided technique, this graph PROG may be transformed into a corresponding graph ECG of the FHE operator with a correct and optimized set of parameters ECP, 280.

[0127] In FIG. PROG, a plaintext operator may be an operator that operates on data marked as confidential and / or data marked as plaintext data and outputs confidential data. Data marked as confidential may be encrypted in the resulting encryption calculation. For example, some or all plaintext operators may 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 secret data and plaintext data; and

[0132] Unary function application.

[0133] Compiling COMP may map a plaintext operator to a corresponding set of one or more FHE operators. Both the plaintext operator and the set of FHE operators may compute the same operation, where the former operates on plaintext data and confidential data, and the latter operates on plaintext and ciphertext. To this end, techniques known per se in the art may be used. Interestingly, to generate a graph ECG, the techniques described herein may be used to find optimal cryptographic computation parameters.

[0134] In the division operation DIV, the calculation graph ECG can be divided into multiple sub-graphs A subgraph may be defined by a type from a set of one or more types, and by zero or more instantiation parameters of the type. What subgraphs of a particular type may have in common is that the same FHE operators are applied in the same order. For this purpose, several additions and scalar multiplications may be collectively considered as a single FHE operator representing a linear mapping, as also illustrated in FIG. 4a and 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 a variety of optimizations) may be one of the instantiation parameters. A type of subgraph is also referred to as an atomic pattern (AP) category.

[0135] Embodiments of various types of subgraphs are discussed, for example, with respect to Figures 4a, 6a, and 6b. What a particular type of subgraph may have in common is that for a particular FHE operator (such as key switching or blind rotation), the same key material is used; however, the key material may also be used as a parameter, as discussed, for example, with respect to Figure 7a.

[0136] Specifically, a subgraph may represent a sub-computation that results in an output ciphertext having noise that is independent of the input. For example, the output ciphertext may be the output of a programmable bootstrap, or the output of a programmable bootstrap with rounding. Thus, by dividing the encrypted computation graph ECG into a plurality of subgraphs that result in noise that is independent of the input at the outputs of corresponding groups of operations (e.g., in the corresponding cases where blind rotation+sampling extraction, or blind rotation+sampling extraction+rounding is applied), the division operation DIV may operate on the graph.

[0137] As an example, the figure shows that the encrypted computation graph ECG includes three subgraphs S1, 231, S2, 232 and S3, 233. In this embodiment, subgraphs S1 and S3 have the same first type T1, 258, and subgraph S2 has a second type T2. Therefore, by instantiating parameters IP-S1, 251, IP-S3, 253 for instantiating the first type T1 to obtain the corresponding subgraphs S1, S3, and by instantiating parameters IP-S2, 252 for instantiating the second type T2 to obtain subgraph S2, the division DIV can obtain the representation REP, 250 of the encrypted computation graph.

[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 that appear in a given encryption computation graph is typically limited to 1, at most or at least 2, or at most or at least 3. The graph can be separated into multiple subgraphs, for example, each node of the graph can appear only in one subgraph. The number of instantiation parameters of the 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. Multiple embodiments are provided throughout this specification.

[0139] Typically, the manner in which the FHE operation of the encrypted computation graph ECG is performed may depend on the values ​​of a set of encryption computation parameters ECP, 280.

[0140] The encryption calculation parameters ECP may include a set of global encryption calculation parameters ECPG, 285. These parameters may, for example, include parameters of the encryption 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 encryption calculation parameters ECP may further include corresponding encryption calculation parameters ECP1, 285, ECP2, 289 for the corresponding types T1, T2. For example, these parameters may include the decomposition base of the programmable bootstrapping and / or key switching that occurs in the subgraph of the type. and / or decomposition level Specifically, the values ​​of these parameters may be different for different types of subgraphs, although they may also be shared between different types. However, the cryptographic computation parameters ECPi are shared between different subgraphs of the same type, which simplifies the optimization of the cryptographic computation parameters compared to defining these parameters separately for individual FHE operations or subgraphs.

[0142] The cryptographic computation parameters ECP may further optionally include corresponding subgraph-specific parameters ECP-S1, 281, ECP-S2, 282, ECP-S3, 283 for the corresponding subgraphs S1, S2, S3. Such parameters may, for example, identify a set of bootstrap or key switching keys to be used in the subgraph (as illustrated with respect to FIG. 7a), and / or indicate a number of programmable bootstraps to be performed as part of a linear mapping (as illustrated with respect to FIG. 7b).

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

[0144] To determine the value of the cryptographic calculation parameter ECP, an optimization OPT may be performed, 223. The optimization may be configured to find a value for the cryptographic calculation parameter ECP that causes the cryptographic calculation to be performed according to the cryptographic calculation parameter x. The computational cost minimized while ensuring the desired level of security and the correctness of the calculation results (up to a given probability).

[0145] Optimizing OPT can ensure security and correctness by constraining the parameters of the cryptographic calculations to satisfy the noise constraints on the ciphertext noise that occurs when performing the cryptographic calculations. Figure 3 was discussed.

[0146] Specifically, by setting the noise of the newly encrypted ciphertext based on the security parameters of the encryption scheme, the noise bound can guarantee the desired security level so that the desired security level is provided. Specifically, as also discussed elsewhere, given the security level λ and the cryptographic parameters k·N (e.g., included in the global parameters EPG), the noise of the newly encrypted ciphertext can be obtained by mapping Given that the mapping is defined so that recent ciphertexts contain enough noise to hide the plaintext, in other words, by not considering 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 can no longer return the correct plaintext with sufficient probability. This threshold on the amount of ciphertext noise can be called a noise bound. The noise bound can be global, or can be different between multiple parts of the calculation, depending on the accuracy desired at a certain moment during the calculation, in which case it can be defined, for example, based on the instantiation parameters IP-Si of the subgraph. The noise bound can be manually specified or calculated, for example based on the desired accuracy (e.g., the number of bits required to represent the encrypted value) and the maximum expected error probability of decryption.

[0148] In general, the optimization problem (optimizing OPT to find the solution of the optimization problem) can be defined as follows. For a given encryption calculation parameter x, a corresponding set of possible values ​​can be defined, denoted as ε x and is called the search space of x. The search space is usually discrete. The Cartesian product of the search space can be expressed as And can be called an encrypted computation graph In this specification, for the sake of brevity, the diagrams are often omitted. The search space of the simultaneously encrypted computation graph is denoted as ε.

[0149] Typically, some solutions in the search space generate too much noise. The noise feasible set is defined as a set of encryption computation parameters ECP that satisfy the noise constraints, for example:

[0150]

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

[0152] In addition to the noise constraint, there may be additional constraints that the optimization OPT is configured to take into account restrictions on the size of the public key and / or the ciphertext. The constraints may, for example, be related to one or more cryptographic calculation parameters. Typically, such additional constraints may define a further additional feasible set

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

[0154]

[0155] In general, formulated in this way, the optimization problem above has a large search space ε (the number of variables is exponentially distributed) and a noisy feasible set It is not easy to find the noise feasible set when the search space ε is known

[0156] Interestingly, by partitioning the computation graph into multiple subgraphs of corresponding types, the optimization problem can be simplified. Specifically, if the solution is in the feasible set , then this partitioning can make the test computationally cheaper.

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

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

[0159]

[0160] Here, subgraph A i Noise Constraint can be obtained by using a subgraph A of the type i The noise constraint function is used to limit the

[0161] In general, a noise constraint for a type of subgraph may be obtained by propagating a noise estimate of the input to the subgraph through an operation of the subgraph. In general, if a graph ECG is partitioned into subgraphs having outputs (e.g., PBS outputs or rounded PBS outputs) that are noise independent of the input, the inputs to the subgraphs may be assumed to have fixed noise (e.g., derived from global encryption calculation parameters ECPG), and the noise may be assumed to increase across all subgraphs, such that a noise constraint may, for example, constrain the noise of the input to the PBS (or other noise-fixed operation) to be sufficiently small to ensure sufficient accuracy. A detailed embodiment is given with respect to FIG. 4 b.

[0162] Interestingly, the noise constraints of corresponding subgraphs of the same type are thereby defined by the same function NCFj, making the satisfaction of these constraints easier to simplify manually or automatically. Specifically, a constraint elimination operation CE,222 may be performed, in which the noise constraints for the first subgraph Si1 may 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 may be the case not only in the case where the subgraphs are of the same type, but also in the case where the subgraphs are of different types, as exemplified elsewhere in this specification. In any case, in such a case, the noise constraints for the second subgraph may be eliminated from the optimization, making the optimization Opt easier to perform. In other words, the noise feasible set can be a subset of each corresponding feasible set of the subgraph, so a noise feasible set (as a superset of another noise feasible set) does not affect About Figure 5 A detailed example of this is given.

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

[0164] In general, optimization OPT may evaluate the computational cost of performing cryptographic calculations in a variety of ways, such as by performing simulations or by measuring the actual computational cost of performing the cryptographic calculations.

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

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

[0167] As illustrative embodiments, subgraph types considered include linear mapping (in other words, polynomial sums), key switching, modulus switching, blind rotation, and sample extraction. In general, these corresponding operations have corresponding costs, which depend at least on the encryption calculation parameter ECP. For key switching, modulus switching, blind rotation, and sample extraction, the cost function generally does not depend on the instantiation parameters.

[0168] For linear mappings, the cost function may be defined such that 1) the cost function does not depend on the linear mapping being applied (eg, the number of additions and / or the values ​​of scalars 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, since the cost of the linear mapping does not depend on the number of additions / multiplications, but only on the non-specific instance parameters ECPG, ECPi. For example, the cost of a subgraph can be defined as 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 in is the same. Therefore, the optimization

[0172]

[0173] It can be simplified to an optimization problem:

[0174]

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

[0176] In general, there are many different ways for the optimizer OPT to determine the encryption calculation parameter ECP. For example, the optimizer can perform a brute force search. Interestingly, this is particularly feasible in the case of performing constraint elimination CE, as described in this article.

[0177] The preferred way to determine the encryption calculation parameter ECP is by a branch and bound method. As known per se, using the branch and bound method, an optimal solution with respect to the computational cost can be found based on a given upper bound and a given lower bound on the computational cost. Given these bounds, the branch and bound method can be more efficient than a 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 lower bounds and / or upper bounds.

[0179] As an example, consider an encrypted computation graph that includes one or more subgraphs of the type illustrated in FIG. 4a. As discussed with respect to that figure, such a subgraph may be represented as A i =A(v i , t i ), where v i is the 2-norm of the applied linear map, and t i is the noise bound. By using a single subgraph A(ν max , t min )(where ν max = = max{ν i} i∈I And t min =min{t i} i∈I ) replaces all subgraphs of this type, and a set of feasible parameters can be found. By constructing, it is guaranteed that the optimization problem can be solved on this graph and the output is used for the input graph Therefore, the optimization problem can be solved on this graph to store the optimal parameters.

[0180] For a given encrypted 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, the corresponding graph (where ν∈I norm And t∈I p ) solve the optimization problem, for example, solve 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 the cost model may be used. As an illustrative embodiment, for the noise function The following lower limits can be used:

[0182] In the case where a table of feasible parameters has been determined, 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 ). In addition, the initial solution for optimization can be determined based on the table. Interestingly, the table allows to efficiently determine a relatively good initial solution, which improves the efficiency of the optimization.

[0183] As an illustrative example, the lower and upper bounds may take into account the number of programmable bootstraps for the linear mapping, as discussed below with respect to FIG. 7 b .

[0184] The lower bound can be derived based on a parameter corresponding to the maximum number of programmable bootstraps while not taking the cost of the programmable bootstraps into account. Specifically, the maximum splitting probability can be adopted, which reduces the noise at the output of each split polynomial sum. Ignoring the cost of the added PBS, the input graph can be transformed and, with the maximum 2-norm of the minimum noise bound, can be calculated Parameters used in the described case You can choose from a table of possible parameters. Interestingly, although those parameters are may be inadmissible, but they can give lower bounds on the complexity, since An admissible solution of may be at least as costly as one selected in this manner.

[0185] The upper limit can be derived based on the parameters corresponding to the minimum number of programmable bootstraps, while including the cost of performing the maximum number of programmable bootstraps. Specifically, the minimum split possibility is adopted and the cost of the added PBS is taken into account, so that the input graph can be transformed, and the parameters (v max , t min ) can be obtained from a table of possible parameters. In this way, an upper bound on the complexity can be obtained.

[0186] In the case where the cryptographic calculation parameters ECP have been determined, a combination operation COMB, 224 can be applied, wherein the parameters ECP can be substituted into the cryptographic calculation graph ECG (they parameterize said cryptographic calculation graph ECG). Thus, the calculation graph ECG can be compiled into an instruction set HE, 290 for the cryptographic calculation engine. By executing said instructions HE, the cryptographic calculation can be performed according to the determined cryptographic calculation parameters ECP; by the same device executing the optimization OPT, or more typically by a different device receiving said instructions HE.

[0187] Figure 3 Detailed, non-limiting embodiments of constraining ciphertext noise are shown. Specifically, embodiments are given for deriving noise bounds from a desired accuracy, given a value to be encrypted into the ciphertext, and given a desired maximum probability of error. Such noise bounds can be used to define noise constraints for subgraphs, as also described with respect to Figure 2 Specifically, the noise constraint may be defined by determining the maximum ciphertext noise of the subgraph of the type and constraining this maximum noise to remain below a noise bound.

[0188] Specifically, the noise bound t(·) may be a threshold of the noise applied to the ciphertext. The noise bound may be parameterized by an error probability, which may be user configurable. The error probability may also be hard-coded. Note that, for security reasons, the exact noise included in the ciphertext is unknown to the party performing the cryptographic calculations. 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 bound may represent a limit on the variance of errors in the ciphertext. Typically, the noise bound may depend on the number of bits used to represent the precision of the message, and the expected probability that the decryption is correct.

[0189] As an illustrative embodiment, the figure shows a noise bound 310 for an LWE-type ciphertext based on an encoding 320 of a message m. The presented approach to deriving the noise bound is applicable to a variety of cryptographic computation techniques, such as 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, the message m,322 has a bit length p and is encrypted in the most significant bits in a single ciphertext. Specifically, the LWE ciphertext can be a tuple (a1, ..., a n , b), where So that:

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

[0196] - yes in, from integers sampled from a uniform distribution;

[0197] -e+Δm is the encoding 320 of the message, comprising the error e, 326 sampled from the centered Gaussian distribution χσ, and the message Δm, 322 rescaled in the most significant bits.

[0198] In this embodiment, the noise term e, 326 is sampled from a Gaussian distribution. The noise bound may 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 the calculation being correct is up to a given probability p err .

[0199] Specifically, the figure illustrates:

[0200] - Ciphertext modulus q,327, for example, a power of 2 (such as 2 32 , 2 64 or 2 128 ), or a non-power of 2 (such as a prime number);

[0201] - a message m,322, with precision p, i.e. the number of bits used to encode the message;

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

[0203] - 323 padding bits to prevent noise from contaminating the message due to rounding at decryption time;

[0204] - The other digits 324 correspond 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 bound 310 can be obtained based on the number of bits required for padding 321, message 322, padding 323, and error tolerance 324. The noise bound 310 can require that the variance of the noise 326 remain below this value. In this particular case, there is a space 325 between the noise bound and the error so that the noise constraint is met.

[0206] The above embodiments can be adapted to a variety of other encryptions as desired. For example, in the case where the MSB 321 is not required for programmable bootstrapping, the MSB 321 can be removed, 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 as "WOPBS" in this specification. This produces a noise margin that is twice as high, for example:

[0207]

[0208] More generally, the noise bound can be calculated as

[0209]

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

[0211] Interestingly, given the encoding and error probabilities, the noise bound may depend only on the desired accuracy of the message m. In particular, the number of possible values ​​that the noise bound may reach may be relatively small, for example, the number of possible values ​​may be at most 10 or at most 20. As also described elsewhere, this limited number of possible values ​​may be advantageously used when optimizing cryptographic calculation parameters.

[0212] Figure 4a shows a detailed but non-limiting embodiment of one type of subgraph. 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 for one or more input ciphertexts 410-412. The linear mapping may include one or more homomorphic additions of a ciphertext with another ciphertext and / or plaintext, and / or one or more homomorphic multiplications of a ciphertext with a scalar. In general, any number of such operations (e.g., ciphertext / plaintext addition or ciphertext / ciphertext addition and multiplication between plaintext and ciphertext) can be represented as a dot product between a ciphertext vector and a plaintext vector. Therefore, linear mapping 420 can represent the calculation of this dot product. Linear mapping 420 can take the corresponding plaintext vector corresponding to the corresponding input ciphertext 410-412 as an instantiation parameter; but interestingly, for the purpose of performing optimization, it is sufficient to represent linear mapping 420 only by the 2-norm of the plaintext vector. Therefore, the subgraph can take the 2-norm of the plaintext vector corresponding to linear mapping 420 as an instantiation parameter.

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

[0215] In many cases, the overall computation graph may be partitioned into multiple subgraphs that generate noise independent of the input. For example, the input ciphertexts 410-412 may be generated from encryption operators or programmable bootstrapping (with optional rounding). In such a case, the noise of the input may be assumed to be bounded by the maximum value of the input-independent noise used (e.g., by the noise generated from the programmable bootstrapping). When performing the computation represented by the subgraph, the corresponding operations 420-450 may generate corresponding ciphertext noise, which may be obtained by propagating the noise of the input (e.g., given by the bounds discussed, or as instantiation parameters) through the graph, as discussed, for example, with respect to FIG. 4b.

[0216] In addition to the 2-norm of the applied linear mapping 420, the subgraph 400 may be further parameterized by instantiation parameters representing noise bounds 421, 431, 441, 451 that may be required to be satisfied by the ciphertext output by the operations 420-450. Interestingly, it may be observed that the operations 420, 430, 440 typically increase the noise, whereas the output noise of the 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 bound 451 only for the noise of the input to the blind rotation 450.

[0217] The cryptographic calculation parameters of the subgraph 400 of the type described may include the decomposition base of the programmable bootstrap 450 and the key switch 430 and decomposition levels In general, these parameters may affect the noise of the output of key switching and programmable bootstrapping: if the noise increases too much, the correctness of the computation may be lost. Furthermore, the parameters may affect the computational cost of the operations, in particular the computational cost of blind rotations 450. These cryptographic computation parameters may be shared between instances of subgraphs of the type described. It is also possible to define multiple subgraph types having the same structure 400 but with different parameters, e.g., bootstrapping and key switching. This may be implemented, for example, by representing bootstrapping and / or key switching with different parameters as different FHE operations, thereby generating subgraphs of different types.

[0218] The computational cost of performing the calculations of subgraph 400 can be represented by a cost function, as also 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 calculating the linear mapping 420 can be based on the corresponding 2-norm, and / or the number of inputs, and / or the number of additions and multiplications, as also explained elsewhere. The cost of a linear mapping can also be approximated to be independent of the specific linear mapping being applied, thereby obtaining a cost function that is independent of instantiation parameters.

[0220] Optionally, the number of possible values ​​of the decomposition base and the decomposition level for key switching and / or blind rotation can be reduced by eliminating possible parameter groups with worse noise and / or complexity than other parameter groups. Specifically, key switching can add linear noise to the input noise, and blind rotation can reset the input noise, so that in both cases, the noise of the operation can be considered independent of the input noise. In addition, for both operations, the computational cost increases with the level. Due to this, (base, level) combinations that are worse than other combinations in terms of noise and complexity can be eliminated. This is illustrated by the following program:

[0221]

[0222]

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

[0224] FIG4 b shows a detailed, non-limiting embodiment of ciphertext noise when evaluating a subgraph of an encryption calculation. In this embodiment, a subgraph of the type illustrated with respect to FIG4 a is performed. Specifically, the figure illustrates that a linear mapping 420 is applied to one or more input ciphertexts 410, 411; followed by a key switch 430, a modulus switch 440, and a blind rotation and sample extraction 450, thereby producing an output ciphertext 460.

[0225] Specifically, as illustrated in the figure, the corresponding FHE operation may have a corresponding noise model that defines how the ciphertext noise of the output of the FHE operation is related to the ciphertext noise of the input. The noise model may generally take as input the cryptographic calculation parameters and instantiation parameters of the corresponding operation. In this specific embodiment, the noise model of the 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 the linear mapping 420,∑(v) may be modeled as equal to v 2The noise of the remaining operations of diagram 400 may depend only on the encryption calculation parameters.

[0226] For example, the key switching 430 and the blind rotation 450 in the corresponding instances of the subgraph 400 of the type may use the same key switching and bootstrapping key. Therefore, the noise constraints of the instance of the subgraph 400 may only depend on the instantiation parameters of the subgraph 400, the 2-norm of the linear mapping 420 and the noise bound indicating the maximum level of noise allowed to be achieved, or equivalently, the noise bound indicating the desired accuracy of the encrypted value; and the global encryption calculation parameters and / or the encryption calculation parameters of the subgraph of the type. Therefore, in this case, there are no encryption calculation parameters for a specific instance. Therefore, the corresponding instances of the illustrated subgraph type can be distinguished by their 2-norm v and the noise bound t(p).

[0227] As illustrated in the figure, the input ciphertexts of corresponding instances of subgraph 400 can be assumed to all have the same noise 419, e.g., noise 459 corresponding to the output of blind rotation and sample extraction 450 (and optional rounding). This is particularly the case if the overall computation graph is divided into multiple subgraphs representing sub-computations (which produce output ciphertexts with noise independent of the input), e.g., by splitting the computation at programmable bootstrapping (and optional rounding) operations. However, this is not strictly required, e.g., the input noise can be an instantiation parameter.

[0228] When evaluating subgraph 400, ciphertext noise is illustrated in graph 499. As illustrated by line 490, in this case, noise 429, 439, 449 may generally increase with the corresponding operator of the subgraph until reaching its peak value 449 after modulus switching 440. Then, blind rotation and sample extraction 450 may produce output ciphertext 460, which has noise 459 independent of the input (corresponding to the noise 419 of the input of the subgraph). Graph 499 also shows a noise bound 492 for noise 490, for example based on the desired computational accuracy. Because the noise increases until blind rotation and sample extraction are performed, the noise constraint of subgraph 400 may illustrate that the noise 449 of the blindly rotated input is below the noise bound 492.

[0229] FIG. 4 c shows a detailed, non-limiting embodiment of encryption calculation parameters. These parameters are illustrated here for subgraph type 400 (described subgraph type 400 is also shown in FIG. 4 a and FIG. 4 b), including linear mapping 420, key switching 430, modulus switching 440, and blind rotation and sample extraction 450. It will be understood that the same encryption calculation parameters are also applicable to instances in which different combinations and / or orders of these operations are used. FIG. illustrates which part of subgraph 400 several encryption calculation parameters are used in.

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

[0231] -k: GLWE dimension of the output of the blind rotation, e.g., an integer (with at most or at least 5, at most or at least 10 possible values, e.g., a value between 1 and 10); this may be a global encryption calculation parameter;

[0232] - N: size of the GLWE polynomial of the output of the blind rotation, e.g. a power of 2 (with at most or at least 5, or at most or at least 10 possible exponent values, e.g. in 2 8 with 2 14 The sample extraction 450 may generate an LWE ciphertext of dimension k·N. This may be a global encryption calculation parameter;

[0233] -n small : LWE dimension of the output of key switching 430, such as an integer (having at least 100 or at least 1000 possible values, such as an integer between 256 and 2048). For optimal efficiency, the number of possible values ​​considered may be limited, such as n small May be assumed to be a power of 2, although this is not necessary for the cryptographic calculations themselves. This can be a global cryptographic calculation parameter;

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

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

[0236] -β BR : a factorization base for the programmable bootstrap 450, e.g. an integer (having at most or at least 32, or at most or at least 64 possible values, e.g. an integer between 1 and 64); this may be, for example, an encryption calculation parameter specific to the subgraph type 400, and possibly shared with one or more other subgraph types so that the remaining subgraph types may use different values ​​for this parameter;

[0237] - A decomposition level of the programmable bootstrap 450, such as an integer (having up to or at least 32, or up to or at least 64 possible values, such as an integer between 1 and 64); this can, for example, be an encryption calculation parameter specific to sub-graph type 400, and possibly shared with one or more other sub-graph types so that the remaining sub-graph types can use different values ​​of this parameter.

[0238] For example, for the ranges of parameters discussed above, the number of possible values ​​for combinations of these parameters may be approximately 2 41 , highlighting the relevance of efficient optimization of these parameters.

[0239] Figure 5 A detailed but non-limiting embodiment of eliminating noise constraints is shown. Specifically, it illustrates how to determine that the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph based on instantiation parameters of the first subgraph and the second subgraph. In this case, the noise constraint of the second subgraph can be eliminated from the optimization of the encryption calculation parameters described herein.

[0240] In this embodiment, the sub-graphs are parameterized by the noise bound t(p) and by the 2-norm v of the applied linear mapping, as in, for example, FIGS. 4a , 6a and Figure 8 An example of a subgraph type as illustrated in .

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

[0242] In other words, if 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, then the noise constraint can be eliminated. Mathematically, let ν1, ν2 be the 2-norms satisfying ν1≤ν2, and t1, t2 be the noise bounds satisfying t2≤t1, then

[0243] For example, in the figure:

[0244] - Sub-graph A4 can be eliminated due to sub-graph A1 or due to sub-graph A2;

[0245] - Sub-graph A5 can be eliminated due to sub-graph A2 or due to sub-graph A3;

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

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

[0248] Since the noise constraints of several subgraphs are eliminated, it is no longer necessary to check the constraints of as many feasible sets as subgraphs, but instead it is sufficient to check the constraints of the non-eliminated subgraphs. This is particularly beneficial in embodiments where the subgraphs are defined by two instantiation parameters (e.g., a noise bound and a 2-norm, at least one of which has a finite number of values), because the number of non-eliminated subgraphs is at most the number of values ​​of the instantiation parameters. For example, the number of noise bounds, and thus the number of non-eliminated subgraphs of a type of subgraph, may be at most 5 or at most 10.

[0249] FIG6a shows a detailed, non-limiting embodiment of one type of subgraph 600. 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 bootstrap (e.g., modulus 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). Thus, the noise of the output ciphertext 660 may be independent of the noise of the input ciphertexts 611-613.

[0250] Interestingly, also with respect to the subgraph of type 600, if 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, then the noise constraint of the second subgraph can be eliminated. In addition, interestingly, the subgraph can have type 600, but can also have type 400 as illustrated with respect to FIG. 4a.

[0251] Specifically, the subgraph type 400 of FIG. 4a (eg, multi-sum, key switching, modulus switching, blind rotation, and sample extraction) is also referred to as "atomic pattern of type 1", denoted as A 1 The subgraph type 600 of this figure may be referred to as "type 2 atomic pattern" and is denoted by A 2 Therefore, the difference between types 400 and 600 is that KS 620 and the linear map ∑(v), 630 are replaced.

[0252] For example, encrypting a computational graph can be composed entirely of these two types of APs. Independently for the corresponding type, the subgraph can be eliminated, such as Figure 5 discussed.

[0253] Interestingly, however, subgraphs may be further eliminated by comparing subgraphs of two different types of APs 400, 600. More generally, by determining that the noise constraints of a first subgraph of a different type are at least as stringent, the noise constraints of a second subgraph may be eliminated from optimization of encryption computation parameters.

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

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

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

[0257] - Operators that output ciphertext with noise that depends on the input noise (eg, nonlinearity), e.g., polynomial sum 630, GLWE multiplication, etc.

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

[0259] Based on this, we can infer the following. 1 and A 2 There are two types of subgraphs, which include the same operations, but the difference is that: 1 In A, the type 2 FHE operator precedes the type 3 FHE operator; however, in A 2 In , the same FHE operator of type 2 comes after the same FHE operator of type 3. Therefore, A 2 The noise in is higher than A 1 For example, let A 2 Corresponding to the subgraph type 600 of FIG. 6a, let A 1 corresponds to subgraph type 400 of Figure 4a. Let V be the 2-norm and let t be the noise limit. Thus, A 2 The noise in (v, t) is higher than A 1 The noise in (v, t) is because the noise of the type 2 operator is amplified by the type 3 operator.

[0260] The above embodiment illustrates how one type of subgraph can be used to remove noise constraints from another type of subgraph, specifically, where the subgraph types differ in that a permutation is performed between a type 2 FHE operator and a type 3 FHE operator, in this case KS and a polynomial sum. Specifically, let v1, v2 denote the 2-norm satisfying v1≤v2, and let t1, t2 denote the noise bound satisfying t2≤t1. Thus,

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

[0262] Figure 6b shows a detailed, non-limiting embodiment of a type of subgraph 601. 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 switch 631 and a programmable bootstrap 651. The balanced cryptographic multiplication 670 may, for example, include a wrapping key switch, a tensor product and a relinearization, as known per se, and may also be presented by corresponding nodes for corresponding sub-operations. Similarly, in this embodiment, the programmable bootstrap is represented by a single node 651, but may also be represented by nodes for its corresponding sub-operations, as for example in Figure 6a. This type of subgraph may be referred to as an "atomic pattern of type 3", denoted A 3 .

[0263] Thus, subgraph type 601 may be based on subgraph type 400, additionally including multiplication 670. Similarly, a fourth subgraph type may be defined as being based on subgraph type 600 of FIG.

[0264] Interestingly, subgraphs of the first type can be eliminated based on subgraphs of the third type, and similarly, subgraphs of the second type can be eliminated based on subgraphs of the fourth type. More generally, subgraphs of a particular type can be eliminated based on subgraphs of that type with additional balanced encryption multiplications. In fact, balanced encryption multiplications add additional noise, thus creating tighter noise constraints.

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

[0266] FIG. 7 a shows a detailed, non-limiting embodiment of identifying a corresponding key switching key and / or bootstrapping key to be used for a corresponding sub-map.

[0267] As also discussed elsewhere, key switching keys and bootstrapping keys can be specific to a specific set of cryptographic computation parameters, such as hierarchical key parameters and decomposition key parameters. As discussed with respect to FIG. 4 a, these parameters 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. This has the advantage that it generates less key material, but on the other hand, it can negatively affect computational complexity because in this case, noisier and faster key switching or bootstrapping cannot be used in the subgraph (even if this is possible).

[0268] There are several ways to support multiple key switching keys and / or bootstrapping keys in the same encryption calculation. As also discussed with respect to FIG. 4a, one way is to define subgraphs of corresponding types having the same structure, but using corresponding key switching keys and / or bootstrapping keys, where specific subgraphs are preconfigured to have specific types. The disadvantage of this approach is that it is not possible to automatically optimize which key is used in which subgraph.

[0269] Another approach is to constrain the cryptographic parameters (e.g., level / base) of key switching and / or bootstrapping to be cryptographic computation parameters for a specific instance of a subgraph, distinct from cryptographic computation parameters for subgraphs 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 creates a large number of additional parameters, making the optimization problem more complex.

[0270] Interestingly, the inventors have envisioned a better way to automatically determine which key switching keys and / or bootstrap keys to use in which subgraph. That is, multiple sets of parameters (e.g., levels and / or bases) corresponding to multiple sets of key switching keys and / or bootstrap keys can be defined as part of, for example, global encryption calculation parameters, or as parameters of a given type of subgraph that can be included. The number of groups to be used can be preconfigured. For a given subgraph 770-772, the encryption calculation parameters δ, 780-782 of the subgraph can determine which set of parameters is used for the subgraph.

[0271] This is illustrated below for key switching. Assume that the number of key switching keys to be used is X, and the number of subgraphs using them is Y. The optimization of the key switching keys to be used may correspond to determining Produces a size of X Y This is better than having multiple sets of parameters for each subgraph, but is still quite large.

[0272] Interestingly, the inventors realized that the search space for key switching keys (and similarly, bootstrap keys) 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, if the noise constraint of the first subgraph is at least as strict as the noise constraint of the second subgraph.

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

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

[0275] In this embodiment, it is noted that (δ0, δ1, δ2) = (0, 1, 0) would not be the optimal solution. This can be explained as follows. As discussed with respect to FIG. 4a and FIG. 6a, in this case, 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. In addition, the noise constraint of A(v0, t) can be eliminated from the optimization because 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 (δ0,δ1,δ2)=(1,1,0):

[0279] (δ0,δ1,δ2) can be equal to (0,1,0) or (1,1,0). In any case, the result is are the same as:

[0280] · As and The only difference between the two is that the first one uses a slower key switch. Since the feasible sets are the same, and In terms of computational complexity, Worse, so it can be inferred that (δ0,δ1,δ2)=(0,1,0) will not be the optimal solution.

[0281] The above reasoning can be extended to graphs containing an arbitrary number of subgraphs with the same noise bound. In this case, identifying the corresponding key switching key may correspond to the number of subgraphs that determine the maximum noise constraint (the subgraphs use the first key switching key), while the remaining subgraphs use the second key switching key. This greatly reduces the parameter space. Mathematically, let satisfies v0<v1<v2<…<v Y And Y = |I|, and assume that two keys are used to switch keys. So, the optimal δ = (δ0,…,δ Y ) has the form (1, ..., 1, 0, ..., 0). Therefore, the optimization does not need to find every possible {δ i} i∈I , for example, determine γ∈{1,…,Y} that satisfies (1,…,1,0,…,0) and δ i-1 =1 and δ i = 0 is sufficient. This means that the substitution must be of size 2 Y It is sufficient to search in a search space of size Y.

[0282] The above reasoning also applies to any number of key switching keys. Moreover, in this case, it is sufficient to determine several subgraphs (sorted from the most stringent noise constraint to the least stringent noise constraint) that use the corresponding key switching key. Mathematically, let satisfies v0<v1<v2<…<v Y And Y = |I|, and assume that there are X keys for switching keys. Then, the optimal δ = (δ0, ..., δ Y) has the form (Y, ..., Y, Y-1, ..., Y-1, ..., 1, ..., 1, 0, ..., 0). Therefore, there is no need to find every possible {δ i} i∈I , for example, determine whether j ∈[[1, Y]], γ j =i's {γ j} j∈[[1，X-1]] At the same time 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 in the search space of size It is sufficient to search in the space.

[0283] The above method can be applied to corresponding groups of subgraphs by defining corresponding key identifier vectors (δ0, ..., δ Y ) to share the corresponding noise bounds, as described above.

[0284] Furthermore, the above method may also be applied to identify corresponding bootstrapping keys to be used in corresponding subgraphs, wherein the bootstrapping keys are sorted according to the amount of noise added.

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

[0286] Fig. 7b shows a detailed and non-limiting embodiment of determining the number of programmable bootstraps to be performed during application linear mapping. The embodiment in this figure is based on a subgraph of the type of Fig. 4a, but the technology is equally applicable to other types of subgraphs including application linear mapping, such as the subgraph of the type shown in Fig. 6a.

[0287] Shown in the figure is a subgraph 700 of the type illustrated in FIG. 4a , comprising a linear mapping 720 applied to one or more input ciphertexts 710 , followed by a key switch 730 and programmable bootstrapping 740 (in this case shown as a single node, but typically implemented as modulus switching, blind rotation, and sample extraction), producing an output ciphertext 760 .

[0288] Further shown 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, which in this case is divided into two parts 721, 722. The programmable bootstrap 750 inserted in this embodiment applies an identification function, although it could also, for example, incorporate scalar multiplication and / or addition of public values. As in subgraph 700, key switching and programmable bootstrap 730 (illustrated here as a single node for simplicity) are applied to the output of the linear mapping 721-722 to obtain the output ciphertext.

[0289] In this case, by inserting PBS 750 in the subgraph during the application of the linear mapping, the computational complexity is increased. On the other hand, the ciphertext noise when evaluating the subgraph is reduced by PBS 750, in this case, the 2-norm of the polynomial sums 721, 722 is reduced, allowing for noisier but faster parameters.

[0290] Interestingly, the inventors have realized that this tradeoff can be optimized so that for a given type of corresponding subgraph, a corresponding number of programmable bootstraps to be performed during the subgraph (e.g., as in this embodiment, during application of the corresponding linear mapping) is automatically determined. Thus, subgraph types with a variable number of programmable bootstraps d can be defined. For example, during application of the corresponding linear mapping, the computation graph input to the optimized cryptographic computation may not include programmable bootstraps, wherein the optimization inserts those programmable bootstraps when 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 are performed during the linear mapping, the linear mapping can be automatically split into a number of 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 effective in allowing 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 with respect to noise and complexity by effectively ignoring the cost of the polynomial sum (specifically, the number of inputs to which the corresponding polynomial sum is applied). Specifically, in order to split the polynomial sum into two polynomial 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 another optional 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 the polynomial sum is as follows. If the weights are close to uniform distribution (e.g., w i ∈[-2 p , 2 p ]), this technique is particularly effective. According to this technique, the corresponding weights can be decomposed into multiple numbers according to the cardinality, and the numbers can be applied to the input and combined. For example, the cardinality decomposition can be as in Algorithm 1 of I. Chillotti et al. "Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 seconds", proceedings ASIACRYPT 2016 (incorporated herein by reference), or using a signed decomposition as disclosed in M. Joye, "Balanced non-adjacent forms", proceedings ASIACRYPT 2021 (incorporated herein by reference). Specifically, the level of the cardinality 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 corresponding Λ i Can be the base The corresponding power of .

[0301] Interestingly, in determining the number of programmable bootstraps d performed for subgraph i i , if the noise constraint of the first sub-graph i is at least as strict as the noise constraint of the second sub-graph j, the number of programmable bootstraps d of the first sub-graph can be set to iconstrained to be greater than or equal to the number of programmable bootstraps d of the second subgraph j , it can greatly reduce d i parameter space.

[0302] That is, if inserting a PBS in a subgraph does not change the parameters, then the insertion is always suboptimal. More precisely, let Satisfies v0<v1<.... Let and There are two possible solutions. and .if (e.g., each coordinate is either inferior or equal and ), it can be noted that That is, similar to the discussion of Figure 7a, the noisy feasible sets of the two subgraphs are the same, and the cost of one subgraph is higher than the other because it contains more programmable bootstraps.

[0303] Figure 8 A detailed but non-limiting embodiment of programmable bootstrapping with noise rounding is shown. This embodiment can be combined with any sub-graph type including programmable bootstrapping (eg, the sub-graph types of FIG. 4 a , FIG. 6 a , FIG. 6 b , or FIG. 7 b ).

[0304] Specifically, this embodiment shows a programmable bootstrapping including modulus switching 840 applied to a programmable bootstrap input ciphertext 839, producing a LWE-encrypted modulus switching output 849, followed by blind rotation 851 using a bootstrap key 854 and a lookup table 855, producing a GLWE-encrypted monomial 852 (RLWE-encrypted in this embodiment), to which sample extraction 853 is applied, thereby obtaining a programmable bootstrap LWE-encrypted output ciphertext 869. These operations may be performed as known per se.

[0305] Interestingly, as shown in this figure, a noise rounding operation 870 may be applied to the sample extraction output 869, thereby obtaining a rounded output ciphertext 879. Specifically, the operation may set a given number of the least significant bits of the ciphertext value to zero, or in other words, round the ciphertext value to a given power of 2. Note that the output ciphertext 869 typically has noise that is independent of the input, and thus the rounded output ciphertext 879 also has noise that is independent of the input.

[0306] As the inventors appreciate, by applying a rounding operation to the result of the programmable bootstrap, the rounded result 879 of the programmable bootstrap can be made independent of the specific Fast Fourier Transform (FFT) implementation used to implement the programmable bootstrap, as long as the FFT implementation has a given accuracy. Therefore, the PBS can effectively become deterministic. This can lead to or at least help the full encryption calculation become deterministic.

[0307] That is, the inventors realize that the sample-extracted output 869 before rounding 870 can differ between multiple FFT implementations. This was in fact observed in experiments comparing an implementation of PBS on a CPU with FFTW with an implementation on a GPU with a conventional FFT. Although both outputs are correct per se, they can differ in the exact output noise produced. For many coefficients of the output of the PBS, it was observed that the most significant bits containing the message were identical, while the least significant bits (containing the noise) contained some differences.

[0308] The number of bits to which rounding is applied, in other words, the position where rounding is performed, can be preconfigured, but this position can also be determined as an encryption calculation parameter, such as a global encryption calculation parameter or a parameter specific to a subgraph type. That is, rounding can add a certain amount of noise, wherein the larger the rounding applied in the MSB, the more noise is added to the plaintext. For a given implementation of the FFT, the optimization can use the error limits of the ciphertext coefficients introduced by the implementation. Therefore, the encryption calculation parameters can be optimized taking into account the noise model, the cost model and also the FFT error model.

[0309] In order to take into account the errors of the FFT depending on the implementation, a constraint can be included in the optimization of the encryption calculation parameters. This constraint can be obtained by adding a feasible set (In the optimization described above, the feasible set will be added The condition can be expressed as:

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

[0311] In general, this method may be based on an error model for the ciphertext coefficients in the output of the FHE operator. For example, an FHE operator that does not use FFT may take as input an error-free ciphertext and may output an error-free ciphertext.

[0312] Programmable bootstrapping (or more generally, FHE operators using FFTs) may reset the error to a minimum level (e.g., may produce ciphertext that is not error-free), or may output a maximum amount of error (e.g., re-randomization of the ciphertext) depending on the parameters of the operator and the input error. Depending on the encryption calculation parameters and the input error, rounding may maintain the same amount of error, or may eliminate the error.

[0313] The FFT error may be constrained based on other cryptographic and / or encryption calculation parameters, for example by requiring

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

[0315] It is also noted that noise rounding 870 can be applied to make the cryptographic calculation more deterministic, regardless of whether the cryptographic calculation parameters are determined by optimization as described herein. Specifically, the inventors contemplate a cryptographic method for performing cryptographic calculations, and a corresponding cryptographic calculation device, in which a noise rounding operation 870 is applied to the output of a FHE operation containing implementation-dependent noise (such as FFT-related noise of programmable bootstrap 840-853). The cryptographic calculations performed by the method and device may use cryptographic calculation parameters as described herein, but this is not required.

[0316] Specifically, a cryptographic method for performing cryptographic calculations including noise rounding can be performed by a mining machine device of a distributed ledger (e.g., blockchain). Specifically, a plurality of such mining machine devices can perform cryptographic calculations. Due to the use of rounding 870, it is achievable that the corresponding mining machine device calculates the exact same ciphertext as the output of the cryptographic calculation, which means that not only the plaintext is the same, but also the ciphertext encrypted to the plaintext is the same. When used in combination with the optimization described herein, the corresponding mining machine device can still use the corresponding cryptographic calculation parameters, which are optimal for the noise (e.g., FFT error) related to the implementation of their corresponding system configuration. Specifically, by using rounding 780, the mining machine can reach a consensus on the output of the cryptographic calculation without the need for decryption.

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

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

[0319] - accessing (910) data representing a computation graph of said encrypted computation;

[0320] - obtaining (920) partitioning the computation graph into a plurality of subgraphs, wherein a subgraph is defined by a type from a set of one or more types, and a subgraph is defined by zero or more instantiation parameters of the type;

[0321] - defining (930) a corresponding set of encryption calculation parameters for a corresponding type;

[0322] - performing (940) said optimization of encryption calculation parameters, wherein:

[0323] - The encryption calculation parameters are optimized so that

[0324] minimizing the computational cost of performing the cryptographic calculations; and

[0325] -The encryption calculation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption calculation, wherein the noise constraints are based on corresponding noise constraints of corresponding subgraphs, wherein the noise constraints of a given type of subgraph are defined by a noise constraint function of the given type, and the noise constraint function of the given type takes at least the encryption calculation parameters of the given type and the instantiation parameters of the subgraph as input.

[0326] 2. The method (900) according to clause 1, comprising:

[0327] - based on instantiation parameters of the first sub-graph and the second sub-graph, determining that the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph; and

[0328] - removing said noise constraint of said second subgraph from said optimization.

[0329] 3. A method (900) according to clause 2, wherein the first sub-graph and the second sub-graph are parameterized by noise bounds and by the 2-norm of the applied linear mapping, and wherein the noise bound of the first sub-graph is at most the noise bound of the second sub-graph, and the 2-norm of the first sub-graph is at least the 2-norm of the second sub-graph.

[0330] 4. A 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 given type of subgraph is defined by the cost function of the given type, and the cost function of the given type takes at least the encryption computation parameters of the given type as input and is independent of the instantiation parameters.

[0331] 5. A method (900) according to any preceding clause, wherein the subgraph represents a sub-computation that produces an output ciphertext with noise independent of the input.

[0332] 6. A method (900) according to any of the preceding clauses, wherein the encryption calculation parameters include one or more of the following: a factorization base for programmable bootstrapping, a factorization level for programmable bootstrapping, a factorization base for key switching, and a factorization level for key switching.

[0333] 7. A method (900) according to any preceding clause, wherein the subgraph comprises programmable bootstrapping to produce output ciphertext and noise rounding of the output ciphertext.

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

[0335] 9. A method (900) according to any of the preceding clauses, wherein the encryption calculation parameter identifies a corresponding key switching key and / or bootstrap key to be used for a corresponding sub-map, wherein if the noise constraint of a first sub-map is at least as strict as the noise constraint of a second sub-map, then the key switching key and / or bootstrap key of the first sub-map is constrained to add at most as much noise as the key switching key and / or bootstrap key of the second sub-map.

[0336] 10. A method (900) according to any preceding clause, wherein the encryption calculation parameter indicates a corresponding number of programmable bootstrappings to be performed during application of the corresponding linear mapping for a corresponding subgraph to which the corresponding linear mapping is applied.

[0337] 11. The method (900) of clause 10, further comprising splitting the linear mapping into a number of corresponding linear mappings corresponding to the number of programmable bootstraps by minimizing a maximum 2-norm of the corresponding linear mappings.

[0338] 12. A method (900) according to clause 10 or 11, wherein if the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph, the number of programmable boots of the first sub-graph is constrained to be greater than or equal to the number of programmable boots of the second sub-graph.

[0339] 13. The method (900) according to any preceding clause, further comprising:

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

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

[0342] -Performing cryptographic calculations according to the determined cryptographic calculation parameters.

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

[0344] - a memory (130), the memory (130) being used to store data representing a computation graph of the encryption computation;

[0345] - a processor subsystem (140), the processor subsystem (140) being configured to:

[0346] - obtaining a partition of the computation graph into a plurality of 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] -define the corresponding group of encryption calculation parameters for the corresponding type;

[0348] -Perform optimization of the encryption calculation parameters, wherein: the encryption calculation parameters are optimized so as to minimize the computational cost of performing the encryption calculation according to the encryption calculation parameters; and the encryption calculation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption calculation, wherein the noise constraints are based on corresponding noise constraints of corresponding subgraphs, wherein the noise constraints of a given type of subgraph are defined by a noise constraint function of the given type, and the noise constraint function takes at least the encryption calculation 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 which, when executed by a processor system, cause the processor system to execute a method according to any one of clauses 1-13 and / or cryptographic calculation parameters determined according to a method according to any one of clauses 1-13 and / or instructions for a cryptographic calculation engine.

[0350] FIG. 9 a schematically illustrates an example of one implementation of a computer-implemented method 900 of determining cryptographic computation parameters for performing cryptographic computations on noisy ciphertext.

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

[0352] Method 900 may include obtaining 920 partitioning the computation graph into a plurality of subgraphs. A subgraph may be 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.

[0353] The method 900 may include defining 930 a corresponding set of cryptographic calculation parameters for a corresponding type.

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

[0355] FIG. 9 b schematically illustrates an example of one implementation of a cryptographic method 950 for performing cryptographic calculations.

[0356] The method 950 may include obtaining 960 cryptographic computation parameters as described herein, and performing 970 a cryptographic computation in accordance with 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 970 the cryptographic computation, or the cryptographic computation parameters may be obtained 960 separately from a representation of the cryptographic computation to be performed.

[0357] As an alternative or in addition to using cryptographic calculation parameters as described herein, method 950 may apply a noise rounding operation to the ciphertext with implementation-dependent noise (e.g., the output of a programmable bootstrap), such as with respect to Figure 8 discussed.

[0358] Many different ways of performing the methods 900, 950 are possible, as will be apparent to those skilled in the art. For example, the order of 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. In addition, other method steps may be inserted between the steps. The inserted steps may represent improvements to the methods such as described herein, or may be unrelated to the methods. For example, some steps may be performed at least partially in parallel. In addition, a given step may not be completely completed when the next step begins. The methods 900, 950 may also be combined, for example, the method 950 for performing cryptographic calculations may be performed according to cryptographic calculation parameters previously determined in accordance with the method 900.

[0359] The embodiments of the method can be performed using software, which includes instructions for causing a processor system to perform 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 in a suitable storage medium, such as a hard disk, a floppy disk, a memory, an optical disk, etc. The software may be sent as a signal via a wired or wireless transmission, or using a data network (e.g., the Internet). The software can be used for downloading and / or can be used remotely on a server. The embodiments of the method can be performed using a bit stream, which is arranged to configure a programmable logic (e.g., a field programmable gate array (FPGA)) to perform the method.

[0360] It will be understood that the currently disclosed subject matter also extends to a computer program (specifically, a computer program located on or in a carrier) that is suitable for putting the currently disclosed subject matter into practice. The program can take the form of source code, target code, code intermediate source, and object code (such as, partially compiled form), or take the form of any other implementation suitable for the implementation of the embodiment of the method. An embodiment related to a computer program product includes computer executable instructions corresponding to each processing step in at least one of the stated methods. These instructions can be subdivided into subroutines, and / or stored in one or more files that can be statically or dynamically linked. Another embodiment related to a computer program product includes computer executable instructions corresponding to each device, unit, and / or part of at least one of the stated multiple systems and / or products.

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

[0362] The processor circuit may be implemented in a distributed form (e.g., as multiple sub-processor circuits). The memory may be allocated across multiple distributed sub-memories. Some or all of the memory may be electronic memory, magnetic memory, etc. For example, the memory may have a volatile portion and a non-volatile portion. Portions of the memory may be read-only.

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

[0364] Alternatively or additionally, data 1020 may represent cryptographic computation parameters and / or instructions for a cryptographic computation engine determined according to one embodiment.

[0365] Data 1020 may be implemented on computer readable medium 1000 as physical marks or by magnetization of computer readable medium 1000. However, any other suitable embodiments are also contemplated. In addition, it will be understood that although computer readable medium 1000 is shown here as an optical disk, computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable.

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

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

[0368] Although device 1110 is shown as including one of the various described components, multiple components may be repeated in multiple embodiments. For example, processor 1120 may include multiple microprocessors configured to independently execute multiple methods described herein, or configured to execute steps or subroutines of the methods described herein, so that multiple processors collaborate to implement the functions described herein. In addition, 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 illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments.

[0370] In the claims, any reference numerals placed in brackets shall not be interpreted as limiting the claims. The use of the verb "comprise" and its variants does not exclude the presence of elements or steps other than those stated in the claims. The article "one" or "an" in front of an element does not exclude the presence of multiple such elements. When an expression such as "at least one" is placed before a list of elements, it means selecting 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 currently disclosed can be implemented by hardware including several different elements, as well as by a suitably programmed computer. In a device claim that lists several components, several of these components can be implemented by the same hardware item. The mere fact that certain measures are recorded in mutually different dependent claims does not indicate that the combination of these measures cannot be used to advantage.

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

Claims

1. A computer-implemented method (900) for determining cryptographic calculation parameters for performing cryptographic calculations on noisy ciphertext, comprising: - accessing (910) data representing a computation graph of said encrypted computation; - obtaining (920) partitioning the computation graph into a plurality of subgraphs, wherein a subgraph represents a subcomputation that produces an output ciphertext having 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; - defining (930) a corresponding set of encryption calculation parameters for a corresponding type; - performing (940) said optimization of encryption calculation parameters, wherein: - the cryptographic calculation parameters are optimized so as to minimize the computational cost of performing the cryptographic calculation according to the cryptographic calculation parameters; and - the encryption calculation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption calculation, wherein the noise constraints are based on corresponding noise constraints of corresponding subgraphs, wherein the noise constraints of a given type of subgraph are defined by a noise constraint function of the given type, the noise constraint function of the given type taking at least the encryption calculation parameters of the given type and the instantiation parameters of the subgraph as input, - based on instantiation parameters of the first sub-graph and the second sub-graph, determining that the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph; and - removing said noise constraint of said second subgraph from said optimization.

2. A method (900) according to claim 1, wherein the first sub-image and the second sub-image are parameterized by noise bounds and by the 2-norm of the applied linear mapping, and wherein the noise bound of the first sub-image is at most the noise bound of the second sub-image, and the 2-norm of the first sub-image is at least the 2-norm of the second sub-image.

3. A method (900) according to any preceding claim, 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 given type of subgraph is defined by the cost function of the given type, and the cost function of the given type takes at least the encryption computation parameters of the given type as input and is independent of the instantiation parameters.

4. A method (900) according to any preceding claim, wherein the encryption calculation parameters include one or more of the following: a factorization base for programmable bootstrapping, a factorization level for programmable bootstrapping, a factorization base for key switching, and a factorization level for key switching.

5. The method (900) of any preceding claim, wherein a subgraph of the plurality of subgraphs comprises programmable bootstrapping to produce an output ciphertext and noise rounding of the output ciphertext.

6. The method (900) according to any preceding claim, wherein the optimization of the cryptographic calculation parameters is performed by a branch and bound method.

7. A method (900) according to any preceding claim, wherein the encryption calculation parameter identifies a corresponding key switching key and / or bootstrap key to be used for a corresponding sub-graph, wherein if the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph, then the key switching key and / or bootstrap key of the first sub-graph is constrained to add at most as much noise as the key switching key and / or bootstrap key of the second sub-graph.

8. A method (900) according to any preceding claim, wherein the encryption calculation parameter indicates a corresponding number of programmable bootstrappings to be performed during application of the corresponding linear mapping for a corresponding subgraph to which the corresponding linear mapping is applied.

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

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

11. The method (900) according to any preceding claim, further comprising: -Convert the unencrypted computation graph into an encrypted computation graph; and / or - Compile the computation graph of the encrypted computation into a set of instructions for the encrypted computation engine; and / or -Performing cryptographic calculations according to the determined cryptographic calculation parameters.

12. A configuration device (110) for determining cryptographic calculation parameters for performing cryptographic calculations on noisy ciphertext, comprising: - a memory (130), the memory (130) being used to store data representing a computation graph of the encryption computation; - a processor subsystem (140), the processor subsystem (140) being configured to: - obtaining a partition of the computation graph into a plurality of subgraphs, wherein the subgraphs represent sub-computations that produce output ciphertexts having noise independent of the input, and 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; -define the corresponding group of encryption calculation parameters for the corresponding type; - performing optimization of the encryption calculation parameters, wherein: the encryption calculation parameters are optimized so as to minimize the computational cost of performing the encryption calculation according to the encryption calculation parameters; and the encryption calculation parameters are constrained to satisfy noise constraints on ciphertext noise when performing the encryption calculation, wherein the noise constraints are based on corresponding noise constraints of corresponding subgraphs, wherein the noise constraints of a given type of subgraph are defined by a noise constraint function of the given type, and the noise constraint function takes at least the encryption calculation parameters of the given type and the instantiation parameters of the subgraph as input, - based on instantiation parameters of the first sub-graph and the second sub-graph, determining that the noise constraint of the first sub-graph is at least as strict as the noise constraint of the second sub-graph; and - removing said noise constraint of said second subgraph from said 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 execute a method according to any one of claims 1-11 and / or cryptographic calculation parameters determined by a method according to any one of claims 1-11 and / or instructions for an cryptographic calculation engine.

Images