D-4.11 Modulus Bootstrapping
- Reference: Bootstrapping for BGV and BFV Revisited [14]
BGV’s bootstrapping shares some common aspects with both BFV and CKKS’s bootstrapping. The
goal of BGV’s bootstrapping is the same as that of CKKS, but the internal technique is closer to
that of BFV. Like CKKS, BGV’s bootstrapping resets the depleted ciphertext modulus from
(strictly
speaking, from
such that
because the bootstrapping operation itself consumes some multiplicative levels). This modulus transition
effectively not only resets the multiplicative level but also reduces the noise-to-ciphertext
modulus ratio. To achieve this goal, one might think that BGV’s bootstrapping can take
the same ModRaise approach used by CKKS’s bootstrapping. However, this is not a directly
applicable solution, because CKKS uses the sine approximation technique to eliminate the
-overflows
after the mod-raise. On the other hand, BGV is an exact encryption scheme which
does not allow approximation of plaintext values. Therefore, BGV uses BFV’s digit
extraction approach to eliminate its modulus overflows. To use digit extraction, like in the
case of BFV, BGV also has to modify the plaintext modulus to a specially prepared one,
.
To configure both the plaintext modulus and the ciphertext modulus to desired values (i.e.,
and
), BGV
uses the homomorphic decryption technique like BFV.
The technical details of BGV’s bootstrapping are as follows.
Suppose that we have an RLWE ciphertext ,
where ,
(a prime),
and is
the ciphertext modulus of the current multiplicative level.
-
1.
- Modulus Switch from :
BFV’s bootstrapping initially switches the ciphertext modulus from
where .
On the other hand, BGV’s bootstrapping switches the ciphertext modulus to
that is a special modulus satisfying the relation:
and
(where
will be explained in the next step). In order for a modulus switch from
(i.e., the special modulus) to be possible, the prime factor(s) comprising
have to be congruent with ,
so that we can do a modulus switch from
(based on the technique learned in §D-4.7). Eventually, this step’s modulus switch transforms the
ciphertext
to ,
during which the plaintext modulus (i.e., noise’s scaling factor) stays the same.
-
2.
- Ciphertext Coefficient Multiplication by :
The constant
is multiplied to each coefficient of the ciphertext polynomials, updating the ciphertext to ,
where
and .
This operation updates the original decryption relation
to
(where ).
Notice that the plaintext modulus (i.e., noise’s scaling factor) has been changed from .
When choosing ,
BGV enforces the following additional constraint:
and .
-
3.
- ModRaise: We mod-raise
to ,
where .
The mod-raised ciphertext’s decryption relation is as follows:
Note that
is the -multiple
overflow and does not get reduced modulo ,
because .
We saw the same situation in the CKKS bootstrapping’s ModRaise (§D-3.13.1) which resets the
ciphertext modulus from
at the cost of incurring a
overflow, which is to be removed by EvalExp’s homomorphic (approximate) sine graph evaluation
(§D-3.13.4). Likewise, BGV’s mod-raised ciphertext
is ,
an encryption of .
In the later step, we will use digit extraction to homomorphically eliminate
like we did in BFV’s bootstrapping. The reason BGV’s bootstrapping uses digit extraction
instead of approximated sine evaluation is that BGV is an exact encryption scheme like BFV
(not an approximate scheme like CKKS).
-
4.
- CoeffToSlot: This step works the same way as CKKS and BFV’s CoeffToSlot step: move the
coefficients of polynomial
to the input vector slots of a new ciphertext. We denote polynomial ,
and each -th
coefficient of
as .
For the CoeffToSlot step, we homomorphically compute .
Then, each input vector slot of the resulting ciphertext ends up storing each
of the polynomial .
-
5.
- Digit Extraction: At this point, each input vector slot contains each coefficient of ,
which is .
Recall that we designed the lowest multiplicative level’s ciphertext modulus
and the homomorphic multiplication factor
such that ,
or
for some positive integer .
Therefore, the following holds:
# applying
# rearranging the terms
# where
To eliminate
from the above, we will use the same digit extraction polynomial
as in BFV (§D-2.11.5) :
# where ,
and
can be any integer, and
We evaluate the digit extraction polynomial
for
recursively total
times, at each coefficient
of polynomial
stored at input vector slots. This operation finally zeros out the least significant (base-)
digits of
as follows:
, where
is some multiple of
to account for the original -overflow
term plus an additional -overflows
generated during the digit extraction. Note that the digit extraction step reduces the ciphertext
modulus from
(where
is an integer smaller than ),
because the homomorphic evaluation of the polynomial
requires some ciphertext-to-ciphertext multiplications, which consume some multiplicative levels.
-
6.
- Homomorphic Multiplication by :
The output of the digit extraction step is
stored in each input vector slot. We homomorphically multiply
to it, which is a modulo-
inverse of .
Note that
is guaranteed to exist because
is a finite field (i.e., Galois field) whose every element is guaranteed to have its counterpart inverse
(Theorem A-3.1 in §A-3.1). Multiplying
to
is equivalent to an exact division of
by ,
because
is exactly divisible by .
We homomorphically compute the following:
Note that the plaintext value
is also equivalent to
(because
divides ),
and is also equivalent to
(i.e., the message portion without the noise is ).
Therefore, homomorphically multiplying
to a ciphertext that encrypts
is equivalent to switching the plaintext modulus from .
In an alternative design, one can eliminate this step of homomorphic multiplication by
by re-designing the digit extraction algorithm to gradually shift down the digits by total (base-)
digits (by multiplying by
at the end of each round of digit extraction).
-
7.
- SlotToCoeff: This step works the same way as BFV’s SlotToCoeff step: move
stored in the input vector slots back to the polynomial coefficient positions by homomorphically
multiplying with .
Meanwhile, the coefficient domain is in modulo .
From modulo-’s
perspective, the result of step 5 is .
It is guaranteed that ,
because .
Therefore, result of SlotToCoeff is a set of polynomial coefficients whose noise is within the noise
budget of .
-
8.
- Noise Term Re-interpretation: The output of the SlotToCoeff step is ,
which also contains some noise term
generated during the homomorphic operations of step .
Therefore, we can view the
term in the plaintext as part of the noise of the ciphertext. In other words, we can view
with some noise term
as a ciphertext
with the noise term .
This step does not require any additional computation. The size of the coefficients of
is upper-bounded because the operations of the CoeffToSlot, digit extraction, and SlotToCoeff
steps are fixed. With a proper setup of the cryptographic parameters of BGV, we can guarantee
that the noise-to-ciphertext modulus ratio always gets decreased after BGV’s bootstrapping (i.e.,
,
where ,
and
denotes the maximum absolute coefficient value of polynomial ).
D-4.11.1 The Reason for Modulus Switch from
BGV switches the modulus from
to eliminate the -multiple
overflows during bootstrapping. After switching the modulus
and then ModRaise, the encrypted
plaintext gets the overflow
term, which can be reduced to
from the plaintext modulus’s perspective due to the special property
(where
is the
plaintext modulus).
D-4.11.2 ModRaise instead of Homomorphic Decryption
In the case of BFV’s bootstrapping, we need homomorphic decryption (§D-2.11.3)
because we need to simultaneously change the ciphertext’s plaintext scaling factor from
and the ciphertext
modulus from .
On the other hand, in the case of CKKS’s bootstrapping, ModRaise instead of homomorphic
decryption is sufficient because we only need to change the ciphertext modulus from
while keeping the same
plaintext scaling factor .
Similarly, in the case of BGV’s bootstrapping, ModRaise instead of homomorphic
decryption is sufficient because we only need to change the ciphertext modulus from
while keeping the noise scaling factor (i.e., the plaintext modulus)
.
D-4.11.3 The Choice of
The larger is, the
greater the (base-)
digit-wise gap between
and
becomes, and thus the less likely it is that the decryption would fail (i.e., fail to zero out
). But a
larger
means the digit extraction operation would be more expensive.
D-4.11.4 Generalization to
Like the case of BFV’s bootstrapping (Summary D-2.11.7 in §D-2.11.7), we can generalize the plaintext modulus (i.e.,
noise scaling factor) to
where is a
prime and
can be any positive integer.