Method, system, and program for analyzing fully homomorphic encryption

Abstract

A method, system, or program for analyzing Fully Homomorphic Encryption (FHE), in response to identifying that a SIMD operation has been directed to be performed or performed by FHE software on one or more original ciphertexts, performing the following: 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; decrypting the ciphertext resulting from the operation performed on the one or more original ciphertexts; comparing the decrypted ciphertext to a plaintext resulting from the same operation performed on the one or more original plaintexts; and performing at least one of the following based on the comparison: determining an amount of noise introduced by the operation, determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation, and determining correctness of an algorithm that includes the operation.

Description

[Technical field]

[0001] The present invention relates to the field of homomorphic encryption, and in particular to fully homomorphic encryption.

[0002] Fully Homomorphic Encryption (FHE) is a type of encryption that allows calculations to be made on encrypted data ("ciphertext") without first decrypting it. These calculations, when decrypted, give the same result as if they were performed on the same data in an unencrypted state ("plaintext").

[0003] In FHE, an encryption scheme includes a cryptographic operation that encrypts some fixed-size vector to produce ciphertext, which involves operations known as Single Instruction, Multiple Data (SIMD) operations, and a decryption operation that extracts data from the resulting ciphertext. An encryption scheme generally guarantees that any computation performed on the encrypted data produces the same result as applying the same computation to the underlying unencrypted data.

[0004] The unique properties of FHE are particularly useful when computations on personal or sensitive data must be outsourced to entities or locations that cannot guarantee its confidentiality. Such personal or sensitive data can first be encrypted using homomorphic encryption and then sent all encrypted for processing (e.g., to a commercial cloud environment). The result of the computation is returned, also in encrypted form, to the original sender, who can decrypt it in a secure environment to view the result. This procedure mitigates privacy and other confidentiality concerns, since unencrypted data is never made available to the entity performing the computation, and certainly not to malicious third parties seeking to compromise that entity's computer storage.

[0005] However, FHE is not without its limitations. In some encryption methods, such as the well-known CKKS (Cheon-Kim-Kim-Song) method, the calculations often introduce a certain amount of noise into the data, which increases as the number of successive operations increases. This leads to a certain deviation between the encrypted calculated data and the result that would have been obtained if the calculation had been performed on the original unencrypted data. After a sufficient number of successive operations, the noise can become so large that the result becomes completely unreliable.

[0006] Another limitation that sometimes occurs is data corruption. Some FHE schemes are known to have some limitations regarding the range of values ​​of unencrypted data that they can successfully handle. 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 incorrect. In this case, no error or warning is usually issued, since the data is encrypted and therefore the entity performing the calculation cannot decrypt it, nor can it be aware that such an overflow has occurred. It should be noted that the range of values ​​that can be correctly stored in the ciphertext depends on the FHE scheme and how it was 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 foregoing examples of the related art and their associated limitations are intended to be illustrative and not exhaustive. Other limitations of the related art will become apparent to those of ordinary skill in the art upon reading this specification and studying the drawings. Summary of the Invention

[0008] The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools, and methods that are intended to be exemplary and illustrative, and not limiting in scope.

[0009] One embodiment provides a computer-implemented method, in response to identifying that a Single Instruction, Multiple Data (SIMD) operation has been directed to be performed by or been performed on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software, automatically performing the following steps: (a) performing the same operations 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 resulting from the operations performed on the one or more original ciphertexts; (c) comparing the decrypted ciphertext to a plaintext resulting from the same operations performed on the one or more original plaintexts; and (d) based on said comparison, performing at least one of: (i) determining an amount of noise caused by the operations performed on the one or more original ciphertexts; (ii) determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operations performed on the one or more original ciphertexts; and (iii) determining correctness of an algorithm that includes the operations performed on the one or more original ciphertexts.

[0010] Another embodiment is directed to at least one hardware processor and a non-transitory computer readable storage medium having program code embodied thereon, the program code being adapted to be executed by the at least one hardware processor in Single Instruction, Multiple Instruction, and Multiple Instruction Mode. and a non-transitory computer-readable storage medium executable to automatically perform the following steps in response to identifying that a Simulated Interleaved Data (SIMD) operation has been directed to be performed by or has been performed on one or more original ciphertexts by Fully Homomorphic Encryption (FHE) software: (a) performing the same operations 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 resulting from the operations performed on the one or more original ciphertexts; (c) comparing the decrypted ciphertext to a plaintext resulting from the same operations performed on the one or more original plaintexts; and (d) based on the comparison, performing at least one of: (i) determining an amount of noise caused by the operations performed on the one or more original ciphertexts; (ii) determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operations performed on the one or more original ciphertexts; and (iii) determining correctness of an algorithm that includes the operations performed on the one or more original ciphertexts.

[0011] A further embodiment is a computer program product including a non-transitory computer readable storage medium having program code embodied therein, the program code being read by at least one hardware processor as Single Instruction, Multiple Instruction, or Multi-Instruction Program. In one embodiment, in response to identifying that a Fully Homomorphic Encryption (FHE) software has been directed to perform or has performed a Single Integer Multiplication and Deciphering (SIMD) operation on one or more original ciphertexts, the single integer multiplication and deciphering (SIMD) operation is executed to automatically perform the following steps: (a) performing the same operations 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 resulting from the operations performed on the one or more original ciphertexts; (c) comparing the decrypted ciphertext to a plaintext resulting from the same operations performed on the one or more original plaintexts; and (d) based on the comparison, performing at least one of: (i) determining an amount of noise caused by the operations performed on the one or more original ciphertexts; (ii) determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operations performed on the one or more original ciphertexts; and (iii) determining correctness of an algorithm that includes the operations performed on the one or more original ciphertexts.

[0012] In some embodiments, step (a) and step (b) are performed by the FHE software or another FHE software.

[0013] In some embodiments, the method is iterated over multiple SIMD operations, or the program code is executable to be iterated over multiple SIMD operations, where in each of the iterations, the one or more original ciphertexts are results of performing a SIMD operation on the one or more original ciphertexts of a prior iteration, and the one or more original plaintexts are results of performing the same operations on the one or more original plaintexts of the prior iteration.

[0014] In some embodiments the method further comprises, or the program code is further capable of: maintaining a log of the comparisons of step (c) of every iteration.

[0015] In some embodiments, the method or program code is implemented as an implementation of an abstract application programming interface (API) having a set of operators identical to the set of operators of the FHE software.

[0016] In some embodiments, the abstract API includes an abstract class programmed to interface with the FHE software to provide instructions to the FHE software to perform the decryption of step (b) and to receive the decrypted ciphertext from the FHE software.

[0017] In some embodiments, the abstract class is further programmed to identify that a SIMD operation is directed to be performed by the FHE software on one or more original ciphertexts, transparently pass any instructions from the user's algorithm intended for the FHE software to the FHE software, except for step (b) that is not performed by the FHE software, and perform the comparison of step (c).

[0018] In some embodiments of the method, this is performed by at least one hardware processor.

[0019] In addition to the exemplary aspects and embodiments described above, further aspects and embodiments will become apparent by study of the following detailed description and by reference to the figures. [Brief description of the drawings]

[0020] Exemplary embodiments are illustrated in the referenced drawings, in which dimensions of components and features shown are generally chosen for convenience and clarity of presentation and are not necessarily shown to scale.

[0021] [Figure 1] FIG. 1 is a block diagram of an exemplary system for analyzing and / or debugging FHE computational operations, according to one embodiment. [Diagram 2] 1 is a flowchart of a method for analyzing and / or debugging FHE computational operations, according to one embodiment. [Diagram 3] 3 is a flow chart illustrating one iteration of the method of FIG. 2 according to one embodiment. [Figure 4] 1 is a flowchart illustrating one iteration of a particular possible implementation, according to one embodiment. [Diagram 5] 1 is a flowchart illustrating one iteration of a particular possible implementation, according to one embodiment. [Figure 6] 1 is a flowchart illustrating one iteration of a particular possible implementation, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Disclosed herein are techniques, embodied in methods, systems, and computer program products, for analyzing and / or debugging computational operations performed on data within the framework of FHE. Analysis 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 the ciphertexts has been corrupted by operations performed on the ciphertexts, and determining the correctness of algorithms that include operations performed on the ciphertexts.

[0023] This technique is particularly useful during the development phase of an FHE application when devising computational algorithms (sequences of operations performed on encrypted data). For example, when developing an FHE application that performs neural network inference on encrypted data, developers could greatly benefit from being able to analyze and / or debug their algorithms before deploying them.

[0024] The technique may generally operate as follows: In response to being instructed by a particular FHE software to perform, or identifying that, a SIMD operation has been performed on one or more original ciphertexts, the following steps may be automatically performed in sequence: first, 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; second, decrypting the ciphertext resulting from the operations performed on the one or more original ciphertexts; third, comparing the decrypted ciphertext to the plaintext resulting from the same operations; and fourth, performing at least one of determining, based on the comparison, the amount of noise caused by the operations performed on the one or more original ciphertexts, determining whether unencrypted data underlying the one or more original ciphertexts was corrupted by the operations performed on the original ciphertexts, and determining the correctness of the algorithm including the operations performed on the one or more original ciphertexts ("debugging").

[0025] The technique is optionally implemented as an abstract application programming interface (API) to one or more standard FHE software libraries, such as the open source HElib library (S. Halevi and V. Shoup, "HElib - An Implementation of Homomorphic Encryption", available at https: / / github.com / shaih / HElib / , last accessed December 19, 2021), the open source SEAL library (Microsoft Research, "Microsoft SEAL", available at https: / / github.com / Microsoft / SEAL, last accessed December 19, 2021), the open source PALISADE library (available at https: / / palisade-crypto.org, last accessed December 19, 2021), etc. This abstract API provides the same functionality as the FHE libraries, but can be implemented such that every operation performed on one or more ciphertexts is also automatically performed on one or more plaintexts, respectively, such that noise and / or data corruption can be automatically tracked and subsequently reported to developers using the standard FHE software libraries.

[0026] Reference is now made to Figure 1, which illustrates a block diagram of an exemplary system 100 for analyzing and / or debugging FHE computational operations, according to one embodiment. System 100 may include one or more hardware processors 102, random access memory (RAM) 104, and one or more non-transitory computer-readable storage devices 106.

[0027] The storage device 106 may store program instructions and / or components configured to operate the hardware processor 102. The program instructions may include one or more software modules, such as an analysis / debugging module 108. The software components may include an operating system that controls and manages general system tasks (e.g., memory management, storage control, power management, etc.) and has various software components and / or drivers to facilitate communication between the various hardware and software components.

[0028] The system 100 can operate by loading instructions of an analysis / debugging module 108 into RAM 104 as they are executed by the processor 102. The instructions of the analysis / debugging module 108 can cause the system 100 to identify 110 that a SIMD operation has been directed to be or has been performed by the FHE software on one or more original ciphertexts 110, and in response, perform a series of automated actions to output one or more decisions 112, such as the amount of noise caused by the FHE operations, whether data corruption has occurred, and whether the computational algorithm (driving the SIMD operations) is correct.

[0029] The system 100 described herein is merely an exemplary embodiment of the invention and may in fact be implemented in hardware only, software only, or a combination of both hardware and software. System 100 may have more or fewer components and modules than shown, may combine two or more of the components, or may have different configurations or arrangements of components. System 100 may include any additional components (not shown) that enable it to function as an operational computer system, such as a motherboard, data bus, power supply, network interface card, display, input devices (e.g., keyboard, pointing device, touch display), etc. Moreover, the components of system 100 may be co-located 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] The operation of the analysis / debugging module 108 will now be discussed with reference to the flowchart of FIG. 2, which illustrates a method 200 for analyzing and / or debugging FHE computational 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), so long as the input required for a step can be obtained from the output of a previous step. In addition, the steps of method 200 are performed automatically (e.g., by system 100 of FIG. 1) unless otherwise noted.

[0032] Method 200 is optionally implemented using an implementation of an abstract API for one or more standard FHE software libraries, as further described below in the Example Implementations section.

[0033] In step 202, it can be automatically identified that a SIMD operation has been instructed to be performed or has been performed by the FHE software on one or more particular ciphertexts (referred to herein as "original ciphertexts"). The operation may be, for example, a multiplication or 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 (such as multiplying the ciphertext by a particular value or adding a particular value to the ciphertext) or may involve two (potentially more) ciphertexts on which an operation is performed (such as multiplying one ciphertext by another, adding two ciphertexts, etc.). Thus, in this disclosure, the terms "one or more (original) ciphertexts" or simply "(original) ciphertexts" are used to indicate these two possibilities. As a result, the terms "one or more (original) plaintexts" or more simply "(original) plaintexts" are used herein to indicate that the operation instructed to be performed on "one or more (original) ciphertexts" is also being performed on "one or more (original) plaintexts", respectively. In other words, each (original) ciphertext is associated with one (original) plaintext in a one-to-one relationship.

[0034] For SIMD operations, in response to this identifying, the following steps numbered 204 through 214 may be automatically performed:

[0035] The same operations directed to or performed on the one or more original ciphertexts in step 204 may also be performed on one or more plaintexts (referred to herein as the “original plaintext” or the “one or more original plaintexts”), each of which is a respective decrypted version of one of the original ciphertexts. The original plaintext may be available from a preliminary step (not shown) of obtaining or generating such plaintext and encrypting it using FHE software to generate the original ciphertext. The operations on the original plaintext may be performed using ordinary arithmetic operations (e.g., multiplication and / or addition) provided directly by, for example, system 100 of FIG. 1 or other computing device. Alternatively, the operations on the original plaintext may be performed using the same FHE scheme used in performing the operations on the original ciphertexts, either using the same FHE software or using different FHE software configured with the same associated FHE scheme.

[0036] In step 206, the ciphertext resulting from the operations performed on the original ciphertext can be decrypted using the associated FHE scheme, either by the same FHE software or by different FHE software, as described above.

[0037] The decrypted ciphertext can be compared to the plaintext resulting from the same operations performed on the original plaintext, step 208. Differences between the two identified in this step can then serve as an indication that the operations performed on the original ciphertext have introduced a certain amount of noise into the data underlying the original ciphertext, or that the underlying data has been completely corrupted.

[0038] Thus, based on the comparison of step 208, one or more of the following actions may be taken:

[0039] A first possible action, 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 is used to perform the operation, and the decrypted ciphertext contains the value 1.00001, and the plaintext resulting from the same operation has the value 1.00002, 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 be configured to immediately alert the user once it has been determined that the noise exceeds some predefined threshold. The threshold may refer to noise generated in a single operation or to noise accumulated over multiple operations. The alert may take the form of "throwing" an exception, as is known in the art of computer programming.

[0041] A second possible action, 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 be caused, for example, by the result of the operation exceeding the maximum range of values ​​acceptable for the ciphertext resulting at this point in the calculation. To determine whether the underlying data has been corrupted and to further distinguish this from noise, the difference found in step 208 may be compared to a predefined threshold. The threshold may be set to a sufficiently high value (absolute or percentage) to ensure that data corruption is not mistaken for noise. For example, the threshold may be set to a 10% difference between the decrypted ciphertext and the plaintext resulting from the same operation performed on the original plaintext. A suitable threshold may be, for example, in the range of 5-20%, the exact threshold being selectable by the user based on the type of calculation at hand.

[0042] In a variation of the second action, step 212 can also be configured to immediately warn the user if it is determined that the unencrypted data underlying the original ciphertext has been corrupted. The warning can be in the form of throwing an exception. Another possibility is to automatically change, or guide the user to change, (a) the settings of the FHE software or method to allow a wider range of values, or (b) the way the calculation is performed, or both.

[0043] A third possible action, described with reference to step 214, is to determine the correctness of the algorithm that contains the operation. This action is sometimes called "debugging" the algorithm. This may be performed automatically, such as by discovering which lines of the algorithm are the culprits of the differences resulting from step 208, or it may be performed manually by a developer who can understand, based on the differences, which parts of the algorithm may be in error.

[0044] It should be noted that method 200 can also operate by not performing any of steps 210-214, and instead simply providing as its final output the comparison result of step 208. In certain scenarios, such an automated comparison may in itself be valuable to a user (e.g., a developer) of method 200.

[0045] Method 200, as described above, is concerned with how an operation is identified and subsequently treated. Since most algorithms used to drive FHE computations include many such operations, it may be useful to iterate through the steps of method 200 for all computational operations and maintain a log 216 of the results of step 208 (comparison) and, optionally, the decisions made in one or more of steps 210-214, along with a description of each operation. In each iteration, at least one of the original ciphertexts is the ciphertext resulting from the execution of a SIMD operation in a prior iteration, and similarly, at least one of the original plaintexts is the plaintext resulting from the execution of the same operation in a prior iteration. In other words, each new iteration is accompanied by at least one (and possibly all) of the ciphertexts and plaintexts computed in the prior iteration (depending on what the user's algorithm dictates). This logging allows tracking of the evolution of the original ciphertext through the sequence of operations defined by the algorithm.

[0046] Once method 200 has completed iterations of all computational operations, the user can review the log and understand how noise, data corruption, or errors in the algorithm, or a combination thereof, have affected the original ciphertext with each subsequent operation, possibly with compounding effects.

[0047] Table 1 below illustrates this by showing a highly simplified log that illustrates how logging the iterations of method 200 can be useful to a user in determining and tracking noise evolution. The ciphertext values ​​listed in this table are, of course, shown in unencrypted, human readable form. Additionally, for simplicity, the example table is for 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 a multiplication by 4, just as with the associated original plaintext. This results in a correct result of 4 for the plaintext, but a slightly noisy (and computationally incorrect) result of 4.001 for the ciphertext. The absolute value of the difference is 0.001, which reflects 0.025% of the correct result. It should be noted that real noise in FHE schemes tends to start at smaller orders of magnitude than this simplified example.

[0050] The last two columns showing the differences could of course be represented by other means, such as by the quotient of the resulting ciphertext and plaintext values, by including only one of these columns in the log, etc. Thus, the format of the differences shown may be user configurable.

[0051] Intermediate reference is made to Fig. 3, which is a flow chart 300 illustrating one iteration of the method 200 represented by the first row of the table. At the start of the iteration, the ciphertext 302a and its associated plaintext 302b both have a starting value of 1. An operation involving a multiplication by 4 is then performed on these ciphertexts 302a and plaintexts 302b, resulting in a ciphertext 304a with a value of 4.001 and a plaintext with a value of 4. A comparison of the latter with each other illustrates the noise value of 0.001 accumulated in this iteration of the method 200.

[0052] Referring now back to Table 1, the second row of the table illustrates the second iteration of method 200. The underlying value of the ciphertext is 4.001 (the result of the ciphertext from the prior iteration). The operation performed on this ciphertext is now the addition of 1, as is the operation performed on the associated plaintext. In this case, the two results differ by 0.02%, but it is clear that the noise has not increased from the prior iteration and remains at 0.001. In other words, no noise is introduced by the addition operation.

[0053] In other scenarios, logging 216 may determine that a particular operation is not generating noise, even though the accumulated noise appears to have increased after that operation. For example, if the logged noise for five consecutive operations is: {0.00001, 0.00002, 0.00008, 0.0001, 0.001}, it is clear that the third operation is not generating noise because the log shows that it is a multiplication by 4. Rather, due to the nature of multiplication operations, the noise is four times as large as expected because the second operation exactly multiplied the noise by four. Exemplary Implementations (Implementation form 1)

[0054] As briefly mentioned above, method 200 may optionally be implemented using an abstract API (in an object-oriented programming language) to one or more standard FHE software libraries. For this purpose, an abstract class may be provided that has the same interface as the standard FHE software library. That is, it provides the same set of operators, such as encryption, decryption, multiplication, addition, etc., that are present in the standard FHE software library. A concrete implementation of this API may delegate calls to a specific FHE library, and multiple such concrete implementations may be created for multiple different FHE libraries. An embodiment of the present invention may be implemented as yet another concrete implementation of this API, whereby each operation is performed on one or more ciphertexts, and also on one or more individual plaintexts, by delegating calls to the FHE library, as specified by method 200.

[0055] The implementation of method 200 as an implementation of such an abstract API allows a user to analyze and / or debug FHE computational operations by indirectly manipulating the underlying standard FHE software library via the abstract API. In other words, the user's algorithm can contain instructions that act on the same operators (e.g., functions, methods, classes, etc.) as those in the library (with which the user is familiar), and the abstract class performs the steps of method 200 transparently, without the user's knowledge, by instructing the library (and receiving its results) or by executing code in the abstract class itself.

[0056] With reference 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 a specific implementation. Rather, in response to the user's algorithm providing instructions to perform such operations on the original ciphertext (e.g., instructions intended for the underlying FHE software library, as is evident from its syntax), the abstract class essentially passes the instructions to the library (step 202) and also utilizes its own program code to perform the same operations on the original plaintext (step 204) or sends instructions to the library (or to another library using the same FHE scheme) to accomplish step 204. For each of steps 202 and 204, the abstract class's code is of course also configured to receive the results of its computations from the associated library. Then, to perform step 206, the abstract class can send instructions to the library (or, as before, to another library using the same FHE scheme) to decrypt the ciphertext resulting from the operations performed on the original ciphertext and receive the decrypted ciphertext. Next, in step 208, the abstract class itself may include program code to perform a comparison between the decrypted ciphertext and the plaintext obtained from step 204, as well as code to perform one or more of steps 210-214. (Implementation form 2)

[0057] The second implementation may be similar to the first, but with the key difference that it does not operate on ciphertext, but only on plaintext: that is, the underlying standard FHE software libraries do not need to be available for any task, but rather it can perform actions only on plaintext without the help of the FHE software (e.g., using the computer's standard arithmetic functions).

[0058] Referring to method 200, step 204 is also performed in response to detecting that SIMD operations are directed 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 directed to do so by the user's algorithm), and only one or more plaintexts are actually available when method 200 begins. Thus, even though the user directs SIMD operations on what they think are ciphertexts, the operations are actually performed on plaintexts (the user's original unencrypted data). As a result, steps 206 onward can be omitted, except for performing a variant of step 214 that can determine the correctness of the algorithm.

[0059] This implementation is particularly useful for debugging purposes, i.e., for determining the correctness of a user's algorithm (as per step 214), but may not be suitable for these purposes since noise and data corruption are not expected to occur when performing computational operations on plain text.

[0060] A particular advantage of this implementation is its speed: by omitting encryption and decryption operations and not performing any 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 implementation, but the key difference is that each operation is performed on one or more tuples, each containing two ciphertexts c1, c2 and two plaintexts p1, p2. Before each operation, for each such tuple, c1 is decrypted and the result is copied to p1. Additionally, p2 is encrypted and the result is copied to c2. This allows the user to distinguish between noise caused by a particular operation and noise accumulated by multiple previous operations.

[0062] Reference is now made to Figure 4, which is a flow chart 400 illustrating one iteration according to the present implementation. This is the iteration described, for example, in the second row of Table 1, and therefore pertains to the simple case where only a single original ciphertext is operated on, in this case a single tuple of c1, c2, p1, and p2.

[0063] In flow chart 400, blocks 402a and 402d are essentially the same as blocks 302a and 302b, respectively, of Figure 3, except that their values ​​are different. Similarly, blocks 404a and 404d are essentially the same as blocks 304a and 304b, respectively, of Figure 3, except that their values ​​are different. Thus, in Figure 4, blocks 402b and 402c with pre-operation values ​​and blocks 404b and 404c with post-operation values ​​have been added.

[0064] This implementation can work as follows: First, from block 402a, it can be seen that a noise value of 0.001 has already been accumulated as a result of one or more previous iterations (e.g., the iteration in the first row of Table 1). Before performing the computational operations of the illustrated operation, two actions can be taken: one is to copy the underlying value of the ciphertext of block 402a (=4.001), which is the result of the previous operation performed on the ciphertext, to the plaintext (block 402b); the other is to copy the value of the plaintext of block 402d (=4), which is the result of the previous operation performed on the plaintext, to the ciphertext (block 402c).

[0065] Then, for all four blocks 402a to 402d, the operation of the relevant iteration (in this case the addition of 1) has been performed.

[0066] The result of this operation is the underlying ciphertext value 5.001 in both blocks 404a and 404b, and the plaintext value 5 in both blocks 404c and 404d.

[0067] Next, comparing the difference between blocks 404a and 404b, blocks 404c and 404d, and finally 404a and 404d, it is clear that the accumulated noise after this operation is 0.001, but this is not the result of the current iteration, but rather one of the prior iterations, since the difference between blocks 404a and 404b, and the difference 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 prior to this iteration.

[0068] Reference is now made to Figure 5. Figure 5 is a flow chart 500 similar to that in Figure 4, but showing different numerical examples that lead to different conclusions about the source of the noise. Similar elements in Figures 4 and 5 are numbered the same, except that the numbers in Figure 5 are in single quotes.

[0069] In the flow chart 500, it can be seen that the initial noise is 0.001, similar to FIG. 4. This is evident from the difference between blocks '402a and '402d. After the above-mentioned copying of blocks '402a-d, a certain operation is performed on all these four blocks, such as multiplication by 10. 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 is responsible for adding 0.1 noise, compared to just 0.001 noise accumulated prior to this iteration. Given this determination regarding the noise, the user may be guided by the method 200 to modify the algorithm such that the noise caused by the current operation is reduced, as it is much more significant (by two orders of magnitude) than the noise accumulation prior to it.

[0070] Reference is now made to Figure 6, which shows a flowchart 600 similar to those of Figures 4 and 5, but illustrating yet another numerical example that leads to a different conclusion about the source of the noise. Similar elements in Figures 4, 5 and 6 are numbered the same, except that the numbers in Figure 6 are appended with double quotes.

[0071] In flow chart 600, it can be seen 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-d as described above, a certain operation, such as multiplication by 2, is performed on all four of these blocks. As a result, the difference between blocks 404a and 404b is 0.1, but there is no difference between blocks 404c and 404d, indicating that the operation of the current iteration operates correctly on already accurate (non-noisy) input values ​​(block 402d) and adds noise to inaccurate (noisy) input values ​​(block 402a). A possible explanation for this phenomenon is that the certain operation performed in this iteration has poor performance for a certain range of real numbers. Given this determination regarding noise, the user may be guided by method 200 to either modify his algorithm so that an alternative, less problematic operation is used, for example an operation that operates correctly over a wider range of numbers, or to address only the symptoms of this problem by reducing the accumulation of noise prior to this iteration and thus limiting significant noise jumps due to this particular operation.

[0072] The present invention may be a system, method, and / or computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0073] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list 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 disk (DVD), memory stick, floppy disk, mechanically encoded device having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires. Instead, computer-readable storage media are non-transitory (i.e., non-volatile) media.

[0074] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to an individual computing / processing device or to an external computer or storage device over 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 fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the individual computing / processing device.

[0075] The computer readable program instructions for carrying out the operations of the present invention may be either source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or object-oriented programming languages ​​such as Java®, Smalltalk®, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer as a standalone software package, partly on the user's computer and partly on a remote computer, or all on a remote computer or 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 wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to individualize the electronic circuitry to implement aspects of the present invention. In some embodiments, electronic circuitry including, for example, an application specific integrated circuit (ASIC) can already incorporate computer readable program instructions at the time of manufacture such that the ASIC is configured to execute these instructions without programming.

[0076] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0077] These computer readable program instructions may be provided to a general purpose computer, special purpose computer, or other programmable data processing device processor to produce a machine, such that the instructions, which execute on the processor of the computer, or other programmable data processing device processor, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable storage medium such that the computer readable storage medium having stored thereon an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, capable of directing a computer, programmable data processing device, or other device, or combination thereof, to function in a particular manner.

[0078] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operable steps to create a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0079] The flowcharts and block diagrams in the figures 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 of the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, are implemented by a special-purpose hardware-based system that performs the specified functions or actions or executes a combination of special-purpose hardware and computer instructions.

[0080] In this specification and claims, the terms "substantially," "essentially," and each of its variants, when describing a numerical value, mean up to a 20% deviation from that value (i.e., ±20%). Similarly, when such terms describe a numerical range, they mean up to a 20% broader range (10% above and 10% below the stated range).

[0081] In this specification, any numerical range should be considered as specifically specifying all possible subranges as well as each individual numerical value within the range, and each such subrange and individual numerical value constitutes an embodiment of the present invention. This applies regardless of the breadth of the range. For example, a description of an integer range of 1 to 6 should be considered as having each individual number within the range, e.g., 1, 4, and 6, as well as the specifically specified subranges, such as 1 to 3, 1 to 4, 1 to 5, 2 to 4, 2 to 6, 3 to 6, etc. Similarly, a description of a fractional range, e.g., 0.6 to 1.1, should be considered as having each individual number within the range, e.g., 0.7, 1, and 1.1, as well as the specifically specified 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, etc.

[0082] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the explicit description. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to allow other 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 forms of words thereof, do not necessarily limit the members of the list with which the word is associated.

[0084] In the event of a conflict between this specification and a document incorporated by reference or otherwise relied upon, the present specification is intended to control.

Claims

1. 1. A computer-implemented method, comprising: automatically in response to identifying that a single instruction, multiple data (SIMD) operation is instructed to be performed, or has been performed, by fully homomorphic encryption (FHE) software on one or more original ciphertexts. (a) performing the same operations on one or more original plaintexts, each of which is a decrypted version of one of said one or more original ciphertexts; (b) decrypting a ciphertext resulting from said operations performed on said one or more original ciphertexts; (c) comparing the decrypted ciphertext with a plaintext resulting from the same operations performed on the one or more original plaintexts; (d) based on said comparison, determining an amount of noise caused by the operations performed on the one or more original ciphertexts; determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation performed on the one or more original ciphertexts; and and determining correctness of an algorithm that includes the operation performed on the one or more original ciphertexts.

2. 2. The computer-implemented method of claim 1, wherein steps (a) and (b) are performed by the FHE software or another FHE software.

3. The method is repeated over a number of SIMD operations; In each of said iterations: the one or more original ciphertexts are a result of performing the SIMD operations on the one or more original ciphertexts of a prior iteration; The computer-implemented method of claim 1 , wherein the one or more original plaintexts are a result of performing the same operation on the one or more original plaintexts of the prior iteration.

4. 4. The computer-implemented method of claim 3, further comprising maintaining a log of the comparisons of step (c) for all said iterations.

5. 2. The computer-implemented method of claim 1, implemented as an implementation of an abstract application programming interface (API) having a set of operators identical to a set of operators of the FHE software.

6. The abstract API, providing instructions to said FHE software to perform said decryption of step (b); and receiving the decrypted ciphertext from the FHE software.

7. The abstract class: identifying the SIMD operations directed to be performed by the FHE software on the one or more original ciphertexts; transparently passing to said FHE software any instructions from a user's algorithm intended for said FHE software, except for step (b) which is not executed by said FHE software; 7. The computer-implemented method of claim 6, further programmed to: perform the comparing of step (c).

8. The computer-implemented method of claim 1 , wherein the method is performed by at least one hardware processor.

9. 1. A system comprising: at least one hardware processor; A non-transitory computer readable storage medium having program code embodied therein, the program code being executed by the at least one hardware processor. automatically in response to identifying that a single instruction, multiple data (SIMD) operation is instructed to be performed, or has been performed, by fully homomorphic encryption (FHE) software on one or more original ciphertexts. (a) performing the same operations on one or more original plaintexts, each of which is a decrypted version of one of said one or more original ciphertexts; (b) decrypting a ciphertext resulting from said operations performed on said one or more original ciphertexts; (c) comparing the decrypted ciphertext with a plaintext resulting from the same operations performed on the one or more original plaintexts; (d) based on said comparison, determining an amount of noise caused by the operations performed on the one or more original ciphertexts; determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation performed on the one or more original ciphertexts; and and determining correctness of an algorithm that includes the operation performed on the one or more original ciphertexts.

10. 10. The system of claim 9, wherein steps (a) and (b) are performed by the FHE software or another FHE software.

11. the program code being executable to iterate over a number of SIMD operations; In each of said iterations: the one or more original ciphertexts are a result of performing the SIMD operations on the one or more original ciphertexts of a prior iteration; The system of claim 9 , wherein the one or more original plaintexts are a result of performing the same operation on the one or more original plaintexts of the prior iteration.

12. The program code comprises: The system of claim 11 , further operable to maintain a log of the comparisons of step (c) for all said iterations.

13. 10. The system of claim 9, wherein the program code is implemented as an implementation of an abstract application programming interface (API) having a set of operators identical to a set of operators of the FHE software.

14. The abstract API, providing instructions to said FHE software to perform said decryption of step (b); and receiving the decrypted ciphertext from the FHE software.

15. The abstract class is identifying the SIMD operations directed to be performed by the FHE software on the one or more original ciphertexts; transparently passing to said FHE software any instructions from a user's algorithm intended for said FHE software, except for step (b) which is not executed by said FHE software; 15. The system of claim 14, further programmed to: perform the comparing of step (c).

16. A computer program product comprising a non-transitory computer readable storage medium having program code embodied therein, said program code being executed by at least one hardware processor. automatically in response to identifying that a single instruction, multiple data (SIMD) operation is instructed to be performed, or has been performed, by fully homomorphic encryption (FHE) software on one or more original ciphertexts. (a) performing the same operations on one or more original plaintexts, each of which is a decrypted version of one of said one or more original ciphertexts; (b) decrypting a ciphertext resulting from said operations performed on said one or more original ciphertexts; (c) comparing the decrypted ciphertext with a plaintext resulting from the same operations performed on the one or more original plaintexts; (d) based on said comparison, determining an amount of noise caused by the operations performed on the one or more original ciphertexts; determining whether unencrypted data underlying the one or more original ciphertexts has been corrupted by the operation performed on the one or more original ciphertexts; and and determining correctness of an algorithm that includes the operation performed on the one or more original ciphertexts.

17. the program code being executable to iterate over a number of SIMD operations; In each of said iterations: the one or more original ciphertexts are a result of performing the SIMD operations on the one or more original ciphertexts of a prior iteration; the one or more original plaintexts are a result of performing the same operation on the one or more original plaintexts of the prior iteration; 17. The computer program product of claim 16, wherein the program code is further executable to maintain a log of the comparisons of step (c) of all the iterations.

18. 17. The computer program product of claim 16, wherein the program code is implemented as an implementation of an abstract application programming interface (API) having a set of operators identical to a set of operators of the FHE software.

19. The abstract API, providing instructions to said FHE software to perform said decryption of step (b); and receiving the decrypted ciphertext from the FHE software.

20. The abstract class: identifying the SIMD operations directed to be performed by the FHE software on the one or more original ciphertexts; transparently passing to said FHE software any instructions from a user's algorithm intended for said FHE software, except for step (b) which is not executed by said FHE software; 20. The computer program product of claim 19, further programmed to: perform the comparing of step (c).

Images