Scale management method of homomorphic encryption compiler based on integer linear programming

Abstract

The invention discloses an integer linear programming-based scale management method for a homomorphic encryption compiler, and relates to the field of cloud computing. According to the method, the scale management problem of the RNS-CKKS is formalized into an integer linear programming problem, so that the problem can be solved by using an existing mathematical method. Through the scale management method provided by the invention, a programmer can neglect the scale management requirement during programming, and the programmer can perform management automatically without intervention; compared with an existing scale management method in a homomorphic encryption compiler, the method provided by the invention can generate a program with better performance in a shorter time, and is beneficial to popularization of use of homomorphic encryption.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing, and in particular to a scale management method of a homomorphic encryption compiler based on integer linear programming. Background Art

[0002] The cloud computing business has experienced significant growth in the past few years. More and more enterprises and organizations choose to migrate their data and services to the cloud, driving the demand for secure computing in the cloud. Fully Homomorphic Encryption (FHE) can perform calculations on encrypted data without decryption, reducing the risk of data exposure in cloud computing. RNS-CKKS is a widely used FHE scheme that has demonstrated outstanding performance in fields such as machine learning, statistical analysis, and data mining. Due to its excellent performance, RNS-CKKS is widely used in various FHE libraries and compilers.

[0003] Despite the many benefits of FHE, writing a correct and efficient FHE application remains complex and challenging. Existing FHE schemes require sufficient cryptographic knowledge to obtain the expected results, such as the need to manage the scale of ciphertext during programming. RNS-CKKS encodes real numbers as integers, and the scale is used to represent the position of its decimal point. Multiplication increases the scale of the ciphertext, and scale overflow will cause the calculation result to be unrecoverable. In addition, the ciphertext has a property called level, which affects the latency of performing arithmetic operations on the ciphertext. In order to develop correct and efficient applications, programmers should manually insert scale management operations such as rescale and modswitch to determine the scale and level of the ciphertext. This unique programming paradigm has created a great obstacle for non-expert programmers and affected the promotion of FHE applications.

[0004] In order to reduce the programming burden, EVA, Hecate, and ELASM proposed automatic scale management methods. However, these methods are based on heuristic or iterative methods, resulting in suboptimal performance or requiring time-consuming iterations. EVA conservatively inserts scale management operations to ensure the functional correctness of the program, but ignores the impact of these operations on program performance. In addition, it adopts separate scale and level analysis without realizing the benefits of solving these two problems in a collaborative way. Hecate and ELASM achieve higher performance by exploring the optimization space based on iteration methods. Compared with Hecate, ELASM finds a better error and delay trade-off through fine-grained noise-aware waterline. However, the quality of the solution obtained by the iterative method is significantly affected by factors such as algorithm parameters, initialization, and randomness, and the iteration parameters need to be manually adjusted according to the problem scale. Multiple experiments are required to find the optimal program parameters, which is still not convenient to use.

[0005] Therefore, those skilled in the art are committed to developing a scale management method for homomorphic encryption compilers based on integer linear programming. The scale management problem of RNS-CKKS is formalized as an integer linear programming problem, so that it can be solved using existing mathematical methods. Summary of the invention

[0006] In view of the above-mentioned defects of the prior art, the technical problem to be solved by the present invention is that when solving the scale management problem, the program generated by the existing homomorphic encryption compiler has poor performance or requires a lot of solution time.

[0007] To achieve the above object, the present invention provides a scale management method of a homomorphic encryption compiler based on integer linear programming, comprising the following steps:

[0008] Step 1: Convert the input program into high-level IR and perform program-level optimization;

[0009] Step 2: Convert high-level IR to FHE::fhe dialect;

[0010] Step 3: The FHE::fhe dialect is reduced to the dialect of the specific scheme, the scale management problem is modeled as an integer linear programming problem, and the low-level IR of different FHE schemes is generated;

[0011] Step 4: The low-level IR generates target code for the hardware backend and performs hardware optimization.

[0012] Furthermore, the goal of the scale management problem is to determine the scale and level of all arithmetic nodes and insert scale management operations to minimize the delay of the program while satisfying constraints.

[0013] Furthermore, the constraints include node level allocation constraints, node scale upper limit constraints, node scale lower limit constraints, arithmetic operation constraints, scale management operation constraints, input and output constraints.

[0014] Furthermore, the integer linear programming problem is solved using Gurobi.

[0015] Furthermore, in step 1, loop unrolling optimization is adopted.

[0016] Furthermore, in step 1, the compilation optimization method includes dead code elimination, constant folding, and common sub-expression elimination.

[0017] Furthermore, in step 2, the FHE::fhe dialect defines the operations and semantics of the homomorphic encryption program.

[0018] Furthermore, in step 2, the optimization method includes vectorization and circuit optimization.

[0019] Furthermore, in step 3, the dialects of the specific scheme include FHE::bfv, FHE::bgv, and FHE::ckks.

[0020] Furthermore, in step 4, the hardware backend includes a CPU, a GPU, and an accelerator.

[0021] Existing homomorphic encryption compilers use heuristic methods or iteration-based methods to solve scale management problems, lacking understanding of the optimization space, resulting in poor performance of the generated program or requiring a lot of time to solve. The present invention formalizes the scale management problem of RNS-CKKS as an integer linear programming problem, so that it can be solved using existing mathematical methods. Compared with heuristic methods and iteration-based methods, the integer linear programming-based method has a rigorous mathematical proof for the optimality of the solution, thereby improving the quality of the solution; at the same time, compared with the disordered iterative method, the integer linear programming-based method can obtain the optimal solution faster.

[0022] Compared with the prior art, the present invention has the following obvious substantial features and significant advantages:

[0023] 1. The present invention can achieve higher performance than existing methods (heuristic methods and iteration-based methods).

[0024] 2. Compared with the existing iteration-based methods, the present invention has a faster solution time.

[0025] 3. The present invention helps to generate higher performance programs in a shorter time, thereby promoting the promotion and implementation of homomorphic encryption applications.

[0026] 4. Through the scale management method proposed in the present invention, programmers can ignore the need for scale management when programming, and the compiler will automatically manage it without the need for programmer intervention; compared with the scale management method in the existing homomorphic encryption compiler, the method proposed in the present invention can generate programs with better performance in a shorter time, which is helpful to promote the use of homomorphic encryption.

[0027] The concept, specific structure and technical effects of the present invention will be further described below in conjunction with the accompanying drawings to fully understand the purpose, characteristics and effects of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a homomorphic encryption compilation process of a preferred embodiment of the present invention;

[0029] Figure 2 This is an example of the meaning of variables in a preferred embodiment of the present invention;

[0030] Figure 3It is a performance comparison of different scale management methods of a preferred embodiment of the present invention;

[0031] Figure 4 It is a performance comparison of different scale management methods under different waterlines under a PR task of a preferred embodiment of the present invention;

[0032] Figure 5 This is a performance comparison of different scale management methods under different waterlines for an MR task in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0033] The following describes several preferred embodiments of the present invention with reference to the drawings in the specification, so that the technical content is clearer and easier to understand. The present invention can be embodied in many different forms of embodiments, and the protection scope of the present invention is not limited to the embodiments mentioned in the text.

[0034] In the drawings, components with the same structure are indicated by the same numerical reference numerals, and components with similar structures or functions are indicated by similar numerical reference numerals. The size and thickness of each component shown in the drawings are arbitrarily shown, and the present invention does not limit the size and thickness of each component. In order to make the illustration clearer, the thickness of the components is appropriately exaggerated in some places in the drawings.

[0035] The present invention belongs to a compilation optimization method in a homomorphic encryption compiler. A homomorphic compiler is implemented as follows: Figure 1 As shown. The compiler is implemented based on the MLIR framework and can compile programs written by programmers into homomorphic encryption programs. The MLIR compiler consists of multiple levels of dialects and optimization methods. In view of the main application scenarios of RNS-CKKS, Python is selected as the current programming language. In addition to arithmetic operations, the compiler also supports branches and loops with plaintext as conditions. Ciphertext cannot be used as conditions for branches and loops, otherwise the ciphertext data will leak from the control flow. The entire compilation process is shown below:

[0036] Step 1: The input program is converted into a high-level IR composed of various built-in dialects and program-level optimization is performed. In the present invention, since FHE schemes such as RNS-CKKS do not support loops, loop unrolling optimization is required. After loop unrolling, compilation optimization methods such as dead code elimination, constant folding, and common subexpression elimination are also required.

[0037] Step 2: Convert high-level IR to FHE::fhe dialect. FHE::fhe dialect defines the operations and semantics of homomorphic encryption programs while abstracting lower-level scheme details such as data types and noise management. This involves two optimization methods: vectorization and circuit optimization. The former is an important way to improve throughput, and the latter is mainly used to reduce the multiplication depth to reduce latency and control noise growth.

[0038] Step 3: The FHE::fhe dialect is reduced to the dialect of a specific scheme, including FHE::bfv, FHE::bgv and FHE::ckks, to generate low-level IRs for different FHE schemes. At this point, the scale management problem needs to be solved to generate the correct program. The core of the present invention is to solve this problem, which will be described in detail later.

[0039] Step 4: The low-level IR will generate target code for different hardware backends, including but not limited to CPU, GPU, and accelerators, and perform hardware-related optimizations. In this embodiment, the backend is SEAL, a general-purpose CPU library for FHE.

[0040] The present invention proposes an effective method for solving the scale management problem (for step three). The method can generate a correct and efficient homomorphic encryption program by modeling the scale management problem as an integer linear programming problem. The present invention is introduced below from the perspective of constant and variable definitions, constraints, objective functions, and experimental results.

[0041] Constant definition: Before scale management, the source program can be regarded as a directed acyclic graph G(V,E). V represents all nodes in the original program, excluding the additional inserted scale management operations, and E represents the dependency edges between nodes. op A set of nodes used to represent a specific operation op, that is, V = V add ∪V mul ∪V rotate ∪V input ∪V output In addition, (e1, e2, dst) is used to more accurately represent a two-input arithmetic node, where e1 and e2 represent two input edges, dst represents the arithmetic node itself, and the rotate node is represented by (e1, dst). J represents a set from 1 to L, which is used to represent all feasible levels, and R represents the rescale factor S f The logarithm of R =S f . D op,j Indicates the latency of the op operation at level j.

[0042] Variable definitions: The variable symbols and descriptions involved in the present invention are shown in the following table:

[0043] symbol type illustrate <![CDATA[s i ]]> Integer The size of node i (logarithmic form) <![CDATA[l i,j ]]> Binary Whether node i is at level j <![CDATA[is k ]]> Integer The size of the output virtual node of edge k (in logarithmic form) <![CDATA[il k,j ]]> Binary Whether the output virtual node of edge k is at level j <![CDATA[r k,j,n ]]> Binary Is there n rescale operations on edge k and the final level is j? <![CDATA[m k,j,n ]]> Binary Is there n modswitch operations on edge k and the final level is j? <![CDATA[u k ]]> Integer Upscale factor on edge k

[0044] The goal of the scale management problem is to determine the scale and level of all arithmetic nodes and insert appropriate scale management operations to minimize the delay of the program while satisfying certain constraints. The decision variables of the problem are the scale and level of each node (including input and output nodes), denoted by si and l i,j To facilitate the representation of the latency of the operation, the rank is expressed in binary form. On the other hand, the scale is expressed in logarithmic form, thus converting multiplication into addition. Figure 2 (a) shows the size and level of each node in a program. The two input ciphertexts have 2 20 and 2 30 The scale of the final operation is 2. 20 and the level is 1. Note that this diagram requires subsequent insertion of scale management operations to achieve correct functionality.

[0045] In order to facilitate subsequent representation, some auxiliary variables are introduced. Assume that each edge has a virtual node ( Figure 2 (b)), there is no operation (including arithmetic and scale management operations) between this virtual node and the destination node of this edge. This virtual node also has scale and level attributes, which are represented by is k andil k,j It is used to represent the input attributes of the destination node. For example, Figure 2 The two inputs of the mulcc node in (b) have 2 20 and 2 30 of scale, and the level is 2.

[0046] After determining the attributes of the nodes, for each edge, a scale management operation needs to be inserted between the virtual node and the source node of the edge, denoted by r k,j,n 、m k,j,n 、u k . Since rescale has a larger delay than the other two operations, reducing its level can significantly improve performance. Therefore, it is placed after the modswitch operation that can reduce the level. If rescale is performed before upscale, the loss of accuracy caused by downscaling is irreversible. In addition, since the upscale operation can increase the scale, placing it before the modswitch operation may cause a scale overflow, so it is inserted after modswitch. Therefore, the order of insertion of the three types of operations is modswitch→upscale→rescale. Note that the downscale operation in HECATE consists of an upscale operation and a rescale operation, so this operation is covered in the present invention. Figure 2 As shown in (c), modswitch operations are inserted on the edges (0,2) and (1,2), so that the level of virtual nodes 0 and 1 is reduced from 3 to 2, while the scale remains unchanged. On the edge (2,3), the scale is increased by 2 through the upscale operation 30, which is then reduced by 2 through the rescale operation 60 , which also reduces the level by 1.

[0047] Constraints: After defining the above variables and constants, the following constraints are introduced to represent feasible scale management.

[0048] 1) Node rank assignment constraint: All rank-related variables, including each node in V and each node on edge k∈E, can only be assigned to one rank.

[0049]

[0050] 2) Node scale upper limit constraint: To avoid scale overflow leading to irreversible results, the node scale (including all arithmetic nodes and virtual nodes) should meet the following requirements:

[0051]

[0052] On a given edge, since the worst case occurs on the virtual nodes, ensuring that the scale and level of these virtual nodes meet the above constraints can ensure that all nodes on the edge can meet this constraint.

[0053] 3) Node size lower limit constraint: The node size should not be too small to maintain a low relative error and thus obtain better service quality. Since the minimum size on an edge is located at the virtual node or the source node (the size of all intermediate variables is greater than or equal to these two nodes), it is sufficient to ensure that these two nodes meet the constraints.

[0054]

[0055] The waterline represents the lower limit of the node size specified in advance, such as the coarse-grained fixed waterline in EVA and the fine-grained dynamic waterline proposed in ELASM.

[0056] 4) Arithmetic operation constraints: Different arithmetic operations have different requirements on the scale and level of the input, and produce different output results.

[0057] The multiplication operation requires that the virtual nodes of the two input edges are at the same level and does not impose any constraints on the scale. After the multiplication operation, the level of the result remains unchanged, and the scale becomes the product of the two input scales (in logarithmic representation, it is the sum).

[0058]

[0059]

[0060] The addition operation requires that the virtual nodes of the two input edges are at the same level and have the same size. The scale and level of the result will remain unchanged.

[0061]

[0062] The rank and scale of the result of the rotation operation remain unchanged.

[0063]

[0064] 5) Scale management operation constraints:

[0065] Rescale operation constraint: Since among the three scale management operations, only the rescale operation can reduce the node scale, its number depends on the difference between the scale of the source node and the scale of the virtual node on this edge.

[0066]

[0067] The final level after the rescale operation is the same as the level of the virtual node.

[0068]

[0069] Modswitch operation constraint: On an edge, the sum of the modswitch times and the rescale times determines the level reduction on the edge.

[0070]

[0071] Upscale operation constraint: The upscale operation determines the increase in the size of an edge.

[0072]

[0073] 6) Input and output constraints: Input and output nodes (V input,output ) has a certain scale i , needs to be constrained; in addition, the input ciphertext node (V inputcipher ) has a maximum level of L.

[0074]

[0075] Objective function:

[0076] Total delay of arithmetic operations: ALLOP is a set of addcc (ciphertext encryption operation), addcp (ciphertext plus plaintext operation), mulcc (ciphertext multiplication operation), mulcp (ciphertext multiplication operation), and rotate (ciphertext rotation and shift operation). Therefore, the total delay of arithmetic operations in the program is Dc for:

[0077]

[0078] The num is introduced for the rotate operation. Considering the overhead of key generation, rotate is generally designed to only move an integer power of 2. If the rotation amount is not an integer power of 2, the number of rotation operations needs to be calculated. The num of other operations is 1.

[0079] Total latency of scale management operations: The latency of the Upscale operation is excluded from consideration because computing it requires multiplication of variables, which quickly increases the size of the problem. Furthermore, the latency of upscale is not a significant component of the total latency, making this omission a reasonable simplification. Total latency of scale management operations D s for:

[0080]

[0081] Where D mod,n,j represents the delay of n modswitch operations with final level j, D res,n,j Represents the latency of n rescaling operations with final level j.

[0082] Optimization goal: The goal of this optimization problem is to minimize the total delay D all :

[0083] D all =D c +D S

[0084] After the above modeling, the problem can be solved by using existing mathematical tools, such as Gurobi.

[0085] Experimental results:

[0086] In order to evaluate the effect of the method proposed in the present invention, 10 tasks were selected as test benchmarks, including Sobel filter detection (SF) and Harris corner detection (HCD) in image processing, linear regression (LR), polynomial regression (PR) and multivariate regression (MR) in statistical machine learning, multilayer perceptron (MLP) in neural networks, and retrieval (RT) and set-union (SU) in privacy information. The numbers after RT and SU represent the number of key-value pairs. Before the experiment, all tasks have been vectorized. In order to verify the performance and compilation time of the present invention, the heuristic method EVA and the iteration-based method ELASM were selected as benchmarks. ELASM explored 12,000 scale management samples, and its optimization goal was modified to minimize the delay of the program. The three methods used the same encryption parameters and set the scaling factor S f Set to 2 60 , the polynomial modulus N is set to 2 15 , thus achieving a 128-bit security level.

[0087] Figure 3 The performance comparison of different scale management methods for a given waterline. All results are from actual execution, not from estimation. Compared with heuristic methods and iteration-based methods, the method proposed in the present invention can more accurately represent the solution space and is easier to find a better solution. Among them, compared with EVA and ELASM, the present invention can achieve an average performance improvement of 1.72 times and 1.19 times. The most obvious improvement cases occur in PR and MR, because the previous methods cannot accurately express the solution space under these two kernels. And because the input image in MLP is the ciphertext provided by the user and the weights are the plaintext provided by the server side, there are almost no mulcc operations in this kernel. This leads to an extremely small solution space, making the performance difference between the three methods negligible.

[0088] In order to demonstrate the scalability of the present invention, the performance of the three methods under different watermarks of MR and PR are experimentally compared. Figure 4 As shown in Figure 1, it is a performance comparison of different scale management methods under PR tasks at different waterlines, and HEILP represents the present invention. Figure 5 As shown, it is a performance comparison of different scale management methods under MR tasks at different waterlines, and HEILP represents the present invention.

[0089] It can be seen that the present invention can achieve performance improvement under almost all parameters, while ELASM may not be able to find a better solution in some cases due to the limited search space.

[0090] The following table shows Figure 3The compilation time overhead in the experiment, where the speedup ratio refers to the speedup of the present invention compared to the iteration-based method ELASM. In the absence of expensive undirected iterative exploration, the present invention greatly reduces the solution time compared to ELASM. In addition, since ELASM cannot perceive the size of the solution space, programmers are required to manually adjust the search parameters. Otherwise, they may end up performing a large number of unnecessary searches in a small space, just as in the MLP task. In contrast, the present invention effectively models the solution space so that the solution time can automatically vary for different problem sizes. In addition, due to the constraints of the bootstrap, the operation depth allowed by a single bootstrap is limited, making the expansion of the solution time brought by integer linear programming acceptable.

[0091] Task EVA ELASM The present invention Speedup SF 0.0565 8.2701 0.108 76.575 HCD 0.0619 12.9187 0.2808 46.0068 LR 0.0647 13.4591 0.2948 45.6550 PR 0.0817 30.3322 4.1366 7.3326 MR 0.1094 28.4936 2.125 13.4088 MLP 0.0916 44.1797 0.242 182.5607 RT256 0.0557 5.114 0.1683 30.3862 RT1024 0.0527 5.4431 0.081 67.1988 SU16 0.0575 5.9592 0.2512 23.7229 SU128 0.0583 10.592 1.2557 8.4351

[0092] The preferred specific embodiments of the present invention are described in detail above. It should be understood that ordinary technicians in the field can make many modifications and changes based on the concept of the present invention without creative work. Therefore, all technical solutions that can be obtained by technicians in the technical field based on the concept of the present invention through logical analysis, reasoning or limited experiments on the basis of the prior art should be within the scope of protection determined by the claims.

Claims

1. A scale management method for a homomorphic encryption compiler based on integer linear programming, characterized in that: The following steps are involved: Step 1: Convert the input program into high-level IR and perform program-level optimization; Step 2: Convert high-level IR to FHE::fhe dialect; Step 3: The FHE::fhe dialect is reduced to the dialect of the specific scheme, the scale management problem is modeled as an integer linear programming problem, and the low-level IR of different FHE schemes is generated; Step 4: The low-level IR generates target code for the hardware backend and performs hardware optimization.

2. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: The goal of the scale management problem is to determine the scale and level of all arithmetic nodes and insert scale management operations to minimize the latency of the program while satisfying constraints.

3. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 2, characterized in that: The constraints include node level allocation constraints, node scale upper limit constraints, node scale lower limit constraints, arithmetic operation constraints, scale management operation constraints, input and output constraints.

4. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: The integer linear programming problem is solved using Gurobi.

5. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: The step 1 adopts loop unrolling optimization.

6. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: In the step 1, the compilation optimization method includes dead code elimination, constant folding, and common sub-expression elimination.

7. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: In step 2, the FHE::fhe dialect defines the operations and semantics of homomorphic encryption programs.

8. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: In step 2, the optimization method includes vectorization and circuit optimization.

9. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: In step 3, the dialects of the specific scheme include FHE::bfv, FHE::bgv, and FHE::ckks.

10. The scale management method based on integer linear programming of the homomorphic encryption compiler according to claim 1, characterized in that: In step 4, the hardware backend includes a CPU, a GPU, and an accelerator.

Images