BFV

From certFHE Community KB
Revision as of 10:07, 30 December 2020 by Gturcas (talk | contribs) (→‎Overview of the BFV scheme)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Around 2012 Brakerski [1] 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. [2] The various optimisations achieved by the last two authors made the scheme suitable for implementation. One such implementation is available in Microsoft SEAL [3] 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 with coefficients modulo , more precisely . 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 being converted to . In this way, the result of ring operations on is always a polynomial of degree strictly less than .

The homomorphic operations on ciphertext, that will be described later, will carry through encryption to addition and multiplication operations in the plaintext .

If we wish to encrypt an integer or a rational number, then we need to encode it first into a plaintext polynomial in 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 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 , for some different (much larger than ) integer . 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 polynomials in back to a ciphertext with polynomials encrypting the same message .

Description of the scheme

Let be the security parameter. Let be a base (one can think of for the sake of presentation) and let denote the number of terms in the decomposition into base . Polynomials in will also be decomposed into base components coefficient-wise, resulting in polynomials. When is a set, we denote we denote the fact that is sampled uniformly from the set .

The BFV scheme has the algorithms and . We describe these below.

  • : This just samples and outputs the secre key .
  • : Set , sample uniformly and from an error distribution. Output the public key .
  • : for , sample and . Output
.

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 [4].

  • For , let . Sample uniformly and . Compute and output
.
  • : Set and . Output
.

The homomorphic operations on ciphertext are as follows

  • Output

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

  • Compute
,
,

and .

This first step is quite easy. One can think of as a polynomial with coefficients in . What we did so far corresponds to computing the product of the polynomials and , resulting in a (quadratic in ) polynomial . This corresponds to a length array . To keep the size of the ciphertext small, we now apply a reliniarization step. The latter consists in computing

,
,

and return as output the ciphertext .

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 , a ciphertext of size . 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 while keeping constant, one obtains more room for homomorphic multiplications (good), but the security of the scheme decreases (bad). This problem can be mitigated by increasing 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 LWE or ring-LWE, a small “noise” component is added to the message during encryption (the vectors sampled from the distribution 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 is larger than ) 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 , 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 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/


References

  1. Z. Brakerski. Fully Homomorphic Encryption without Modulus Switching from Classical GapSVP. CRYPTO 2012. http://eprint.iacr.org/2012/078.pdf
  2. 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
  3. Microsoft Research. Microsoft SEAL (release 3.5). 2020. https://github.com/Microsoft/SEAL
  4. K. Lane. Simple Encrypted Arithmetic Library. Microsoft Research. https://www.microsoft.com/en-us/research/uploads/prod/2017/11/sealmanual-2-3-1.pdf