Methods, systems, and programs for analyzing fully homomorphic encryption.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- INTERNATIONAL BUSINESS MACHINE CORPORATION
- Filing Date
- 2022-12-21
- Publication Date
- 2026-08-04
Smart Images

Figure 0007900501000002 
Figure 0007900501000003 
Figure 0007900501000004
Abstract
Description
Technical Field
[0001] The present invention relates to the field of homomorphic encryption, particularly fully homomorphic encryption.
[0002] Fully homomorphic encryption (FHE) is a type of encryption that allows computations to be performed on encrypted data (the "ciphertext") without first decrypting it. These computations give the same result as if they were performed on the same data in its unencrypted state (the "plaintext") when decrypted.
[0003] In FHE, the encryption scheme involves an encryption operation that encrypts some fixed-size vector to create the ciphertext, and this computation includes operations known as SIMD (Single Instruction, Multiple Data) operations. The decryption operation then extracts the data from the resulting ciphertext. The encryption scheme generally guarantees that any computation performed on the encrypted data yields the same result as applying the same computation to the underlying unencrypted data.
[0004] The unique property of FHE is particularly useful when computations on personal or confidential data must be outsourced to an entity or location that cannot guarantee its confidentiality. Such personal or confidential data can first be encrypted using a homomorphic encryption method and then sent entirely in encrypted form for processing (e.g., to a commercial cloud environment). The result of the computation is also returned to the original sender in encrypted form, and this sender can decrypt it in a secure environment to view the result. In this procedure, the unencrypted data is never made available to the entity performing the computation, and of course, it is also not made available to malicious third parties attempting to breach the entity's computer storage, thus reducing concerns regarding privacy and other confidentiality.
[0005] However, FHE is not without its limitations. In some encryption methods, such as the well-known CKKS (Cheon-Kim-Kim-Song) scheme, computation often introduces a certain amount of noise into the data, and this noise increases with the number of sequential operations. This results in a certain discrepancy between the encrypted computation data and the result that would have occurred if the computation had been performed on the unencrypted original data. If too many sequential operations are performed, the noise can become too large, and the reliability of the result may be completely lost.
[0006] Another limitation that sometimes arises is data corruption. Some FHE schemes are known to have some limitations regarding the range of unencrypted data values they can handle well. In some calculations, the result may exceed this range ("overflow"), or some intermediate value in the calculation may exceed this range. In either case, the result will be corrupted, that is, completely inaccurate. In this case, since the data is encrypted and therefore the entity performing the calculation cannot decrypt it, and is unaware that such an overflow has occurred, no error or warning is usually generated. It should be noted that the range of values that can be correctly stored in ciphertext depends on the FHE scheme and how it is configured, and may even change during the calculation. For example, the range may be [-100,100] at the beginning of the calculation, but decrease to [-1,1] later in the calculation.
[0007] The examples of related technologies and their associated limitations described herein are illustrative and not exclusive. Other limitations of the related technologies will become apparent to those skilled in the art by reading this specification and examining the drawings. [Overview of the project]
[0008] The following embodiments and aspects are described and illustrated together with the systems, tools, and methods, but these are intended to be illustrative and illustrative and not limiting in scope.
[0009] One embodiment provides a computer implementation method that automatically performs the following steps in response to the identification that a Single Instruction, Multiple Data (SIMD) operation has been instructed to be performed or has been performed on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software: (a) performing the same operation on one or more original plaintexts, each of which is a decrypted version of one of the one or more original ciphertexts; (b) decrypting the ciphertext obtained from the operation performed on one or more original ciphertexts; (c) comparing the decrypted ciphertext with the plaintext obtained from the same operation performed on one or more original plaintexts; and (d) based on the comparison, performing at least one of the following: (i) determining the amount of noise caused by the operation performed on one or more original ciphertexts; (ii) determining whether the unencrypted data underlying one or more original ciphertexts has been corrupted by the operation performed on one or more original ciphertexts; and (iii) determining the correctness of the algorithm including the operation performed on one or more original ciphertexts.
[0010] Another embodiment includes at least one hardware processor and a non-transient computer-readable storage medium in which program code is embodied, wherein the program code is generated by the at least one hardware processor using Single Instruction, Multiple A system is provided comprising a non-transient, computer-readable storage medium on which a Data (SIMD) operation is executable to automatically perform the following steps in response to the system identifying that a Data (SIMD) operation has been instructed to be performed or has been performed on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software: (a) performing the same operation on one or more original plaintexts, each of which is a decrypted version of one or more of the original ciphertexts; (b) decrypting the ciphertext obtained from the operation performed on one or more original ciphertexts; (c) comparing the decrypted ciphertext with the plaintext obtained from the same operation performed on one or more original plaintexts; and (d) based on the comparison, performing at least one of the following: (i) determining the amount of noise caused by the operation performed on one or more original ciphertexts; (ii) determining whether the unencrypted data underlying one or more original ciphertexts has been corrupted by the operation performed on one or more original ciphertexts; and (iii) determining the correctness of the algorithm including the operation performed on one or more original ciphertexts.
[0011] A further embodiment is a computer program product comprising a non-transient computer-readable storage medium in which program code is embodied, wherein the program code is provided by at least one hardware processor as a Single Instruction, Multiple Instruction A computer program product is provided which, in response to the identification that a Data (SIMD) operation has been instructed to be performed or has been performed on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software, is executable to automatically perform the following steps: (a) performing the same operation on one or more original plaintexts, each of which is a decrypted version of one or more of the original ciphertexts; (b) decrypting the ciphertext obtained from the operation performed on one or more original ciphertexts; (c) comparing the decrypted ciphertext with the plaintext obtained from the same operation performed on one or more original plaintexts; and (d) based on the comparison, performing at least one of the following: (i) determining the amount of noise caused by the operation performed on one or more original ciphertexts; (ii) determining whether the unencrypted data underlying one or more original ciphertexts has been corrupted by the operation performed on one or more original ciphertexts; and (iii) determining the correctness of the algorithm including the operation performed on one or more original ciphertexts.
[0012] In some embodiments, steps (a) and (b) are performed by FHE software or other FHE software.
[0013] In some embodiments, the method is repeated over multiple SIMD operations, or the program code is executable to be repeated over multiple SIMD operations, in each iteration, one or more original ciphertexts are the result of performing a SIMD operation on one or more original ciphertexts from a preceding iteration, and one or more original plaintexts are the result of performing the same operation on one or more original plaintexts from a preceding iteration.
[0014] In some embodiments, the method further includes, or the program code can further perform: maintaining a log of the comparisons in step (c) of all iterations.
[0015] In some embodiments, the method or program code is implemented as an implementation of an abstract application programming interface (API) having the same set of operators as the FHE software.
[0016] In some embodiments, the abstract API includes an abstract class programmed to interface with the FHE software, such that it gives the FHE software an instruction to perform decryption in step (b) and receives the decrypted ciphertext from the FHE software.
[0017] In some embodiments, the abstract class is further programmed to identify that a SIMD operation has been instructed to be performed by the FHE software on one or more original ciphertexts, to transparently pass any instructions from the user's algorithm intended for the FHE software to the FHE software, except for step (b) which is not performed by the FHE software, and to perform the comparison in step (c).
[0018] In some embodiments of the method, this is performed by at least one hardware processor.
[0019] In addition to the exemplary embodiments and models described above, further embodiments and models will become apparent by examining the following detailed description with reference to the figures. [Brief explanation of the drawing]
[0020] Exemplary embodiments are shown in the drawings. Dimensions of components and features shown in the drawings are generally selected for convenience and clarity of presentation and are not necessarily shown to scale. The drawings are as follows:
[0021] [Figure 1] This is a block diagram of an exemplary system for analyzing, debugging, or both FHE calculations according to one embodiment. [Figure 2] This is a flowchart of a method for analyzing, debugging, or both of the FHE calculation operations according to one embodiment. [Figure 3] This is a flowchart illustrating one iteration of the method shown in Figure 2 according to one embodiment. [Figure 4] This flowchart illustrates one iteration of a specific possible implementation according to one embodiment. [Figure 5] This flowchart illustrates one iteration of a specific possible implementation according to one embodiment. [Figure 6] This flowchart illustrates one iteration of a specific possible implementation according to one embodiment. [Modes for carrying out the invention]
[0022] Disclosed herein is a technique embodied in a method, a system, and a computer program product for analyzing or debugging or both, computational operations performed on data within a framework of FHE. Analyzing and debugging may include, for example, determining the amount of noise caused by operations performed on one or more ciphertexts, determining whether unencrypted data underlying a ciphertext has been corrupted by operations performed on the ciphertext, and determining the correctness of an algorithm including operations performed on the ciphertext.
[0023] This technique is particularly useful when devising computational algorithms (a series of operations performed on encrypted data) during the development stage of FHE applications. For example, when developing an FHE application that performs neural network inference on encrypted data, developers may benefit greatly by being able to analyze or debug or both before deploying their algorithms.
[0024] This technology can generally operate as follows: In response to being instructed by or identifying that a SIMD operation has been performed on one or more original ciphertexts by specific FHE software, the following steps can be automatically and sequentially executed: First, the same operation is performed on one or more original plaintexts, each of which is a decrypted version of one of the one or more original ciphertexts. Second, the ciphertext obtained from the operation performed on one or more original ciphertexts is decrypted. Third, the decrypted ciphertext is compared with the plaintext obtained from the same operation. Fourth, based on the comparison, at least one of the following is performed: determining the amount of noise caused by the operation performed on one or more original ciphertexts, determining whether the unencrypted data underlying one or more original ciphertexts has been corrupted by the operation performed on the original ciphertexts, and determining the correctness of the algorithm including the operation performed on one or more original ciphertexts ("debugging").
[0025] The present technology is implemented, optionally, as an abstract application programming interface (API) for one or more standard FHE software libraries as follows: the open-source HElib library (S. Halevi and V. Shoup, "HElib - An Implementation of Homomorphic Encryption", available at https: / / github.com / shaih / HElib / , last viewed on December 19, 2021), the open-source SEAL library (Microsoft Research, "Microsoft SEAL", available at https: / / github.com / Microsoft / SEAL, last viewed on December 19, 2021), the open-source PALISADE library (available at https: / / palisade-crypto.org, last viewed on December 19, 2021), etc. This abstract API provides the same functionality as the above FHE libraries, but can be implemented such that all operations performed on one or more ciphertexts are also automatically performed on one or more plaintexts, thereby automatically tracking noise or data or both damages and then being able to be reported to developers using the standard FHE software libraries.
[0026] Next, refer to FIG. 1, which shows a block diagram of an exemplary system 100 for analyzing or debugging or both FHE computational operations according to one embodiment. System 100 can include one or more hardware processors 102, a random access memory (RAM) 104, and one or more non-transitory computer-readable storage devices 106.
[0027] The storage device 106 can store program instructions or components, or both, configured to operate the hardware processor 102. The program instructions may include one or more software modules, such as the analysis / debugging module 108. The software components may include an operating system having various software components or drivers, or both, to control and manage common system tasks (e.g., memory management, storage device control, power management, etc.) and to facilitate communication between various hardware and software components.
[0028] System 100 can operate by loading instructions for the analysis / debugging module 108 into RAM 104 when they are executed by the processor 102. Instructions for the analysis / debugging module 108 can cause System 100 to identify that the FHE software has instructed or performed SIMD operations on one or more original ciphertexts 110, and in response to this, to perform a series of automatic actions, which can output one or more judgments 112 such as the amount of noise caused by the FHE operations, whether data corruption occurred, and whether the computation algorithm (driving the SIMD operations) is correct.
[0029] The system 100 described herein is merely an exemplary embodiment of the present invention and can actually be implemented with hardware only, software only, or a combination of both hardware and software. System 100 may have more or fewer components and modules than those shown, or may combine two or more components, or the configuration or arrangement of components may differ. System 100 may include any additional components (not shown) that enable it to function as an operable computer system, such as a motherboard, data bus, power supply, network interface card, display, and input devices (e.g., keyboard, pointing device, contact display). Furthermore, the components of system 100 may be located in the same location or distributed, or the system may be configured to run as one or more cloud computing "instances," "containers," "virtual machines," or other types of encapsulated software applications known in the art.
[0030] Next, we will consider the instructions of the analysis / debugging module 108 with reference to the flowchart in Figure 2, which shows a method 200 for performing analysis, debugging, or both of FHE calculation operations according to one embodiment.
[0031] The steps of Method 200 may be performed in the order presented, or in a different order (or in parallel), as long as the input required for one step can be obtained from the output of the preceding step. In addition, the steps of Method 200 are performed automatically (for example, by System 100 in Figure 1) unless otherwise specified.
[0032] Method 200 is optionally implemented using an implementation of the abstract API for one or more standard FHE software libraries, as will be further described in the section on exemplary implementations.
[0033] In step 202, the FHE software can automatically identify that it has been instructed to perform, or has performed, a SIMD operation on one or more specific ciphertexts (hereinafter referred to as “original ciphertexts”). The operation may be multiplication, addition, or both, which are basic operations available in the FHE framework. It should be noted that the instructed operation may involve a single original ciphertext (e.g., multiplying that ciphertext by a specific value, or adding that ciphertext by a specific value), or it may involve two (potentially more) ciphertexts, with the operation performed on them (e.g., multiplying one ciphertext by another, or adding two ciphertexts). Therefore, in this disclosure, the terms “one or more (original) ciphertexts” or simply “(original) ciphertexts” are used to indicate these two possibilities. Consequently, in this specification, the terms “one or more (original) plaintexts” or more simply “(original) plaintexts” are used to indicate that an operation instructed to be performed on “one or more (original) ciphertexts” has also been performed on each of the “one or more (original) plaintexts.” In other words, each (original) ciphertext is associated with one (original) plaintext in a one-to-one relationship.
[0034] With regard to SIMD operations, in response to this identification, the following steps numbered 204 through 214 may be automatically performed:
[0035] In step 204, the same operations instructed or performed on one or more original ciphertexts can also be performed on one or more plaintexts (referred to here as “original plaintexts” or “one or more original plaintexts”), each being a decrypted version of one of the original ciphertexts. The original plaintexts are available from a preliminary step (not shown in the figure) in which such plaintexts are obtained or generated, encrypted using FHE software, and used to generate the original ciphertexts. Operations on the original plaintexts can be performed, for example, using standard arithmetic operations (e.g., multiplication or addition or both) provided directly by system 100 in Figure 1 or other computing devices. Alternatively, operations on the original plaintexts can be performed using the same FHE schemes used when performing operations on the original ciphertexts, using either the same FHE software or different FHE software configured with the same associated FHE schemes.
[0036] In step 206, the ciphertext obtained from the operations performed on the original ciphertext can be decrypted using the relevant FHE scheme, either by the same FHE software or different FHE software, as described above.
[0037] In step 208, the decrypted ciphertext can be compared with the plaintext obtained from the same operation performed on the original plaintext. The differences identified in this step can then serve as an indicator that the operation performed on the original ciphertext introduced some noise into the underlying data of the original ciphertext, or that the underlying data was completely corrupted.
[0038] Therefore, based on the comparison in step 208, one or more of the following actions may be performed:
[0039] The first possible action, as described with reference to step 210, is to determine the amount of noise caused by the operation performed on the original ciphertext. As a simplified example, if the CKKS scheme was used to perform the operation, and the decrypted ciphertext contains the value 1.00001, and the plaintext obtained from the same operation has the value 1.00002, then it can be determined that noise equivalent to 0.00099999% was caused by the operation.
[0040] In a variation of the first action, step 210 may also be configured to immediately warn the user if it is determined that the noise exceeds a predetermined threshold. The threshold may refer to noise generated in a single operation or noise accumulated over multiple operations. This warning may also take the form of "throwing" an exception, as is well known in the field of computer programming.
[0041] A second possible action, as described with reference to step 212, is to determine whether the unencrypted data underlying the original ciphertext has been corrupted by the operation performed on the original ciphertext. Such data corruption may occur, for example, if the result of the operation exceeds the maximum range of values acceptable for the ciphertext obtained at this point in the calculation. To determine whether the underlying data is corrupted and to further distinguish it from noise, the difference found in step 208 may be compared to a predetermined threshold. The threshold can be set to a sufficiently high value (absolute value or percentage) to ensure that data corruption is not mistaken for noise. For example, the threshold can be set to a 10% difference between the decrypted ciphertext and the plaintext obtained from the same operation performed on the original plaintext. An appropriate threshold can be, for example, in the range of 5-20%, and the exact threshold can be selected by the user based on the type of calculation at hand.
[0042] In a variation of the second action, step 212 may also be configured to immediately alert the user if it is determined that the unencrypted data underlying the original ciphertext is corrupted. The alert may be in the form of throwing an exception. Another possibility is to automatically change (a) the settings of the FHE software or scheme to allow a wider range of values, or (b) the way the calculation is performed, or both, or to guide the user to make such changes.
[0043] A third possible action, as described with reference to step 214, is to determine the correctness of the algorithm containing the operation. This action is sometimes called "debugging" the algorithm. This may be done automatically, for example, by detecting which line of the algorithm is responsible for the difference that arose from step 208, or it may be done manually by a developer who can understand, based on the difference, which part of the algorithm may be wrong.
[0044] It should be noted that Method 200 can also work by not performing any of steps 210-214, and instead simply providing the comparison result from step 208 as its final output. In certain scenarios, such an automated comparison may be valuable in itself to the user of Method 200 (e.g., a developer).
[0045] Method 200, as described above, concerns how a single operation is identified and subsequently handled. Since most algorithms used to drive FHE calculations involve many such operations, it may be useful to iterate through the steps of Method 200 for all calculation operations and maintain a log 216 of the results of step 208 (comparison) and, optionally, one or more decisions made in steps 210-214, along with a description of each operation. In each iteration, at least one of the original ciphertexts is a ciphertext obtained from the execution of a SIMD operation in a preceding iteration, and similarly, at least one of the original plaintexts is a plaintext obtained from the execution of the same operation in a preceding iteration. In other words, each new iteration is accompanied by at least one (and possibly all) of the ciphertexts and plaintexts calculated in a preceding iteration (depending on what the user's algorithm instructs). This logging allows tracking the evolution of the original ciphertext through the sequence of operations defined by the algorithm.
[0046] Once Method 200 has completed all iterations of the computation, the user can review the log to understand how noise, data corruption, or errors in the algorithm, or a combination thereof, affected the original ciphertext in each subsequent operation (and potentially multiple effects).
[0047] Table 1 below illustrates this by showing a highly simplified log illustrating how logging iterations of Method 200 can be beneficial to the user in determining and tracking the evolution of noise. The ciphertext values listed in this table are, of course, presented in unencrypted, human-readable form. In addition, for the sake of simplification, the examples in this table relate to operations performed on a single original ciphertext and a single original plaintext.
[0048] [Table 1]
[0049] The first row of the table shows the first iteration of Method 200. The underlying value of the original ciphertext is 1, and the operation performed on it is multiplication by 4, as with the related original plaintext. This results in the correct calculation result of 4 in the plaintext, but in the ciphertext, it yields a slightly noisy (and mathematically incorrect) result of 4.001. The absolute value of the difference is 0.001, which reflects 0.025% of the correct calculation result. It should be noted that actual noise in the FHE scheme tends to start on a much smaller order than in this simplified example.
[0050] The last two columns showing the difference can, of course, be represented by other means, such as by including only one of these columns in the log, or by the quotient of the obtained ciphertext and plaintext values. Therefore, the format of the difference shown may be user-configurable.
[0051] An intermediate reference to Figure 3 is provided, which is a flowchart 300 showing one iteration of method 200 represented by the first row of the table. At the start of the iteration, the starting values of both the ciphertext 302a and its associated plaintext 302b are 1. Next, operations including multiplication by 4 are performed on these ciphertexts 302a and plaintext 302b, resulting in a ciphertext 304a with a value of 4.001 and plaintext with a value of 4. A comparison of the latter two shows the noise value of 0.001 accumulated in this iteration of method 200.
[0052] Returning to Table 1, the second row of the table shows the second iteration of Method 200. The underlying value of the ciphertext is 4.001 (the result of the ciphertext from the previous iteration). The operation performed on this ciphertext is, this time, the same as the operation performed on the associated plaintext: addition of 1. In this case, there is a 0.02% difference between the two results, but it is clear that the noise has not increased from the previous iteration and remains at 0.001. In other words, the addition operation does not generate noise.
[0053] In other scenarios, logging 216 might indicate that a particular operation did not generate noise, even though the accumulated noise appears to have increased after that operation. For example, suppose the logged noise from five consecutive operations was {0.00001, 0.00002, 0.00008, 0.0001, 0.001}, but the log shows that the third operation is a multiplication by 4, so it is clear that the operation did not generate noise. Rather, due to the nature of multiplication, the noise was quadrupled by the second operation, so the noise is quadrupled as expected. Example Implementation (Implementation form 1)
[0054] As briefly stated above, Method 200 may optionally be implemented using an abstract API to one or more standard FHE software libraries (in an object-oriented programming language). For this purpose, an abstract class having the same interface as a standard FHE software library can be provided; that is, it provides the same set of operators as those present in a standard FHE software library, such as encryption, decryption, multiplication, and addition. A concrete implementation of this API may delegate calls to a specific FHE library, and multiple such concrete implementations can be created for multiple different FHE libraries. Embodiments of the present invention may be implemented as yet another concrete implementation of this API, thereby each operation being performed on one or more ciphertexts and also on one or more individual plaintexts by delegating calls to an FHE library, as specified by Method 200.
[0055] By implementing Method 200 as an implementation of such an abstract API, users can analyze, debug, or both FHE computation operations by indirectly manipulating the underlying standard FHE software library through the abstract API. In other words, the user's algorithm may include instructions that act on the same operators (e.g., functions, methods, classes, etc.) as those in the library (which the user is familiar with), and the abstract class performs the steps of Method 200 transparently and without the user's knowledge by instructing the library (and receiving the results) or by executing the code of the abstract class itself.
[0056] Referring to Method 200, the step of identifying that a SIMD operation is being performed (202) is specific to this implementation and may not actually require any particular execution. Rather, in response to the user's algorithm providing an instruction to perform such an operation on the original ciphertext (e.g., an instruction intended for the underlying FHE software library, as is evident from its syntax), the abstract class essentially passes that instruction to the library (step 202), and also utilizes its own program code to perform the same operation on the original plaintext (step 204), or sends an instruction to the library (or another library using the same FHE scheme) to accomplish step 204. For each of steps 202 and 204, the abstract class code is configured to receive the result of the computation from the relevant library as well as from the code itself. Next, to perform step 206, the abstract class can decrypt the ciphertext obtained from the operation performed on the original ciphertext and send an instruction to the library (or, as before, another library using the same FHE scheme) to receive the decrypted ciphertext. Next, in step 208, the abstract class itself may include program code that performs a comparison between the decrypted ciphertext and the plaintext obtained from step 204, and code that performs one or more of steps 210-214. (Implementation form 2)
[0057] The second implementation may be similar to the first, but it has a major difference: it operates only on plaintext, not on ciphertext. In other words, the underlying standard FHE software library does not need to be used for any task, and in fact, actions can be performed only on plaintext without the help of the FHE software (for example, by using the computer's standard arithmetic functions).
[0058] Referring to Method 200, step 204 is also performed in response to detecting that a SIMD operation has been instructed by the user's algorithm on one or more ciphertexts, but on one or more individual plaintexts that have not undergone FHE encryption. In fact, in this implementation, the abstract class can refrain from encrypting the user's original data into ciphertext at all (even if instructed to do so by the user's algorithm), and only one or more plaintexts are actually available when Method 200 begins. Therefore, even if the user instructs a SIMD operation on what they consider to be ciphertext, the operation will actually be performed on plaintext (the user's original unencrypted data). As a result, steps 206 onward can be omitted, except for performing a variation of step 214 that can determine the correctness of the algorithm.
[0059] This implementation is particularly useful for debugging purposes, i.e., to determine the correctness of the user's algorithm (according to step 214). However, it may not be suitable for these determinations because noise and data corruption are not expected to occur when performing calculations on plain text.
[0060] The particular advantage of this implementation is its speed. By omitting encryption and decryption operations and performing no operations on the ciphertext, this implementation is likely to run much faster for a given user's algorithm than any implementation that requires such actions. (Implementation form 3)
[0061] The third implementation may be similar to the first, but the key difference is that each operation is performed on one or more tuples containing two ciphertexts c1 and c2 and two plaintexts p1 and p2. Before each operation, in each such tuple, c1 is decrypted and the result is copied to p1. In addition, p2 is encrypted and the result is copied to c2. This allows the user to distinguish between noise caused by a specific operation and noise accumulated by multiple preceding operations.
[0062] Next, refer to Figure 4, which is a flowchart 400 showing one iteration in this implementation. This is the iteration described in row 2 of Table 1, for example, and relates to a simple case where only a single original ciphertext is processed, in this case a single tuple of c1, c2, p1, and p2.
[0063] In flowchart 400, blocks 402a and 402d are essentially the same as blocks 302a and 302b in Figure 3, respectively, except for their different values. Similarly, blocks 404a and 404d are essentially the same as blocks 304a and 304b in Figure 3, respectively, except for their different values. Therefore, in Figure 4, blocks 402b and 402c with values before the operation, and blocks 404b and 404c with values after the operation are added.
[0064] This implementation can function as follows: First, from block 402a, we can see that noise with a value of 0.001 has already been accumulated as a result of one or more preceding iterations (for example, the iteration in the first row of Table 1). Before performing the computation of the illustrated operation, two actions may occur: one is to copy the underlying value of the ciphertext in block 402a (=4.001), which is the result of a preceding operation performed on the ciphertext, into the plaintext (block 402b). The other is to copy the plaintext value in block 402d (=4), which is the result of a preceding operation performed on the plaintext, into the ciphertext (block 402c).
[0065] This means that the associated iteration operation (in this case, the addition of 1) is performed on all four blocks 402a through 402d.
[0066] The result of this operation is a value of 5.001, which is the underlying value for the ciphertext of both block 404a and block 404b, and a value of 5 for the plaintext of both block 404c and block 404d.
[0067] Next, comparing the differences between blocks 404a and 404b, blocks 404c and 404d, and finally between 404a and 404d, the accumulated noise after this calculation is 0.001, which is clearly not the result of the current iteration, but rather the result of one of the preceding iterations. This is because the differences between blocks 404a and 404b, and between blocks 404c and 404d were all zero. Given this determination regarding noise, the user may be guided by Method 200 to modify the algorithm to reduce the accumulation of noise before this iteration.
[0068] Next, refer to Figure 5. Figure 5 is a flowchart 500 similar to the one in Figure 4, but it shows a different numerical example that leads to different conclusions about the source of the noise. Similar elements in Figure 4 and Figure 5 are indicated by the same symbols, except that the symbols in Figure 5 are enclosed in single quotes.
[0069] In flowchart 500, we can see that the initial noise is 0.001, similar to Figure 4. This is evident from the difference between blocks '402a' and '402d'. After the aforementioned copying of blocks '402a' to '402d', a specific operation, such as multiplication by 10, is performed on all four of these blocks. As a result, the difference between blocks '404a' and '404b' is 0.1, and similarly, the difference between blocks '404c' and '404d' is also 0.1, indicating that the current iteration has added 0.1 of noise compared to the exactly 0.001 of noise accumulated before this iteration. Given this determination regarding the noise, the user may be guided by method 200 to modify the algorithm so that the noise caused by the current operation is reduced, as it is far more significant (by two orders of magnitude) than the previous accumulation of noise.
[0070] Next, refer to Figure 6. Figure 6 is a flowchart 600 similar to the flowcharts in Figures 4 and 5, but shows yet another numerical example that leads to different conclusions about the source of noise. Similar elements in Figures 4, 5 and 6 are indicated by the same symbols, except that the symbols in Figure 6 are enclosed in double quotes.
[0071] In flowchart 600, we can see that the initial noise is 0.001, similar to Figures 4 and 5. This is evident from the difference between blocks "402a" and "402d". After copying blocks "402a" to "402d" as described above, a specific operation, such as multiplication by 2, is performed on all four blocks. As a result, the difference between blocks "404a" and "404b" is 0.1, but there is no difference between blocks "404c" and "404d". This indicates that the operation in the current iteration works accurately on already accurate (non-noisy) input values (of block "402d"), but adds noise to inaccurate (noisy) input values (of block "402a"). A possible explanation for this phenomenon is that the specific operation performed in this iteration is underperforming for a certain range of real numbers. Given this judgment regarding noise, the user may be guided by Method 200 to either modify their algorithm so that an alternative, less problematic operation, such as one that works accurately over a wider range of numbers, is used, or to address only the symptoms of this problem by reducing the accumulation of noise before this iteration and thus limiting the significant noise jump caused by this particular operation.
[0072] The present invention may be a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or a set of mediums) having computer-readable program instructions for causing a processor to execute an aspect of the present invention.
[0073] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive enumeration of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires. Rather, computer-readable storage media are non-transient (i.e., non-volatile) media.
[0074] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to an individual computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the individual computing / processing device.
[0075] The computer-readable program instructions for performing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Java(R), Smalltalk(R), and C++, and conventional procedural programming languages or similar programming languages such as the "C" programming language. The computer-readable program instructions may be executed entirely on the user's computer, partially as a standalone software package on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or on a server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) can be personalized by executing computer-readable program instructions by utilizing state information of computer-readable program instructions in order to carry out aspects of the present invention. In some embodiments, electronic circuits including, for example, application-specific integrated circuits (ASICs) can have computer-readable program instructions incorporated at the time of manufacture so that the ASIC is configured to execute these instructions without programming.
[0076] Aspects of the present invention will be described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, are executable by computer-readable program instructions.
[0077] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine that generates means for instructions to be executed via the processor of a computer or other programmable data processing device to perform functions / actions specified in one or more blocks of a flowchart or block diagram, or both. These computer-readable program instructions may also be stored in a computer-readable storage medium so that the computer-readable storage medium containing the instructions provides a product containing instructions that perform the modes of functions / actions specified in one or more blocks of a flowchart or block diagram, or both, and can be used to instruct a computer, a programmable data processing device, or other device, or a combination thereof, to function in a particular manner.
[0078] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing device, or other device to create a computer implementation process in which instructions executed on a computer, other programmable device, or other device implement functions / actions specified in one or more blocks of a flowchart or block diagram, or both, causing the computer, other programmable device, or other device to execute a series of operable steps.
[0079] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, containing one or more executable instructions for implementing a specified logical function. It should also be noted that each block in a block diagram or flowchart, or both, and combinations of blocks in a block diagram or flowchart, or both, may be implemented by a special-purpose hardware-based system that performs a specified function or operation, or executes a combination of special-purpose hardware and computer instructions.
[0080] In this specification and in the claims, “substantially,” “essentially,” and each of these terms, when describing a number, means a deviation of up to 20 percent (i.e., ±20%) from that value. Similarly, when such a term describes a range of numbers, it means a range up to 20 percent wider (more than 10 percent greater than or less than its explicit range).
[0081] In this specification, any numerical range should be understood to specifically reveal not only the individual numbers within that range, but also all possible subranges, so that such subranges and individual numbers each constitute an embodiment of the present invention. This applies regardless of the breadth of the range. For example, a description of the integer range from 1 to 6 should be understood to include not only the specifically revealed subranges such as 1 to 3, 1 to 4, 1 to 5, 2 to 4, 2 to 6, 3 to 6, but also the individual numbers within that range, such as 1, 4, and 6. Similarly, a description of the fractional range, for example, from 0.6 to 1.1, should be understood to include not only the specifically revealed subranges such as 0.6 to 0.9, 0.7 to 1.1, 0.9 to 1, 0.8 to 0.9, 0.6 to 1.1, 1 to 1.1, but also the individual numbers within that range, such as 0.7, 1, and 1.1.
[0082] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or to be limited to the express descriptions. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the embodiments described. The terms used herein have been selected to best describe the principles of the embodiments, their practical applications, or technical improvements to the art found in the market, or to enable those else skilled in the art to understand the embodiments disclosed herein.
[0083] In the specification and claims of this application, each of the words “comprise,” “include,” and “have,” as well as any phrases of that form, are not necessarily limited to the enumeration components to which the words are associated.
[0084] In the event of any conflict between this Specified Version and any document incorporated by reference or otherwise relied upon, this Specified Version is intended to prevail.
Claims
1. A method of computer information processing, wherein the method is In response to the identification that a Single Instruction, Multiple Data (SIMD) operation has been instructed to be performed, or has been performed, on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software, it automatically performs the operation. (a) The steps of performing the same operation on one or more original plaintexts, each of which is a decrypted version of one or more of the original ciphertexts, (b) The step of decrypting the ciphertext obtained from the operation performed on one or more original ciphertexts, (c) A step of comparing the decrypted ciphertext with the plaintext obtained from the same operation performed on the one or more original plaintexts, (d) Based on the above comparison, To determine the amount of noise caused by the operation performed on the one or more original ciphertexts, To determine whether the unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation performed on the one or more original ciphertexts, To determine the correctness of an algorithm that includes the operation performed on one or more original ciphertexts, A method comprising the step of performing at least one of the following.
2. The method according to claim 1, wherein steps (a) and (b) are performed by the FHE software or other FHE software.
3. The above method is repeated across multiple SIMD operations. In each of the aforementioned iterations: The above one or more original ciphertexts are the result of performing the SIMD operation on the above one or more original ciphertexts of the preceding iteration, The method according to claim 1, wherein the one or more original plain texts are the result of performing the same operation on the one or more original plain texts of the preceding iteration.
4. The method according to claim 3, further comprising maintaining a log of the comparisons for all of the iterations (c).
5. The method according to claim 1, which is implemented as an implementation of an abstract application programming interface (API) having the same set of operators as the set of operators of the FHE software.
6. The aforementioned abstract API, The instruction to perform the decoding in step (b) is given to the FHE software, The method of claim 5, comprising an abstract class programmed to interface with the FHE software to receive the decrypted ciphertext from the FHE software.
7. The aforementioned abstract class, Identifying that the SIMD operation has been instructed to be performed by the FHE software on one or more original ciphertexts, Except for step (b) which is not performed by the FHE software, any instruction from the user's algorithm intended for the FHE software is passed transparently to the FHE software, The method according to claim 6, further programmed to perform the comparison of step (c).
8. The method according to claim 1, which is executed by at least one hardware processor.
9. It is a system, At least one hardware processor, A non-transient computer-readable storage medium in which program code is materialized, wherein the program code is processed by at least one hardware processor In response to the identification that a Single Instruction, Multiple Data (SIMD) operation has been instructed to be performed, or has been performed, on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software, it automatically performs the operation. (a) The steps of performing the same operation on one or more original plaintexts, each of which is a decrypted version of one or more of the original ciphertexts, (b) The step of decrypting the ciphertext obtained from the operation performed on one or more original ciphertexts, (c) A step of comparing the decrypted ciphertext with the plaintext obtained from the same operation performed on the one or more original plaintexts, (d) Based on the above comparison, To determine the amount of noise caused by the operation performed on the one or more original ciphertexts, To determine whether the unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation performed on the one or more original ciphertexts, To determine the correctness of an algorithm that includes the operation performed on one or more original ciphertexts, A system comprising a non-transient computer-readable storage medium executable to perform the step of performing at least one of the following.
10. The system according to claim 9, wherein steps (a) and (b) are performed by the FHE software or other FHE software.
11. The aforementioned program code is executable so as to be repeated across multiple SIMD operations. In each of the aforementioned iterations: The above one or more original ciphertexts are the result of performing the SIMD operation on the above one or more original ciphertexts of the preceding iteration, The system according to claim 9, wherein the one or more original plain texts are the result of performing the same operation on the one or more original plain texts of the preceding iteration.
12. The aforementioned program code, The system according to claim 11, further operable to maintain a log of the comparisons for all of the iterations (c).
13. The system according to claim 9, wherein the program code is implemented as an implementation of an abstract application programming interface (API) having the same set of operators as the set of operators of the FHE software.
14. The aforementioned abstract API, The instruction to perform the decoding in step (b) is given to the FHE software, The system according to claim 13, comprising an abstract class programmed to interface with the FHE software to receive the decrypted ciphertext from the FHE software.
15. Abstract classes, Identifying that the SIMD operation has been instructed to be performed by the FHE software on one or more original ciphertexts, Except for step (b) which is not performed by the FHE software, any instruction from the user's algorithm intended for the FHE software is passed transparently to the FHE software, The system according to claim 14, further programmed to perform the comparison of step (c).
16. A computer program that causes a computer to perform the method described in any one of Claims 1 to 8.
17. A storage medium storing the computer program described in Claim 16 in a computer-readable storage medium.