Table of Contents Author Guidelines Submit a Manuscript
Security and Communication Networks
Volume 2018, Article ID 2363928, 14 pages
Research Article

Privacy-Preserving Oriented Floating-Point Number Fully Homomorphic Encryption Scheme

1College of Computer Science, Nanjing University of Posts and Telecommunication, Nanjing 210003, China
2Key Laboratory of Broadband Wireless Communication & Sensor Networks Technology of Ministry of Education, Nanjing University of Posts and Telecommunications, Nanjing 210003, China
3Jiangsu Key Laboratory of Big Data Security & Intelligent Processing, Nanjing, Jiangsu 210023, China

Correspondence should be addressed to Geng Yang; nc.ude.tpujn@ggnay

Received 29 January 2018; Revised 19 May 2018; Accepted 5 June 2018; Published 24 July 2018

Academic Editor: Roberto Di Pietro

Copyright © 2018 Shuangjie Bai et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.


The issue of the privacy-preserving of information has become more prominent, especially regarding the privacy-preserving problem in a cloud environment. Homomorphic encryption can be operated directly on the ciphertext; this encryption provides a new method for privacy-preserving. However, we face a challenge in understanding how to construct a practical fully homomorphic encryption on non-integer data types. This paper proposes a revised floating-point fully homomorphic encryption scheme (FFHE) that achieves the goal of floating-point numbers operation without privacy leakage to unauthorized parties. We encrypt a matrix of plaintext bits as a single ciphertext to reduce the ciphertext expansion ratio and reduce the public key size by encrypting with a quadratic form in three types of public key elements and pseudo-random number generators. Additionally, we make the FFHE scheme more applicable by generalizing the homomorphism of addition and multiplication of floating-point numbers to analytic functions using the Taylor formula. We prove that the FFHE scheme for ciphertext operation may limit an additional loss of accuracy. Specifically, the precision of the ciphertext operation’s result is similar to unencrypted floating-point number computation. Compared to other schemes, our FFHE scheme is more practical for privacy-preserving in the cloud environment with its low ciphertext expansion ratio and public key size, supporting multiple operation types and high precision.

1. Introduction

In this age of big data, the amount of data that identifies individuals is increasing. People are enjoying the convenience created by these data; at the same time, leakage of personal data has attracted more attention because these data are easily accessible to third parties, especially in a cloud environment, and because the service provider can easily access users’ plaintexts in a cloud server. Additionally, the security and privacy of personal data are threatened as we adopt cloud computing services; this threat is considered the biggest challenge in a cloud environment [1]. To avoid the data being leaked, people usually adopt an encryption algorithm such as AES to encrypt these data and store them on a cloud server. However, AES cannot support the operations over ciphertexts directly on the cloud server. When people need to use these data, they must download ciphertexts from the server and decrypt locally. Such downloads require a large consumption of resources. Only immense storage space in the cloud is used while the availability of ciphertexts is lost. Therefore, people have been seeking a scheme that can utilize the advantages of the cloud, including immense storage space and strong computing power, which can effectively protect the privacy of an individual at the same time. Homomorphic encryption is closely related to the confidentiality of data in the cloud and is the key technology to protect data privacy.

Homomorphic encryption allows third parties to operate over encrypted values without being aware of the content. The idea of homomorphic encryption is as follows. Enc represents the encryption algorithm, and Dec represents the decryption algorithm. For a function taking plaintexts as inputs, there exists a function taking the corresponding ciphertexts as inputs, where , such thatAccording to the property of homomorphic encryption above, to protect a user’s privacy in a cloud environment seems to be an excellent method. We can take advantage of the strong computing power in the cloud to operate over the ciphertexts without exposing the plaintexts. There are some applications such as CryptDB [7, 8] and other encrypted databases [9, 10], which apply a homomorphic encryption scheme to protect data privacy.

The present homomorphic encryption schemes have some limitations. Most practical systems apply a partially homomorphic encryption scheme (certain restricted types of computations can be done on ciphertexts), such as Paillier [11], rather than a fully homomorphic encryption scheme. The current fully homomorphic encryption scheme is inefficient. There are also many studies on improving the efficiency of fully homomorphic encryption schemes [35, 12, 13], but these schemes cannot be applied to a practical system. Furthermore, most current homomorphic encryption schemes only operate over the integer data type, while most data are not only integers. For example, in the e-healthcare cloud service [14], decision-making models can be used to automatically check a patient’s health status, and the parameters of the decision-making model contain real numbers. Additionally, we often need a mathematic modeling method to analyze a patient’s health data, which may utilize complex functions taking floating-point numbers as input. However, most existing homomorphic encryption schemes [2, 11, 1518] only focus on operations on integers. Designing a homomorphic encryption scheme to achieve floating-point number calculation without compromising the privacy of the outsourced data is a challenging issue.

In this paper, we propose a floating-point fully homomorphic encryption scheme (FFHE) to overcome the above problems. The scheme is based on our proposed revised somewhat homomorphic encryption scheme (RSHE), which is more effective than [35]. Although FFHE is not appropriate for practical application to a system, we have improved the efficiency. By using five integers to express a floating-point number [19], we convert the operations on a floating-point number to an integer. FFHE can support addition and multiplication operations on floating-point numbers. We then prove that the operation on ciphertexts of a floating-point number does not increase additional precision loss. Using the Taylor series approximation calculation, our scheme can also calculate the result of analysis functions, such as exponential and logistic functions taking floating-point numbers as input without exposing plaintexts.

Our FFHE is more efficient than previous works. It is based on Gentry’s original blueprint and supports a more complex function with more diversified input data types. The main contributions of this paper can be summarized as follows.

(i) We construct a more efficient and somewhat homomorphic encryption scheme with a smaller public key size and a secret key size based on [2], which is more effective than Coron’s scheme [35].

(ii) We follow Gentry’s blueprint and construct a floating-point fully homomorphic encryption scheme (FFHE) that can support addition and multiplication operations on floating-point numbers based on our proposed revised somewhat homomorphic encryption (RSHE). Compared to the operation of plaintexts, addition and multiplication of ciphertexts do not increase additional precision loss.

(iii) FFHE can calculate the result of analysis functions taking floating-point numbers as input without exposing plaintexts, and the error of approximate calculation is negligible.

The remainder of this paper is organized as follows: related work is discussed in Section 2. In Section 3, we describe some preliminaries required for understanding of our proposed revised somewhat homomorphic encryption scheme and FFHE, as well as some prior knowledge about floating-point numbers. In Section 4, we review the DGHV scheme. Then, we present the revised somewhat homomorphic encryption scheme in Section 5, followed by our proposed FFHE in Section 6. In Section 7, we explain the type of operations of FFHE. Section 8 concludes this paper.

2. Related Work

In this section, we informally review previous homomorphic encryption schemes. In 1978, Rivest et al. proposed the idea of privacy homomorphism [20]: workers may perform implicit addition and multiplication on plaintext values while exclusively manipulating encrypted data. Homomorphic encryption has attracted significant research attention lately. There are many studies on homomorphic encryption, including a somewhat homomorphic encryption scheme (a crucial component of fully homomorphic encryption which allows many additions and a small number of multiplications on ciphertexts) and a partially homomorphic encryption scheme. For example, RSA [15] is a multiplicatively homomorphic encryption scheme, and Paillier cryptosystem [11] is an additively homomorphic encryption scheme.

However, partially or somewhat homomorphic encryption schemes cannot meet the requirements of processing vast privacy data. In a 2009 breakthrough work, Gentry constructed the first encryption scheme based on ideal lattices that support both addition and multiplication on ciphertexts, i.e., a fully homomorphic encryption scheme [16], and detailed the proposed scheme in his Ph.D. thesis [17], which led to the research on fully homomorphic encryption.

Based on Gentry’s research, three types of schemes were constructed.

(1) Gentry’s original scheme was based on ideal lattices. The construction follows successive steps: first, construct a somewhat homomorphic scheme that supports limited addition and multiplication on ciphertexts. This step is necessary because ciphertexts contain some noise that becomes larger with successive homomorphic multiplication, and only ciphertexts whose noise size remains below a certain threshold can be decrypted correctly. Second, Gentry shows how to squash the decryption procedure so that it can be expressed as a low degree polynomial in the bits of the ciphertext and the secret key. Then, Gentry’s key idea, called bootstrapping, consists in homomorphically evaluating this decryption polynomial on encryptions of the secret key bits, resulting in a different ciphertext (refreshed ciphertext) associated with the same plaintext with possibly reduced noise. The refreshed ciphertext can then be used in subsequent homomorphic operations. By repeatedly refreshing ciphertexts after every operation, the number of homomorphic operations becomes unlimited, resulting in a fully homomorphic encryption scheme. Gentry and Halevi implemented Gentry’s scheme [21] based on algorithmic optimizations proposed by Smart et al. [12].

(2) In 2012, Brakerski et al. proposed a fully homomorphic encryption scheme (BGV scheme) based on Learning with Errors (LWE) and Ring Learning with Errors (RLWE) problems [18], which was a new way of constructing a leveled fully homomorphic encryption scheme (capable of evaluating arbitrary polynomial-size circuits), without Gentry’s bootstrapping procedure. They proposed modulus-switching and key switching techniques to reduce noise and the ciphertext expansion ratio. An implementation was described with an efficient homomorphic evaluation of a full AES encryption circuit. At the same time, this branch also drew significant attention, and they proposed a revised scheme based on LWE [13, 2225].

(3) At Eurocrypt 2010, Dijk, Gentry, Halevi, and Vaikuntanathan (DGHV scheme) described a fully homomorphic encryption scheme over the integers [2]. The main appeal of the scheme (compared to Gentry’s original scheme) was its conceptual simplicity; all operations are done over the integers instead of ideal lattices. However, the public key was too large for any practical system. Because of that, Coron et al. [35] proposed several optimization techniques to reduce public key size. Homomorphic encryption scheme can also be applied in provable data possession [2629].

The schemes above address operation over integers, while there are few studies of fully homomorphic encryption schemes for non-integers. Real numbers are the most common numbers used in measuring. Recently, there have been papers focusing on designing a fully homomorphic encryption scheme for real numbers. Seiko, Arita, and Shota Nakasato [30] proposed a fully homomorphic encryption for point numbers based on the FV [31] scheme, which is based on the LWE problem. They construct a first homomorphic encryption scheme that supports operations for fixed-point numbers. Based on this, they constructed a fully homomorphic encryption scheme that can homomorphically compute addition and multiplication of encrypted floating-point numbers. Cheon et al. [32] proposed a floating-point homomorphic encryption scheme based on the BGV scheme [18], which was able to evaluate arbitrary polynomial-size circuits, similar to the BGV scheme. Costache [33] proposed a fixed-point arithmetic in a somewhat homomorphic encryption scheme and investigated an application in homomorphic image processing. However, these papers just identified the feasibility of constructing a homomorphic encryption scheme supporting operations over floating-point numbers. These schemes cannot secretly calculate complex functions with floating-point numbers as input. Additionally, because of the low efficiency of basic schemes over integer, their proposed schemes for non-integers also require a large key space and ciphertext space. Liu [34] realized outsourced calculation on floating-point numbers. They utilized Paillier-based cryptosystem to construct operation protocol over the ciphertexts. However, Paillier is only an additively homomorphic scheme, and they construct a multiplicatively homomorphic scheme by setting up two severs, which requires a higher security model.

Low efficiency, large public key size, and ciphertext expansion ratio are the main reasons for which most fully homomorphic encryption schemes are not practical, and this problem receives the most attention. However, there are some studies on floating-point number homomorphic encryption, and the supported arithmetic types have many limitations; for example, most analytic functions such as exponential functions and logarithmic functions for floating-point numbers cannot be supported. Therefore, it is necessary to construct a fully homomorphic encryption scheme for floating-point numbers.

3. Preliminary

3.1. Notations

For a real number , we denote using , , and rounded up, down, or to the nearest integer. For a real number , and an integer , we denote the reduction of modulo by with , or with . Let be a real number. We use the notation to represent the floating-point value of (the nearest number in the floating-point system). The most useful measures of the accuracy of are its absolute error and its relative error [19].

The parameters of the somewhat homomorphic DGHV scheme are shown in Section 4. Given the security parameter , the following parameters are used:  is the bit-length of the public keys.  is the bit-length of the secret keys.  is the bit-length of the first noise parameter.  is the number of the public keys.’ is the bit-length of the secondary noise parameter.

The other parameters used in our proposed schemes will be described in Sections 5 and 6.

3.2. Floating-Point Number

The floating-point number is the formulaic representation that approximates a real number to support a trade-off between range and precision. We define the floating-point format used in this paper. A floating-point format is characterized by five integers [19]:where is the sign of . is the base or radix (b=2 in this paper). is an integer such that , called the exponent of the , where and are two extremal exponents such that . is the precision (the number of significant digits in the significand), and is the significand satisfying . To determine accuracy, we define the quantity . It is the furthest distance relative to unity between a real number and the nearest floating-point number. According to the definition of the relative error above, we represent the relative error as such that . According to different demands in a practical system, we may adjust the parameters in the floating-point format we defined above.

3.3. Floating-Point Error Analysis

For real numbers , , , represent the floating-point value of , , which is the nearest number in the floating-point system. For , , where , represent the absolute error of the real number and the floating-point number, which are subject to , , and the relative error is as follows:

The addition of the two real numbers can be represented as , such thatThe addition of floating-point number does not affect the relative error, and the precision is still .

The multiplication of the two real numbers can be represented as such thatFor each multiplication, the relative error approximately doubles. Specifically, the relative error will increase with continuous multiplications [19]. The FFHE we propose below simulates the operations of plaintext in the floating-point system with a Boolean circuit. We prove the relative error of ciphertext is the same as corresponding plaintext in our FFHE.

4. The Somewhat Homomorphic DGHV Scheme

In this section, we recall the somewhat homomorphic encryption scheme over the integers of van Dijk, Gentry, Halevi, and Vaikuntanathan (DGHV) [2]. The notation used in the DGHV scheme is the same as in Section 3.1.

For a specific -bit odd integer p, we use the following distribution over -bit integers:

DGHV.KenGen. Generate an -bit random prime integer so that . For , sample . Relabel the so that is the largest. Restart unless is odd and is even. Let and .

DGHV.Encrypt(pk,  ). Choose a random subset and a random integer r in , and output the ciphertext: .

DGHV.Evaluatepk, , , , , . Given the circuit with input bits and ciphertexts , apply the addition and multiplication gates of to the ciphertexts, performing all the addition and multiplications over the integers, and return the resulting integer.

DGHV.Decryptsk, . Output .

This completes the description of the scheme as shown in [2], and the scheme is a somewhat homomorphic scheme and it is semantically secure under the approximate-GCD assumption, which is proven in [2].

Definition 1 (approximate GCD). The problem is as follows: given a random -bit odd integer p and given many polynomial samples from , in outputting p.

According to the scheme parameter constraints, the following parameters are suggested: , , , and . The public key size is , which is too large for a practical system.

5. Revised Somewhat Homomorphic Encryption Scheme (RSHE)

In this section, we propose our revised somewhat homomorphic encryption scheme (RSHE) with a smaller public key size and ciphertext expansion ratio. As described in Section 4, the public key size of DGHV is , which is too large for a practical system. References [35] proposed some variants of the DGHV scheme. However, our RSHE is more efficient than these schemes, and the detailed performance comparison of our RSHE with these schemes is shown in Section 5.2.

As in the extension in [3], we extend the DGHV scheme for a batch setting. Instead of packing the plaintext vector , we packed plaintext matrix with elements into a single ciphertext, where . Instead of working with integer of the form as in [21], we compressed all of the public keys used in RSHE in the same way, that is , for where , and for where . Then, only integers need to be stored in the public key to generate integers used for encryption in [3]. We considered a linear combination of the with coefficients in , and a linear combination of the in to further reduce the public key size. The detailed description of RSHE is as follows.

5.1. Description

KeyGen: Choose -bit distinct primes , and denote as their product, that is . Define the error-free public key element , where is a -rough integer. Initialize two pseudo-random number generators f1, f2, with two random seeds se1, se2 (the two pseudo-random number generator functions are independent of each other). Use and to generate a set of integers , , , let , compute the first set of public keys:where and . For all and , compute . For noise parameters , , , , compute the second set of public keys:For noise parameters , compute the third set of public keys:We name as the extended Kronecker function as follows (the definition of the Kronecker function is shown in [3]):and using the compression technique used for the first set of public keys, we can also compress , let , and compute .

Let , .

Enc (pk,): Generate random integer matrix , . Output the ciphertext:

Dec , : Output plaintext matrix :

Evaluate pk, C, , …, : as in the original DGHV scheme.

Add pk, , : Output:

Mult pk, , : Output:

5.2. Parameter Analysis

For the security parameters , we have the following constraints on our scheme parameters:

: to avoid a brute force attack on the noise, and the value is larger than that in [5] to be secure against an attack proposed in [35].

: for thwarting lattice-based attacks against the approximate GCD problem [2].

: for supporting homomorphic operations for evaluating the squashed decryption circuit [2].

: for correct decryption of a ciphertext (Section 5.3).

To satisfy the above constraints, we can take , , , , , , , . As the ciphertexts are preserved in the form of a matrix, let , the ciphertext expansion ratio is , the new secret key size is , as in [3]. However, compared to the ciphertext expansion ratio in [2], our scheme has been greatly improved. The new public key for our revised somewhat homomorphic scheme has a size instead of as in [3] and as in [4]. Though the public key size in [5] is , the ciphertext expansion rate is much larger than that in our paper. We prefer a slightly larger public key size for a smaller ciphertext expansion rate. Compared to a public key, ciphertexts require more storage. Additionally, [6] declares the public key size of their scheme as ; however, the value of the public key in the scheme does not meet the constraints proposed in [2], and it is vulnerable to lattice-based attacks. To satisfy the constraints, the size of public key is , and the actual public key size is at least . Therefore, our proposed scheme is better in terms of public key size and ciphertext expansion rate.

We also perform computational complexity analysis between these schemes. The computational complexity of [2] is and the computational complexity of [4] is . Furthermore, the computational complexity of [3, 5] is all . Our scheme’s computational complexity is . We have not increased the computational complexity under the premise of reducing the space complexity.

A comprehensive comparison of space complexity and computational complexity between the above schemes is shown in Table 1.

Table 1: Performance comparison of somewhat homomorphic encryption scheme.
5.3. Correctness

First, define the permitted circuits as follows.

Definition 2 (permitted circuit). For any , and any set of integer inputs all less than in absolute value, it holds that the generalized circuit’s output has an absolute value not exceeding , where . Let denote the set of permitted circuits.

According to the above scheme, encrypt the plaintext matrix m1, ⋯, mt, and the ciphertext vector generate, where . Let be a circuit with inputs and an output. We can decrypt properly, if

Lemma 3. Our somewhat homomorphic encryption scheme is correct for .

Proof. The ciphertext of our scheme is as follows:For , we have:Let be a Boolean circuit with input , and let be the associated integer circuit where Boolean gates are replaced with integer operations with ciphertexts of plaintext for input. For , we haveAccording to the Definition 2,soThen,AndThen, our scheme is correct for the permitted circuit .

In the scheme, addition results in a linear increase of noise, while multiplication results in an exponential increase of noise; therefore, multiplication is dominant in increasing noise. According to Definition 2, ciphertext outputs have noise not exceeding ; after multiplication, the new noise does not exceed ; let d be the degree. Let be the multivariate polynomial computed by , and let be the norm of the coefficient vector of . Then, provided that , then,As in [5], we refer to polynomials as permitted polynomials and denote the set of these polynomials by .

5.4. Semantic Security

Our scheme is semantically secure under a new assumption called the error-free--approximate GCD assumption. Given integers , we define the following oracle which, given as input a matrix , outputs with where . We denote by the unique integer smaller than such that for . Therefore, outputs a ciphertext for the plaintext .

Definition 4 (EF--AGCD). The error-free--approximate-GCD problem is as follows. Pick random -bit integers of product , a random -rough , integers . Given , and oracle access to , guess .

The decisional problem is therefore to distinguish between an encryption of 0 and an encryption of 1.

Theorem 5. Our revised somewhat homomorphic encryption scheme is semantically secure under the error-free -approximate-GCD assumption.

Proof. An attacker takes as input the public key and outputs two messages and . The challenger returns an encryption of for a random bit . The attacker outputs a guess and succeeds if .
We introduce a matrix representation of ciphertexts. To any ciphertext , we associate the matrix:In the ciphertexts matrix, each ciphertext can be rewritten as a result of matrix operation, for ,where is the matrix of plaintexts , and , are two vectors which contain random noise in the third set of public keys. and are random integer matrixes. , contain random noise in the second set of public keys, and contain random noise in the first set of public keys (with the extended Kronecker function terms). According to the constraints on the parameters in Section 5.1, let random variable be uniform in Then, the statistical distance between the random variables and does not exceed . Therefore, and .
This concludes the proof of Theorem 5.

6. Floating-Point Fully Homomorphic Encryption Scheme (FFHE)

RSHE can only support finite homomorphic operations, so it is necessary to construct a fully homomorphic encryption scheme. In this section, we follow Gentry’s approach to transform RSHE into a fully homomorphic encryption scheme (FFHE), and we identify the scheme supporting operations over floating-point numbers.

6.1. Squash the Decryption Circuit

We first need to squash the decryption circuit. Specifically, we must add extra information about the secret key to the public key to “post process” the ciphertext. The ciphertext can be expressed as a low degree polynomial in the bits of the secret key. We add information about the secret key into the public key to construct a lower degree decryption polynomial.

We use the same technique as in [2] and generalize it to a batch setting. Let be three new parameters, concretely, , , . We add to the public key a set of rational numbers in with bits of precision after the binary point, such that for all there exists a sparse subset of size with . We also replace the secret key with the indicator vector of the subset . Formally, according to RSHE in Section 5.1, we define FFHE as follows.

(1) KeyGen: Generate and as before. Let , choose at random -bit vectors , each of Hamming weight , for . Choose at random integers for , fulfilling the condition that for . Set and . Each is a positive number smaller than two, with bits of precision after the binary point, and verifiesfor some .

As we set a new public key with bits of precision after the binary point, the public key size is , instead of as in our revised homomorphic encryption scheme. Using the public key compressing method proposed in Section 5.1, we also generate by using a pseudo-random generator with seed se. So, only se and must be stored in a public key.

The new secret key is , and the new public key is .

(2) Enc (pk, m): the same as Section 5.1.

(3) Expand (, c): the ciphertext expansion procedure takes as input a ciphertext c and computes an expanded ciphertext: let with bits of precision after the binary point for . Output the expanded ciphertext .

(4) Dec (, , , ⋯, ): output :

Lemma 6. The scheme after squashing the decryption circuit is correct for the set of circuits that compute permitted polynomials.

Proof. According to Lemma 3, the correct decrypted message is given by , so what we need to show is thatThen,To satisfy the constraints on parameters, we have , , so,then,The total distance is strictly less than 1/2. This concludes the proof.

6.2. Bootstrapping

As in [2], one sees that the scheme is bootstrappable. From Gentry’s theorem, we identify homomorphic encryption schemes for circuits of any depth.

Theorem 7. Let be the scheme above and let be the set of squashed decryption circuits. Then, .

For each plaintext, the Expand procedures work naturally in parallel. For , we consider the decryption equation:Except for the decryption equation, the proof of Theorem 7 is identical to the proof of Theorem 3 in [2].

6.3. Security Analysis

Our squashed scheme is semantically secure under the hardness of subset sum assumption, which is mentioned in [2, 16]. We use the attack analysis in [4] of the sparse subset sum problem. In our scheme, the attacker must solve the following equation:where are known and the secret key is of small Hamming weight . We assume that the attack knows and therefore .

Our squashed scheme makes an additional batch operation based on [4]. Moreover, the Expand procedures works naturally parallel over the plaintext bits, which means that the ciphertexts encrypted by different secret keys will not interfere with each other. For each , the attack analysis is similar to [4].

According to the asymptotic analysis in [4, 36], we can take , and to avoid known attacks on the sparse subset sum problem.

6.4. Floating-Point Calculation

According to Section 3.2, we denote a floating-point number (let b=2), which can be represented as a triple , and is the constant precision. To securely store a floating-point number, we use FFHE to encrypt it as , where is the sign bit of , is a -bits number. The encrypted floating-point number is constructed as . Then, we define two types of circuit operations, “” as addition circuit and “” as multiplication circuit, which take binary bits as input in plaintext operation and take large integer ciphertexts as input in ciphertext operation.

The comparison of magnitude of ciphertexts cannot be avoided in the operation of the ciphertexts. Suppose we have two ciphertexts and , where and are all integers. Define a bit to be 1 if and to be 0 otherwise. We propose a Greater-Than Bit (GTB) protocol to compute an encryption of the bit given only ciphertexts and without knowing the secret key.

and are signed integers. They can be expressed as binary numbers and , and are sign bits of respectively. Through the Boolean circuit, we can calculate . We can use two’s complement to achieve binary subtraction. For example,Specifically,Therefore, using the addition circuit, we define the “” as subtraction circuit as above (we do not need the modulo operation in the subtraction operation of ciphertexts).

Greater-Than Bit Protocol. We use the subtraction circuit to implement our proposed GTB protocol. Given two ciphertexts and , GTB protocol is to show or . The overall steps of GTB are shown as follows.

Step 1. We execute the subtraction circuit to calculate the ciphertexts of .The input of our FFHE scheme is binary bit; therefore, the ciphertext isand is the sign bit of .

Step 2. We need to check whether the signs of and are consistent. is the ciphertext for 1, when the signs of and are the same, and is the ciphertext for 0, when the signs of and are different.

Step 3. We define GTB protocol as . Gtb is the ciphertext for 0, when , and is ciphertext for 1, when .

Equivalent-Bit Protocol. Additionally, it is necessary to check whether two numbers are equivalent or not. Therefore, we propose the Equivalent-Bit (EB) protocol. Given two ciphertexts and , the EB protocol is to show whether . The overall steps of EB protocol are shown as follows.

Step 1. We execute GTB protocol to check or .

Step 2. We define EB protocol as . Notice that if , then . Otherwise, .

Left Shift Protocol. In floating-point number addition, it is necessary to unify the exponents of these floating-point numbers. Therefore, we propose the Left Shift (LS) protocol to adjust the significand of a floating-point number. Given a ciphertext of the significand and two ciphertexts of the exponents , , we calculate , where . The overall steps of LS protocol are shown as follows.

Step 1. For in ( is an extremal exponent as described in Section 3.2),Return .

We define LS protocol as We also propose floating-point number addition (FAdd) protocol and floating-point number multiplication (FMult) protocol to compute the addition and multiplication of the ciphertexts of the floating-point numbers. Suppose we have two floating-point numbers , . The ciphertexts are and respectively. The overall steps of FAdd protocol and FMult protocol are shown as follows.

Floating-Point Number Addition Protocol

Step 1. We need to check whether the signs of and are consistent. is the ciphertext for 1, when , and is the ciphertext for 0, when . Supposing that , the sign bit of is .

Step 2. If , the sign of is the same as the sign of the larger between and , specifically, the sign bit of is as follows:

Step 3. We calculate the sign of the addition of and .

Step 4. When , the significand of is as follows:Therefore, we calculate the final significand of the addition of and .It shows that is k+l binary bits, and the precision of the result is k+l.

Step 5. If , it shows that the exponent of is . If , it shows that the exponent of is . The construction is as follows:We calculate the exponent of the addition of x and y.

Step 6. Finally, we need to keep the result significand bits.Therefore, is binary bits. The result of addition can be represented as, specifically, .

As above, the precision is still . Floating-point addition does not add additional relative error. For subsequent operations, the precision is still , and the relative error as in Section 3.2.

Floating-Point Number Multiplication Protocol

Step 1. First, we calculate the sign of the multiplication of and .

Step 2. Then, we calculate the exponent.

Step 3. Finally, we calculate the significand.It shows that is 2k binary bits, and the precision of the result is 2k.

Step 4. Thereafter, we need to keep the result significand bits.Therefore, is binary bits. The result of multiplication can be represented as , specifically,