Homomorphic encryption
Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it first. The result of the computation is on an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.
Homomorphic encryption can be used for privacy-preserving outsourced storage and computation. This allows data to be encrypted and out-sourced to commercial cloud environments for processing, all while encrypted. In highly regulated industries, such as health care, homomorphic encryption can be used to enable new services by removing privacy barriers inhibiting data sharing. For example, predictive analytics in health care can be hard to apply due to medical data privacy concerns, but if the predictive analytics service provider can operate on encrypted data instead, these privacy concerns are diminished.
Description
Homomorphic encryption is a form of encryption with an additional evaluation capability for computing over encrypted data without access to the secret key. The result of such a computation remains encrypted. Homomorphic encryption can be viewed as an extension of either symmetric-key or public-key cryptography. Homomorphic refers to homomorphism in algebra: the encryption and decryption functions can be thought of as homomorphisms between plaintext and ciphertext spaces.Homomorphic encryption includes multiple types of encryption schemes that can perform different classes of computations over encrypted data.
Some common types of homomorphic encryption are partially homomorphic, somewhat homomorphic, leveled fully homomorphic, and fully homomorphic encryption. The computations are represented as either Boolean or arithmetic circuits. Partially homomorphic encryption encompasses schemes that support the evaluation of circuits consisting of only one type of gate, e.g., addition or multiplication. Somewhat homomorphic encryption schemes can evaluate two types of gates, but only for a subset of circuits. Leveled fully homomorphic encryption supports the evaluation of arbitrary circuits of bounded depth. Fully homomorphic encryption allows the evaluation of arbitrary circuits of unbounded depth, and is the strongest notion of homomorphic encryption. For the majority of homomorphic encryption schemes, the multiplicative depth of circuits is the main practical limitation in performing computations over encrypted data.
Homomorphic encryption schemes are inherently malleable. In terms of malleability, homomorphic encryption schemes have weaker security properties than non-homomorphic schemes.
History
Homomorphic encryption schemes have been developed using different approaches. Specifically, fully homomorphic encryption schemes are often grouped into generations corresponding to the underlying approach.Pre-FHE
The problem of constructing a fully homomorphic encryption scheme was first proposed in 1978, within a year of publishing of the RSA scheme. For more than 30 years, it was unclear whether a solution existed. During that period, partial results included the following schemes:- RSA cryptosystem ;
- ElGamal cryptosystem ;
- Goldwasser–Micali cryptosystem ;
- Benaloh cryptosystem ;
- Paillier cryptosystem ;
- Sander-Young-Yung system ;
- Boneh–Goh–Nissim cryptosystem ;
- Ishai-Paskin cryptosystem.
First-generation FHE
For Gentry's "noisy" scheme, the bootstrapping procedure effectively "refreshes" the ciphertext by applying to it the decryption procedure homomorphically, thereby obtaining a new ciphertext that encrypts the same value as before but has lower noise. By "refreshing" the ciphertext periodically whenever the noise grows too large, it is possible to compute an arbitrary number of additions and multiplications without increasing the noise too much.
Gentry based the security of his scheme on the assumed hardness of two problems: certain worst-case problems over ideal lattices, and the sparse subset sum problem.
Gentry's Ph.D. thesis
provides additional details.
The Gentry-Halevi implementation of Gentry's original cryptosystem reported timing of about 30 minutes per basic bit operation. Extensive design and implementation work in subsequent years have improved upon these early implementations by many orders of magnitude runtime performance.
In 2010, Marten van Dijk, Craig Gentry, Shai Halevi and Vinod Vaikuntanathan presented a second fully homomorphic encryption scheme,
which uses many of the tools of Gentry's construction, but which does not require ideal lattices. Instead, they show that the somewhat homomorphic component of Gentry's ideal lattice-based scheme can be replaced with a very simple somewhat homomorphic scheme that uses integers. The scheme is therefore conceptually simpler than Gentry's ideal lattice scheme, but has similar properties with regards to homomorphic operations and efficiency. The somewhat homomorphic component in the work of Van Dijk et al. is similar to an encryption scheme proposed by Levieil and Naccache in 2008, and also to one that was proposed by Bram Cohen in 1998.
Cohen's method is not even additively homomorphic, however. The Levieil–Naccache scheme supports only additions, but it can be modified to also support a small number of multiplications.
Many refinements and optimizations of the scheme of Van Dijk et al. were proposed in a sequence of works by Jean-Sébastien Coron, Tancrède Lepoint, Avradip Mandal, David Naccache, and Mehdi Tibouchi.
Some of these works included also implementations of the resulting schemes.
Second-generation FHE
The homomorphic cryptosystems in current use are derived from techniques that were developed starting in 2011-2012 by Zvika Brakerski, Craig Gentry, Vinod Vaikuntanathan, and others. These innovations led to the development of much more efficient somewhat and fully homomorphic cryptosystems. These include:- The Brakerski-Gentry-Vaikuntanathan scheme, building on techniques of Brakerski-Vaikuntanathan;
- The NTRU-based scheme by Lopez-Alt, Tromer, and Vaikuntanathan ;
- The Brakerski/Fan-Vercauteren scheme, building on Brakerski's cryptosystem;
- The NTRU-based scheme by Bos, Lauter, Loftus, and Naehrig, building on LTV and Brakerski's scale-invariant cryptosystem;
- The Cheon-Kim-Kim-Song scheme.
All the second-generation cryptosystems still follow the basic blueprint of Gentry's original construction, namely they first construct a somewhat homomorphic cryptosystem and then convert it to a fully homomorphic cryptosystem using bootstrapping.
A distinguishing characteristic of the second-generation cryptosystems is that they all feature a much slower growth of the noise during the homomorphic computations.
Additional optimizations by Craig Gentry, Shai Halevi, and Nigel Smart resulted in cryptosystems with nearly optimal asymptotic complexity: Performing operations on data encrypted with security parameter has complexity of only.
These optimizations build on the Smart-Vercauteren techniques that enables packing of many plaintext values in a single ciphertext and operating on all these plaintext values in a SIMD fashion.
Many of the advances in these second-generation cryptosystems were also ported to the cryptosystem over the integers.
Another distinguishing feature of second-generation schemes is that they are efficient enough for many applications even without invoking bootstrapping, instead operating in the leveled FHE mode.
Third-generation FHE
In 2013, Craig Gentry, Amit Sahai, and Brent Waters proposed a new technique for building FHE schemes that avoids an expensive "relinearization" step in homomorphic multiplication.Zvika Brakerski and Vinod Vaikuntanathan observed that for certain types of circuits, the GSW cryptosystem features an even slower growth rate of noise, and hence better efficiency and stronger security.
Jacob Alperin-Sheriff and Chris Peikert then described a very efficient bootstrapping technique based on this observation.
These techniques were further improved to develop efficient ring variants of the GSW cryptosystem: FHEW and TFHE. The FHEW scheme was the first to show that by refreshing the ciphertexts after every single operation, it is possible to reduce the bootstrapping time to a fraction of a second. FHEW introduced a new method to compute Boolean gates on encrypted data that greatly simplifies bootstrapping, and implemented a variant of the bootstrapping procedure. The efficiency of FHEW was further improved by the TFHE scheme, which implements a ring variant of the bootstrapping procedure using a method similar to the one in FHEW.
Partially homomorphic cryptosystems
In the following examples, the notation is used to denote the encryption of the message.Unpadded RSA
If the RSA public key has modulus and encryption exponent, then the encryption of a message is given by. The homomorphic property is then
ElGamal
In the ElGamal cryptosystem, in a cyclic group of order with generator, if the public key is, where, and is the secret key, then the encryption of a message is, for some random. The homomorphic property is then
Goldwasser–Micali
In the Goldwasser–Micali cryptosystem, if the public key is the modulus and quadratic non-residue, then the encryption of a bit is, for some random. The homomorphic property is then
where denotes addition modulo 2,.
Benaloh
In the Benaloh cryptosystem, if the public key is the modulus and the base with a blocksize of, then the encryption of a message is, for some random. The homomorphic property is then
Paillier
In the Paillier cryptosystem, if the public key is the modulus and the base, then the encryption of a message is, for some random. The homomorphic property is then
Other partially homomorphic cryptosystems
- Okamoto–Uchiyama cryptosystem
- Naccache–Stern cryptosystem
- Damgård–Jurik cryptosystem
- Sander–Young–Yung encryption scheme
- Boneh–Goh–Nissim cryptosystem
- Ishai–Paskin cryptosystem
- Castagnos–Laguillaumie cryptosystem
Fully Homomorphic Encryption
Fully homomorphic cryptosystems have great practical implications in the outsourcing of private computations, for instance, in the context of cloud computing.
Implementations
A list of open-source FHE libraries implementing second-generation and/or third-generation FHE schemes is provided above.An up-to-date is also maintained by the industry standards consortium.
There are several open-source implementations of second- and third-generation fully homomorphic encryption schemes. Second-generation FHE scheme implementations typically operate in the leveled FHE mode and support efficient SIMD-like packing of data; they are typically used to compute on encrypted integers or real/complex numbers. Third-generation FHE scheme implementations often bootstrap after each Boolean gate operation but have limited support for packing and efficient arithmetic computations; they are typically used to compute Boolean circuits over encrypted bits. The choice of using a second-generation vs. third-generation scheme depends on the input data types and the desired computation.
FHE libraries
- HElib by IBM implements the BGV scheme with the GHS optimizations, and the CKKS scheme;
- Microsoft SEAL implements the BFV and the CKKS encryption schemes;
- PALISADE by a consortium of DARPA-funded defense contractors and academics, including New Jersey Institute of Technology, Duality Technologies, Raytheon BBN Technologies, MIT, University of California, San Diego and others. PALISADE is a general-purpose lattice cryptography library implementing the BFV, BGV, CKKS, FHEW, and other lattice schemes;
- HEAAN by Seoul National University implements the CKKS scheme along with bootstrapping.
- FHEW by Leo Ducas and Daniele Micciancio implements the FHEW scheme.
- TFHE by Ilaria Chillotti, Nicolas Gama, Mariya Georgieva and Malika Izabachene implements the TFHE scheme.
- FV-NFLlib by CryptoExperts implements the BFV scheme.
- NuFHE by NuCypher provides a GPU implementation of TFHE.
- Lattigo implements the BFV and the CKKS encryption schemes in Go along with their distributed variants enabling Secure multi-party computation.
FHE frameworks
- E3 by MoMA Lab at NYU Abu Dhabi supports TFHE, FHEW, HElib and SEAL libraries.
- SHEEP by Alan Turing Institute supports HElib, SEAL, PALISADE and TFHE libraries.
Standardization