Security and Communication Networks

Volume 2018, Article ID 2363928, 14 pages

https://doi.org/10.1155/2018/2363928

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

^{1}College of Computer Science, Nanjing University of Posts and Telecommunication, Nanjing 210003, China^{2}Key Laboratory of Broadband Wireless Communication & Sensor Networks Technology of Ministry of Education, Nanjing University of Posts and Telecommunications, Nanjing 210003, China^{3}Jiangsu 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.

#### Abstract

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 [3–5, 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, 15–18] 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 [3–5]. 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 [3–5].

(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, 22–25].

(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. [3–5] proposed several optimization techniques to reduce public key size. Homomorphic encryption scheme can also be applied in provable data possession [26–29].

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.Evaluate****pk, ****, ****, ****, ****, **. 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.Decrypt****sk, **. 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 [3–5] 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* f*_{1},* f*_{2}, with two random seeds* se*_{1},* se*_{2} (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.