BFV

Around 2012 Brakerski proposed a new efficient FHE scheme whose security is based on the LWE problem. Later on, this scheme was ported to the ring-LWE setting by Fan and Vercauteren. The various optimisations achieved by the last two authors made the scheme suitable for implementation. One such implementation is available in Microsoft SEAL 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 $n$ with coefficients modulo $t$, more precisely ${\mathcal {R}}_{t}=\mathbb {Z} _{t}[x]/(x^{n}+1)$. 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 $x^{n}$ being converted to $-1$. In this way, the result of ring operations on ${\mathcal {R}}_{t}$ is always a polynomial of degree strictly less than $n$.

The homomorphic operations on ciphertext, that will be described later, will carry through encryption to addition and multiplication operations in the plaintext ${\mathcal {R}}_{t}$.

If we wish to encrypt an integer or a rational number, then we need to encode it first into a plaintext polynomial in ${\mathcal {R}}_{t}$ and the result can be encrypted only after that. We mention that distinction should be made between encoding and encrypting data. The first one is a public operation, i.e. anybody can reverse it by decoding , 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 ${\mathcal {R}}_{t}$ 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 ${\mathcal {R}}_{q}$, for some different (much larger than $t$) integer $q$. These arrays contain at least two polynomials. Their length grows with each homomorphic multiplication, unless an operation called reliniarization is performed. The latter is a procedure which takes a ciphertext consisting of more than $2$ polynomials in ${\mathcal {R}}_{q}$ back to a ciphertext with $2$ polynomials encrypting the same message $m\in {\mathcal {R}}_{t}$.

Description of the scheme

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

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

• $SecretKeyGen(\lambda )$: This just samples $s\leftarrow {\mathcal {R}}_{2}$ and outputs the secre key $sk=s$.

• $PublicKeyGen(sk)$: Set $s=sk$, sample $a\leftarrow {\mathcal {R}}_{q}$ uniformly and $e\leftarrow \chi$ from an error distribution. Output the public key $pk=([-(as+e)]_{q},a)$.

• $EvaluationKeyGen(sk,w)$: for $i\in \{0,\dots ,l\}$, sample $a_{i}\leftarrow {\mathcal {R}}_{q}$ and $e_{i}\leftarrow \chi$. Output

$evk=([-(a_{i}s+e_{i})+w^{i}s^{2}]_{q},a_{i})$.

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 .

• $Encrypt(pk,m):$ For $m\in {\mathcal {R}}_{t}$, let $p_{k}=(p_{0},p_{1})$. Sample $u\leftarrow {\mathcal {R}}_{2}$ uniformly and $e_{1},e_{2}\leftarrow \chi$. Compute and output

$ct=([{\frac {q}{t}}\cdot m+p_{0}u+e_{1}]_{q},[p_{q}u+e_{2}]_{q})$ .

• $Decrypt(sk,ct)$: Set $s=sk,c_{0}=ct[0]$ and $c_{1}=ct[1]$. Output

$\left[\left\lfloor {\frac {t}{q}}\cdot [c_{0}+c_{1}s]_{q}\right\rfloor \right]_{t}$.

The homomorphic operations on ciphertext are as follows

• $Add(ct_{0},ct_{1}):$ Output $(ct_{0}[0]+ct_{1}[0],ct_{0}[1]+ct_{1}[1]).$

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

• $Multiply(ct_{0},ct_{1}):$ Compute

$c_{0}=\left[\left\lfloor {\frac {t}{q}}ct_{0}[0]ct_{1}[0]\right\rceil \right]_{q}$, $c_{1}=\left[\left\lfloor {\frac {t}{q}}(ct_{0}[0]ct_{1}[1]+ct_{0}[1]ct_{1}[0])\right\rceil \right]_{q}$ ,

and $c_{2}=\left[\left\lfloor {\frac {t}{q}}(ct_{0}[1]ct_{1}[1])\right\rceil \right]_{q}$.

This first step is quite easy. One can think of $ct_{i}$ as a polynomial $ct_{i}(x)=ct_{i}[0]+x\cdot ct_{i}[1]$ with coefficients in ${\mathcal {R}}_{q}$. What we did so far corresponds to computing the product of the polynomials $ct_{1}(x)$ and $ct_{2}(x)$, resulting in a (quadratic in $x$) polynomial $c_{0}+c_{1}x+c_{2}x^{2}$. This corresponds to a length $3$ array $(c_{0},c_{1},c_{2})$. To keep the size of the ciphertext small, we now apply a reliniarization step. The latter consists in computing

$c_{0}'=c_{0}+\sum _{i=0}^{l}evk[i][0]c_{2}^{(i)}$, $c_{1}'=c_{1}+\sum _{i=0}^{l}evk[i][1]c_{2}^{(i)}$ ,

and return as output the ciphertext $(c_{0}',c_{1}')$.

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 $(c_{0},c_{1},c_{2})$, a ciphertext of size $3$. 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 $q$ while keeping $n$ constant, one obtains more room for homomorphic multiplications (good), but the security of the scheme decreases (bad). This problem can be mitigated by increasing $n$ as well.