title | filename | chapternum |
---|---|---|
Fully Homomorphic Encryption |
lec_15_FHE |
16 |
In today's era of "cloud computing", much of individuals' and businesses' data is stored and computed on by third parties such as Google, Microsoft, Apple, Amazon, Facebook, Dropbox and many others.
Classically, cryptography provided solutions to protecting data in motion from point A to point B.
But these are not always sufficient to protect data at rest and particularly data in use.
For example, suppose that Alice has some data
Encryption does not seem to immediately solve the problem.
Alice could store at Bob an encrypted version of the data and keep the secret key for herself.
But then she would be at a loss if she wanted to do with the data anything more than retrieving particular blocks of it.
If she wanted to outsource computation to Bob as well, and compute
For example, after the computing systems of Office of Personell Management (OPM) were discovered to be hacked in June of 2015, revealing sensitive information, including fingerprints and all data gathered during security clearance checks of up to 18 million people, DHS assistant secretary for cybersecurity and communications Andy Ozment said that encryption wouldn't have helped preventing it since "if an adversary has the credentials of a user on the network, then they can access data even if it's encrypted, just as the users on the network have to access data". So, can we encrypt data in a way that still allows some access and computing on it?
Already in 1978, Rivest, Adleman and Dertouzos considered this problem of a business that wishes to use a "commercial time-sharing service" to store some sensitive data.
They envisioned a potential solution for this task which they called a privacy homomorphism.
This notion later became known as fully homomorphic encryption (FHE) which is an encryption that allows a party (such as the cloud provider) that does not know the secret key to modify a ciphertext
Unlike the case of a trapdoor function, where it only took a year for Diffie and Hellman's challenge to be answered by RSA, in the case of fully homomorphic encryption for more than 30 years cryptographers had no constructions achieving this goal. In fact, some people suspected that there is something inherently incompatible between the security of an encryption scheme and the ability of a user to perform all these operations on ciphertexts. Stanford cryptographer Dan Boneh used to joke to incoming graduate students that he will immediately sign the thesis of anyone who came up with a fully homomorphic encryption. But he never expected that he will actually encounter such a thesis, until in 2009, Boneh's student Craig Gentry released a paper doing just that. Gentry's paper shook the world of cryptography, and instigated a flurry of research results making his scheme more efficient, reducing the assumptions it relied on, extending and applying it, and much more. In particular, Brakerski and Vaikuntanathan managed to obtain a fully homomorphic encryption scheme based only on the Learning with Error (LWE) assumption we have seen before.
Although there is an open source library, as well as other implementations, there is still much work to be done in order to turn FHE from theory to practice. For a comparable level of security, the encryption and decryption operations of a fully homomorphic encryption scheme are several orders of magnitude slower than a conventional public key system, and (depending on its complexity) homomorphically evaluating a circuit can be significantly more taxing. However, this is a fast evolving field, and already since 2009 significant optimizations have been discovered that reduced the computational and storage overhead by many orders of magnitudes. As in public key encryption, one would imagine that for larger data one would use a "hybrid" approach of combining FHE with symmetric encryption, though one might need to come up with tailor-made symmetric encryption schemes that can be efficiently evaluated.^[In 2012 the state of art on homomorphically evaluating AES was about six orders of magnitude slower than non-homomorphic AES computation. I don't know what's the current record.]
In this lecture and the next one we will focus on the fully homomorphic encryption schemes that are easiest to describe, rather than the ones that are most efficient (though the efficient schemes share many similarities with the ones we will talk about). As is generally the case for lattice based encryption, the current most efficient schemes are based on ideal lattices and on assumptions such as ring LWE or the security of the NTRU cryptosystem.1
To take the distance between theory and practice in perspective, it might be useful to consider the case of verifying computation. In the early 1990's researchers (motivated initially by zero knowledge proofs) came up with the notion of probabilistically checkable proofs (PCP's) which could yield in principle extremely succinct ways to check correctness of computation.
Probabilistically checkable proofs can be thought of as "souped up" versions of NP completeness reductions and like these reductions, have been mostly used for negative results, especially since the initial proofs were extremely complicated and also included enormous hidden constants. However, with time people have slowly understood these better and made them more efficient (e.g., see this survey) and it has now reached the point where these results, are nearly practical (see also this) and in fact these ideas underly at least one startup. Overall, constructions for verifying computation have improved by at least 20 orders of magnitude over the last two decades. (We will talk about some of these constructions later in this course.) If progress on fully homomorphic encryption follows a similar trajectory, then we can expect the road to practical utility to be very long, but there is hope that it's not a "bridge to nowhere".
Since large scale fully homomorphic encryption is still impractical, people have been trying to achieve at least weaker security goals using certain assumptions.
In particular Intel chips have so called "Secure enclaves" which one can think of as a somewhat tamper-protected region of the processor that is supposed to be out of reach for the outside world.
The idea is that a cloud provider client would treat this enclave as a trusted party that it can communicate with through the cloud provider.
The client can store their data on the cloud encrypted with some key
We start by defining partially homomorphic encryption. We focus on encryption for single bits. This is without loss of generality for CPA security (CCA security is anyway ruled out for homomorphic encryption- can you see why?), though there are more efficient constructions that encrypt several bits at a time.
Let $\mathcal{F} = \cup \mathcal{F}\ell$ be a class of functions where every $f\in\mathcal{F}\ell$ maps
An $\mathcal{F}$-homomorphic public key encryption scheme is a CPA secure public key encryption scheme
-
$c=EVAL_e(f,E_e(x_1),\ldots,E_e(x_\ell))$ has length at most$n$ . \ -
$D_d(c)=f(x_1,\ldots,x_\ell)$ .
\
Please stop and verify you understand the definition.
In particular you should understand why some bound on the length of the output of
A fully homomomorphic encryption is simply a partially homomorphic encryption scheme for the family
The canonical application of fully homomorphic encryption is for a client to store encrypted data
Here is a cute protocol to achieve the latter goal (due to Chung Kalai and Vadhan).
Curiously the protocol involves "doubly encrypting" the input, and homomorphically evaluating the
-
Assumptions: We assume that all functions
$f$ that the client will be interested in can be described by a string of length$n$ . -
Preprocessing: The client generates a pair of keys
$(e,d)$ . In the initial stage the client computes the encrypted database$\overline{c}=E_e(x)$ and sends$\overline{c},e,e'$ to the server. It also computes $c^* = E_e(f^)$ for some function $f^$ as well as $C^{}=EVAL_{e}(eval,E_e(f^)|\overline{c})$ for some function $f^$ and keeps $c^*,c^{}$ for herself, where$eval(f,x)=f(x)$ is the circuit evaluation function. -
Client query: To ask for an evaluation of
$f$ , the client generates a new random FHE keypair$(e',d')$ , chooses$b \leftarrow_R {0,1}$ and lets$c_b = E_{e'}(E_e(f))$ and$c_{1-b}=E_{e'}(c^*)$ . It sends the triple$e',c_0,c_1$ to the server. -
Server response: Given the queries
$c_0,c_1$ , the server defines the function$g:{0,1}^* \rightarrow {0,1}^*$ where$g(c)=EVAL_e(eval,c|\overline{c})$ (for the fixed$\overline{c}$ received) and computes$c'_0,c'_1$ where $c'b = EVAL{e'}(g_b,c_b)$. (Please pause here and make sure you understand what this step is doing! Note that we use here crucially the fact that$EVAL$ itself is a polynomial time computation.) -
Client check: Client checks whether $D_{d'}(c'{1-b})=c^{**}$ and if so accepts $D_d(D{d'}(c'_b))$ as the answer.
We claim that if the server cheats then the client will detect this with probability
It turns out that Regev's LWE-based encryption LWEENC we saw before is homomorphic with respect to the class of linear (mod 2) functions. Let us recall the LWE assumption and the encryption scheme based on it.
Let
-
$A$ is an$m\times n$ matrix over$\Z_q$ and$s\in\Z_q^n$ satisfies$s_1=\floor{\tfrac{q}{2}}$ and$|As|_i \leq \sqrt{q}$ for every$i\in {1,\ldots, m}$ .
- The distribution
$A$ where$(A,s)$ is sampled from$LWE_q$ is computationally indistinguishable from the uniform distribution of$m\times n$ matrices over$\Z_q$ .
The LWE conjecture is that
It is a good idea for you to pause here and try to show the equivalence on your own.
The reason the two conjectures are equivalent are the following.
Before we phrased the conjecture as recovering
A linearly-homomorphic encryption scheme: We can describe the encryption scheme LWEENC presented in class as:
- Key generation: Choose
$(A,s)$ from$LWE_q$ where$m$ satisfies$q^{1/4} \gg m \log q \gg n$ .
- To encrypt
$b\in{0,1}$ , choose$w\in{0,1}^m$ and output$w^\top A + (b,0,\ldots,0)$
- To decrypt
$c\in\Z_q^n$ , output$0$ iff$|\langle c,s \rangle| \leq q/10$ , where for$x\in\Z_q$ we defined$|x| = \min { x , q-x }$ .
\
The decryption algorithm recovers the original plaintext since
For every
This claim is not hard to prove, but working it out for yourself can be a good way to get more familiarity with LWEENC and the kind of manipulations we'll be making time and again in the constructions of many lattice based cryptographic primitives.
Try to show that
The proof is quite simple.
Several other encryption schemes are also homomorphic with respect to linear functions, and even before Gentry's construction people have managed to achieve homomorphism with respect to slightly larger classes (e.g., quadratic functions by Boneh, Goh and Nissim) but not significantly so.
It is instructive to consider the following abstraction (which we'll use in the next lecture) of the above encryption scheme as a trapdoor generator (see TDPgenfig{.ref}).
On input
-
Any polynomial number of samples from the distribution
$G_s(1^n)$ is computationally indistinguishable from independent samples from the uniform distribution over$\Z_q^n$ -
If
$c$ is output by$G_s(1^n)$ then$|\langle c,s \rangle| \leq n\sqrt{q}$ .
Thus
Note that this trapdoor generator satisfies the following stronger property: we can generate an alternative generator
A trapdoor generator is a pair of randomized algorithms
- On input
$1^n$ ,$GEN$ outputs a pair$(G_s,s)$ where$G_s$ is a string describing a randomized circuit that itself takes$1^n$ as input and outputs a string of length$t$ where$t=t(n)$ is some polynomial. \ - On input
$1^n$ ,$GEN'$ outputs$G'$ where$G'$ is a string describing a randomized circuit that itself takes$1^n$ as input. \ - The distributions
$GEN(1^n)_1$ (i.e., the first output of$GEN(1^n)$ and$GEN'(1^n)$ are computationally indistinguishable \ - With probability
$1-negl(n)$ over the choice of$G'$ output by$GEN'$ , the distribution$G'(1^n)$ is statistically indistinguishable (i.e., within$negl(n)$ total variation distance) from$U_t$ . \ - There is an efficient algorithm
$T$ such that for every pair$(G_s,s)$ output by$GEN$ ,$\Pr[ T(s,G_s(1^n))=1] \geq 1- negl(n)$ (where this probability is over the internal randomness used by$G_s$ on the input$1^n$ ) but$\Pr[ T(s,U_t)=1] \leq 1/3$ .^[The choice of$1/3$ is arbitrary, and can be amplified as needed.]
This is not an easy definition to parse, but looking at TDPgenfig{.ref} can help.
Make sure you understand why
Aside: trapdoor generators in real life: In the above we use the notion of a "trapdoor" in the pseudorandom generator as a mathematical abstraction, but generators with actual trapdoors have arisen in practice. In 2007 the National Institute of Standards (NIST) released standards for pseudorandom generators. Pseudorandom generators are the quintessential private key primitive, typically built out of hash functions, block ciphers, and such and so it was surprising that NIST included in the list a pseudorandom generator based on public key tools - the Dual EC DRBG generator based on elliptic curve cryptography. This was already strange but became even more worrying when Microsoft researchers Dan Shumow and Niels Ferguson showed that this generator could have a trapdoor in the sense that it contained some hardwired constants that if generated in a particular way, there would be some information that (just like in
$G_s$ above) allows to distinguish the generator from random (see here for a 2007 blog post on this issue). We learned more about this when leaks from the Snowden document showed that the NSA secretly paid 10 million dollars to RSA to make this generator the default option in their Bsafe software.
You'd think that this generator is long dead but it turns out to be the "gift that keeps on giving". In December of 2015, Juniper systems announced that they have discovered a malicious code in their system, dating back to at least 2012 (possibly 2008), that would allow an attacker to surreptitiously decrypt all VPN traffic through their firewalls. The issue is that Juniper has been using the Dual EC DRBG and someone has managed to replace the constant they were using with another one, one that they presumably knew the trapdoor for (see here and here for more; of course unless you know to check for this, it's very hard by looking at the code to see that one arbitrary looking constant has been replaced by another). Apparently, even though this is very surprising to many people in law enforcement and government, inserting back doors into cryptographic primitives might end up making them less secure.
Gentry's breakthrough had two components:
-
First, he gave a scheme that is homomorphic with respect to arithmetic circuits (involving not just addition but also multiplications) of logarithmic depth.
-
Second, he showed the amazing "bootstrapping theorem" that if a scheme is homomorphic enough to evaluate its own decryption circuit, then it can be turned into a fully homomorphic encryption that can evaluate any function.
Combining these two insights led to his fully homomorphic encryption.2
In this lecture we will focus on the second component - the bootstrapping theorem. We will show a "partially homomorphic encryption" (based on a later work of Gentry, Sahai and Waters) that can fit that theorem in the next lecture.
The bootstrapping theorem is quite surprising.
A priori you might expect that given that a homomorphic encryption for linear functions was not trivial to do, a homomorphic encryption for quadratics would be harder, cubics even harder and so on and so forth.
But it turns out that there is some special degree $t^$ such that if we obtain homomorphic encryption for degree $t^$ polynomials then we can obtain fully homomorphic encryption that works for all functions.
(Specifically, if the decryption algorithm
We now show the bootstrapping theorem:
Suppose that
Here is one analogy for bootstrapping, inspired by Gentry's survey.
Suppose that you need to construct some complicated object from a highly toxic material (see ziplocbagfig{.ref}).
You are given a supply of sealed bags that are flexible enough so you can manipulate the object from outside the bag.
However, each bag can only hold for
We now turn to the formal proof of bootstrapthm{.ref}
The idea behind the proof is simple but ingenious.
Recall that the NAND gate
Thus to prove the theorem, we need to modify
So, now all that is left is to define the
Don't let the short proof fool you. This theorem is quite deep and subtle, and requires some reading and re-reading to truly "get" it.
Footnotes
-
As we mentioned before, as a general rule of thumb, the difference between the ideal schemes and the one that we describe is that in the ideal setting one deals with structured matrices that have a compact representation as a single vector and also enable fast FFT-like matrix-vector multiplication. This saves a factor of about $n$ in the storage and computation requirements (where $n$ is the dimension of the subspace/lattice). However, there can be some subtle security implications for ideal lattices as well, see e.g., here, here, here, and here. ↩
-
The story is a bit more complex than that. Frustratingly, the decryption circuit of Gentry's basic scheme was just a little bit too deep for the bootstrapping theorem to apply. A lesser man, such as yours truly, would at this point surmise that fully homomprphic encryption was just not meant to be, and perhaps take up knitting or playing bridge as an alternative hobby. However, Craig persevered and managed to come up with a way to "squash" the decryption circuit so it can fit the bootstrapping parameters. Follow up works, and in particular the paper of Brakerski and Vaikuntanathan, managed to get schemes with much better relation between the homomorphism depth and decryption circuit, and hence avoid the need for squashing and also improve the security assumptions. ↩
-
You can ignore the condition of circular security in a first read - we will discuss it later. ↩
-
Without this assumption we can still obtained a form of FHE known as a leveled FHE where the size of the public key grows with the depth of the circuit to be evaluated. We can do this by having $\ell$ public keys where $\ell$ is the depth we want to evaluate, and encrypt the private key of the $i^{th}$ key with the $i+1^{st}$ public key. However, since circular security seems quite likely to hold, we ignore this extra complication in the rest of the discussion. ↩