View source for BFV

Around 2012 Brakerski <ref>Z. Brakerski.
Fully Homomorphic Encryption without Modulus Switching from Classical GapSVP.
CRYPTO 2012. http://eprint.iacr.org/2012/078.pdf </ref> proposed a new efficient FHE scheme whose security is based on the [https://en.wikipedia.org/wiki/Learning_with_errors LWE] problem. Later on, this scheme was ported to the [https://en.wikipedia.org/wiki/Ring_learning_with_errors ring-LWE] setting by Fan and Vercauteren. <ref> J. Fan and F. Vercauteren. Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, Report
2012/144, Mar. 2012. https://eprint.iacr.org/2012/144.pdf </ref> The various optimisations achieved by the last two authors made the scheme suitable for implementation. One such implementation is available in Microsoft SEAL <ref name = SEAL> Microsoft Research. Microsoft SEAL (release 3.5). 2020. https://github.com/Microsoft/SEAL </ref> is an actively maintained library which makes homomorphic encryption available in an easy-to-use form both to experts and to non-experts.

==Overview of the BFV scheme==

In BFV the plaintext space consists of polynomials of degree less than <math>n </math> with coefficients modulo <math> t</math>, more precisely <math> \mathcal R_t = \mathbb Z_{t}[x]/(x^n+1) </math>. This is a ring, where addition is just the usual addition of polynomials. Multiplication is also quite intuitive, in the sense that multiplication of two elements is just multiplication of the underlying polynomials with <math>x^n </math> being converted to <math>-1 </math>. In this way, the result of ring operations on <math>\mathcal R_t </math> is always a polynomial of degree strictly less than <math>n </math>. 

The homomorphic operations on ciphertext, that will be described later, will carry through encryption to addition and multiplication operations in the plaintext <math> \mathcal R_t </math>.

If we wish to encrypt an integer or a rational number, then we need to encode it first into a plaintext polynomial in <math> \mathcal R_t </math> and the result can be encrypted only after that. We mention that distinction should be made between <b> encoding </b> and <b> encrypting </b> data. The first one is a public operation, i.e. anybody can reverse it by <b> decoding </b>, whereas the latter can be reverse just by someone who knows the (secret) encryption key. In
order to be able to compute additions and multiplications on, for example, integers in encrypted form,
the encoding must be such that addition and multiplication of encoded polynomials in <math> \mathcal R_t </math> 
carry over correctly to the integers when the result is decoded. The aforementioned library Microsoft SEAL provides a few different standard encoders that users can use at their convenience.

The ciphertext space in this scheme consists of arrays of polynomials in <math> \mathcal R_q </math>, for some different (much larger than <math> t </math>) integer <math>q</math>. These arrays contain at least two polynomials. Their length grows with each homomorphic multiplication, unless an operation called <b> reliniarization </b> is performed. The latter is a procedure which takes a ciphertext consisting of more than <math> 2 </math> polynomials in <math> \mathcal R_q </math> back to a ciphertext with <math> 2 </math> polynomials encrypting the same message <math> m \in \mathcal R_t </math>.

== Description of the scheme ==

Let <math> \lambda </math> be the security parameter. Let <math> w </math> be a base (one can think of <math> w =2 </math> for the sake of presentation) and let <math>l+1= \lfloor \log_w q \rfloor +1 </math> denote the number of terms in the decomposition into base <math> q</math>. Polynomials in <math> \mathcal R_q </math> will also be decomposed into base <math> w </math> components coefficient-wise, resulting in <math> l+1 </math> polynomials. When <math>S</math> is a set, we denote <math>a \leftarrow S </math> we denote the fact that <math> a </math> is sampled uniformly from the set <math> S</math>.

The BFV scheme has the algorithms <math>SecretKeyGen, PublicKeyGen, EvaluationKeyGen, Encrypt, Decrypt, Add </math> and <math>Multiply </math>. We describe these below.

* <math> SecretKeyGen(\lambda) </math>: This just samples <math> s \leftarrow \mathcal  R_2 </math> and outputs the secre key <math> sk=s </math>.

* <math> PublicKeyGen(sk) </math>: Set <math> s =sk </math>, sample <math> a \leftarrow \mathcal R_q </math> uniformly and <math>e \leftarrow \chi </math> from an error distribution. Output the public key <math> pk = ([-(as+e)]_q, a) </math>.

* <math> EvaluationKeyGen(sk,w) </math>: for <math>i \in \{0,\dots, l \} </math>, sample <math>a_i \leftarrow \mathcal R_q </math> and <math> e_i \leftarrow \chi  </math>. Output
<center> <math> evk = ([-(a_is+e_i)+w^is^2]_q,a_i) </math>. </center>

The autors note that one can think of the evaluation key essentially as
a masking of the secret key raised to the power 2 (or, more generally, to some higher power).
Unfortunately, it is not possible to argue the uniformity of the evaluation key based on the
decision-RLWE assumption. Instead, one can think of it as an encryption of (some power of)
the secret key under the secret key itself, and to argue security one needs to make the extra
assumption that the encryption scheme is secure even when the adversary has access to all of
the evaluation keys which may exist. This point is also explained in the SEAL manual <ref> K. Lane. Simple Encrypted Arithmetic Library. Microsoft Research. https://www.microsoft.com/en-us/research/uploads/prod/2017/11/sealmanual-2-3-1.pdf </ref>.

* <math>Encrypt(pk,m):</math> For <math> m \in \mathcal R_t </math>, let <math> p_k = (p_0,p_1)</math>. Sample <math> u \leftarrow \mathcal R_2 </math> uniformly and <math>e_1, e_2 \leftarrow \chi </math>. Compute and output
<center> <math>  ct = ([ \frac{q}{t} \cdot m + p_0 u+e_1]_q, [p_qu +e_2]_q)</math> .</center>

* <math>Decrypt(sk,ct) </math>: Set <math> s=sk, c_0 = ct[0] </math> and <math>c_1 = ct[1] </math>. Output
<center> <math> \left[ \left\lfloor \frac{t}{q} \cdot [c_0+c_1s]_q \right\rfloor \right]_t </math>.  </center>

The homomorphic operations on ciphertext are as follows

* <math>Add(ct_0, ct_1):</math> Output <math>(ct_0[0]+ct_1[0], ct_0[1]+ct_1[1]).</math>

As one can see addition is done in the most natural way, component-wise. Multiplication is a little bit more tricky.

* <math>Multiply(ct_0, ct_1):</math> Compute

<center><math>  c_0 = \left[ \left\lfloor \frac{t}{q} ct_0[0] ct_1[0] \right\rceil \right]_q </math>,</center>

<center><math> c_1 = \left[ \left\lfloor \frac{t}{q}(ct_0[0]ct_1[1]+ct_0[1]ct_1[0]) \right\rceil \right]_q </math> ,</center>

and <math> c_2 = \left[ \left\lfloor \frac{t}{q} (ct_0[1]ct_1[1]) \right\rceil \right]_q </math>.

This first step is quite easy. One can think of <math>ct_i </math> as a polynomial <math>ct_i(x)= ct_i[0] + x \cdot ct_i[1] </math> with coefficients in <math> \mathcal R_q </math>. What we did so far corresponds to computing the product of the polynomials <math>ct_1(x) </math>  and <math>ct_2(x) </math>, resulting in a (quadratic in <math> x</math>) polynomial <math> c_0+c_1x+c_2x^2 </math>. This corresponds to a length <math> 3</math> array <math>(c_0,c_1,c_2) </math>. To keep the size of the ciphertext small, we now apply a reliniarization step. The latter consists in computing
<center> <math>  c_0' = c_0+ \sum_{i=0}^l evk[i][0] c_2^{(i)} </math>,</center>

<center> <math> c_1' = c_1 + \sum_{i=0}^l evk[i][1] c_2^{(i)} </math> ,</center>

and return as output the ciphertext <math>(c_0', c_1')</math>.

We remark that the last step is the only place where one has to use the evaluation key, therefore having to rely on the extra circular security assumption. In practice, if one does not need to perform bootstrapping for obtaining a fully homomorphic encryption scheme, the reliniarization step can be avoided. For example, in the SEAL library, the function Evaluator::multiply(ct_0, ct_1) performs only the first step in the multiplication and outputs <math>(c_0,c_1, c_2) </math>, a ciphertext of size <math> 3</math>. Homomorphic operations are defined naturally on ciphertexts of arbitrary size and the decryption algorithm works well without reliniarization. The only problem with this approach is that the ciphertexts will grow with the number of homomorphic multiplications we perform, so one has to know a priori an upper bound on this number in order to choose parameters correctly. The problem of choosing parameters is also a delicate one. Increasing <math> q</math> while keeping <math> n </math> constant, one obtains more room for homomorphic multiplications (good), but the security of the scheme decreases (bad). This problem can be mitigated by increasing <math> n </math> as well.

==Making the scheme fully homomorphic== 

What is described above is a somewhat homomorphic encryption scheme. As all existing schemes that are based on [https://en.wikipedia.org/wiki/Learning_with_errors LWE] or [https://en.wikipedia.org/wiki/Ring_learning_with_errors ring-LWE], a small “noise” component is added to the message during encryption (the vectors <math>e_1,e_2 </math> sampled from the distribution <math> \chi </math> above). Computing homomorphically on ciphertexts will cause these noise to grow up to the point when it becomes so large (in practice, this happens when a certain norm of the vectors <math>e_1,e_2</math> is larger than <math> 1/2 \cdot \lfloor q/t \rceil </math> ) that decryption fails. The bootstrapping approach by Gentry can then be used to lower the noise in a ciphertext to a fixed level determined by the complexity of the decryption circuit. Gentry’s idea of bootstrapping is really simple, namely run
the decryption of the somewhat homomorphic scheme above in the encrypted domain, i.e. homomorphically. The result of this operation is an encryption of the same message, but with noise of a fixed
size. If the decryption circuit can be evaluated in depth D, then the noise after bootstrapping equals the noise one would obtain by evaluating a depth D circuit, which is
clearly independent of the starting noise present in the ciphertext. Therefore, if the scheme
can handle circuits of depth <math> D + 1 </math> , we can still handle one multiplication after bootstrapping and thus obtain a fully homomorphic scheme. The BFV scheme is designed such that it handles its own decryption circuit, therefore it can be turned into a fully homomorphic scheme via bootstrapping.

Unfortunately this is slow, and requires the encryption parameters <math>(n,q) </math>  to be large enough to support bootstrapping (not currently
implemented in SEAL for the BFV scheme).

== Applications ==

* CryptoNets: Applying Neural Networks to Encrypted Data
with High Throughput and Accuracy https://www.microsoft.com/en-us/research/publication/cryptonets-applying-neural-networks-to-encrypted-data-with-high-throughput-and-accuracy/

* Private queries on encrypted genomic data https://www.microsoft.com/en-us/research/publication/private-queries-encrypted-genomic-data/

* Logistic regression over encrypted data from fully homomorphic encryption https://www.microsoft.com/en-us/research/publication/logistic-regression-over-encrypted-data-from-fully-homomorphic-encryption-2/


== References ==