1. Introduction
Homomorphic encryption (HE) is a cryptographic technology that enables computations to be performed directly on encrypted data. Dubbed the “holy grail” of cryptography, HE holds enormous application potential in the field of information security. Based on the scope of homomorphic computations supported, HE can be categorized into partial homomorphic encryption (PHE), leveled homomorphic encryption (LHE), and fully homomorphic encryption (FHE). Early research on HE focused on PHE, with representative schemes including the RSA scheme proposed by Rivest et al. [
1] and the Paillier encryption scheme [
2] developed later. The RSA scheme exhibits multiplicative homomorphism—decrypting the product of two ciphertexts yields the product of the corresponding plaintexts. In contrast, the Paillier scheme possesses additive homomorphism—decrypting the product of two ciphertexts results in the sum of the corresponding plaintexts. However, PHE schemes are highly restrictive as they only support either additive or multiplicative homomorphism. Decades after the concept of ‘homomorphic encryption’ was proposed, Gentry [
3] introduced a framework for constructing FHE, shifting academic focus from PHE to LHE and FHE. LHE supports both additive and multiplicative operations on ciphertexts, and the resulting new ciphertexts are encryptions of the corresponding plaintext sums or products. Nevertheless, LHE does not allow unlimited homomorphic computations—if the noise accumulated after each computation exceeds the scheme’s tolerance threshold, the ciphertext will fail to decrypt. Gentry’s FHE framework consists of LHE and bootstrapping. The core idea of bootstrapping is to execute a homomorphic decryption circuit on the ciphertext before the noise reaches the threshold. As long as the noise of the bootstrapped ciphertext remains sufficiently low to support one additional homomorphic operation, LHE can be transformed into FHE.
Existing bootstrapping methods primarily fall into three categories. The first category is tailored for BGV/BFV schemes [
4,
5,
6,
7], leveraging the Chinese remainder theorem (CRT) over polynomial rings. Its core idea involves re-encrypting the original ciphertext and then decrypting the inner-layer ciphertext of the new ciphertext. The second category is designed for the CKKS scheme [
8]. Since CKKS ciphertexts treat noise as part of the plaintext, the decryption function is replaced by an approximate modulus function, with the remaining steps closely resembling those of the first category. The third category is the bootstrapping based on blind rotation in TFHE schemes [
9,
10]. Unlike the previous two, blind rotation utilizes the negative cyclic property of the polynomial ring
. Through the iterative multiplication of the rotation polynomial with key-related monomials, specific coefficients of the rotation polynomial are rotated to the constant term in the encrypted state, thereby achieving homomorphic decryption. In TFHE, blind rotation consists of two types of ciphertexts (RLWE and RGSW) and their “external product”. Given the large size of these two ciphertext types, Bonte et al. [
11] proposed the NTRU-based FINAL scheme to reduce the size of bootstrapping keys. The FINAL scheme replaces RLWE and RGSW ciphertexts with scalar NTRU and vector NTRU ciphertexts, respectively. Since scalar NTRU ciphertexts consist of only one polynomial and since the size of vector NTRU ciphertexts is half that of RGSW ciphertexts, the NTRU-based bootstrapping algorithm not only offers superior space complexity but also requires fewer polynomial multiplications for executing the “external product” compared to TFHE. Subsequent works extended the NTRU-based blind rotation to MKHE scenarios, yet these schemes are tailored for the pure multi-key setting and lack architectural compatibility with the multi-group framework while also suffering from limitations such as symmetric-only bootstrapping key encryption and non-parallelizable bootstrapping execution.
The primary application of FHE is outsourcing computation, where data owners can encrypt their data and entrust it to untrusted computing service providers without revealing sensitive information. However, in secure multi-party computation (SMPC) scenarios, there is a need to compute data from multiple sources, rendering single-key FHE inadequate. To meet this demand, researchers have extended FHE to multi-party settings, leading to two main technical routes: static multi-party homomorphic encryption (MPHE) [
12,
13,
14] and dynamic multi-key homomorphic encryption (MKHE) [
15,
16,
17]. MPHE requires parties to be fixed prior to computation, with various keys generated collectively by all parties. Since encryption, decryption, and bootstrapping are performed under the same key, its computational efficiency is independent of the number of parties, ensuring high efficiency but limited flexibility. In contrast, MKHE does not require pre-computation negotiation among parties—each party generates its own key and participates in encryption, decryption, and bootstrapping without disclosing any key-related information. However, the size of multi-key ciphertexts is positively correlated with the number of parties, resulting in high flexibility but low computational efficiency. To balance flexibility and efficiency, Kwak et al. [
18] proposed a new HE primitive called multi-group homomorphic encryption (MGHE). MGHE treats ciphertexts of MPHE as single-key ciphertexts under a joint public key, while ciphertexts encrypted under joint public keys of different groups are computed jointly in a multi-key manner. Notably, the initial MGHE construction and its follow-up extensions exclusively adopt RLWE/RGSW-based bootstrapping methods (the first, second, and third categories mentioned above) and have not integrated the high-efficiency NTRU-based blind rotation; meanwhile, all existing NTRU-based MKHE schemes inherently lack support for parallel bootstrapping, which limits their efficiency and scalability in practical multi-key homomorphic evaluation scenarios. To leverage the advantage of low bootstrapping overhead in the NTRU-based FINAL scheme and address the issue that existing NTRU-based MKHE schemes do not support parallel bootstrapping, we focus our core solution on the proposed MGHE scheme. Specifically, the main contributions of this paper are as follows:
- 1.
A secret sharing-based bootstrapping key generation algorithm for the MGHE framework is proposed, which enables the MGHE framework to employ NTRU-based bootstrapping. The FINAL scheme lacks an asymmetric encryption variant, and existing NTRU-based blind rotation algorithms [
19,
20] employ symmetrically encrypted bootstrapping keys. To ensure compatibility between the proposed bootstrapping algorithm and NTRU-based blind rotation while maintaining low noise levels in bootstrapping keys, additive secret sharing is introduced in the offline phase before bootstrapping. Parties within the same group collectively negotiate and generate bootstrapping keys through operations such as addition and multiplication of secret shares.
- 2.
A multi-group hybrid product algorithm dedicated to NTRU-based blind rotation is proposed, realizing the parallelizable bootstrapping for MGHE in MKHE setting. To parallelize bootstrapping, the core steps of bootstrapping are divided into multiple subtasks by group. Each subtask independently performs blind rotation using the corresponding group bootstrapping key, and the outputs of the subtasks are aggregated using the multi-group hybrid product algorithm.
- 3.
Secure parameter sets were determined, with the effectiveness being verified through experiments. Since the FINAL scheme is based on NTRU, “overstretched” parameters render the scheme vulnerable to sublattice attacks. Through an analysis of the upper bound of noise, the parameters of the proposed scheme are ensured to remain within a secure range using LWE [
21] and NTRU estimators [
22]. Experiments were conducted under different parameter sets with the number of groups ranging from 2 to 8, validating the effectiveness of the proposed scheme.
2. Related Work
In MGHE, plaintexts within the same group are encrypted using a joint public key in the form of MPHE, while ciphertexts encrypted under joint public keys of different groups are computed in a multi-key manner. Thus, MGHE can be regarded as an extension of MPHE to multi-key scenarios. Current mainstream single-key HE schemes include BGV [
23], BFV [
24], CKKS [
25], and FHEW [
26]/TFHE [
9,
10]. Both MPHE and MKHE schemes are constructed on top of these single-key schemes, and existing MGHE schemes are all extended from MPHE/MKHE based on RLWE/RGSW primitives, with no prior work on NTRU-based MGHE construction.
2.1. Multi-Party Homomorphic Encryption Schemes
The earliest MPHE scheme was constructed by Asharov et al. [
27] based on the LWE-based BGV scheme. In this scheme, parties independently generate public keys, broadcast them, and compute the joint public key locally by summing the received public keys from other parties. Similarly, Mouchet et al. [
13] constructed an RLWE-based MPHE on the BFV scheme, which can be easily extended to BGV and CKKS schemes. FHEW/TFHE-type schemes employ two layers of ciphertexts: the first layer is basic LWE ciphertexts, and the second layer is RGSW ciphertexts for homomorphic decryption. Unlike BGV, BFV, and CKKS schemes, TFHE encodes the LWE secret key into the monomial
X and encrypts it into the second-layer ciphertext as the bootstrapping key, achieving homomorphic decryption through the blind rotation algorithm. Thus, constructing a multi-party TFHE scheme requires generating multi-party bootstrapping keys. Lee et al. [
28] realized the generation of multi-party blind rotation keys by leveraging homomorphic multiplication between RGSW ciphertexts, constructing a feasible multi-party bootstrapping algorithm. Subsequently, Park et al. [
29] built the first multi-party TFHE scheme based on this bootstrapping algorithm.
2.2. Multi-Key Homomorphic Encryption Schemes Based on Blind Rotation
As the fastest method for bootstrapping a single ciphertext, blind rotation is not only applicable to TFHE schemes but also compatible with all (R)LWE-based encryption schemes. Thus, blind rotation is a key technology for both MPHE and MKHE schemes. Chen et al. [
17] first extended TFHE to multi-key scenarios, proposing the CCS scheme. This scheme uses the hybrid product between multi-key RLWE ciphertexts and single-key Uni-Enc ciphertexts to replace the external product between multi-key RLWE and multi-key RGSW ciphertexts, achieving lower time and space overhead. Based on the hybrid product algorithm proposed by Chen et al., Kwak et al. [
30] constructed a generalized external product algorithm and designed a parallelizable multi-key LWE ciphertext bootstrapping algorithm (KMS scheme). The initial blind rotation algorithm, which used RLWE and RGSW ciphertexts as inputs, was later improved in the FINAL scheme by Bonte et al. [
11]. Based on the NTRU problem, their key modification was to replace these ciphertexts with the more compact scalar NTRU and vector ciphertexts, respectively. Since NTRU scalar and vector ciphertexts are smaller in size than are RLWE and RGSW ciphertexts, and fewer polynomial multiplications are required for their homomorphic multiplication, the overhead of blind rotation is reduced. Building on the FINAL scheme, Xu et al. [
31] proposed an MKHE scheme that achieves an approximately 5x speedup compared to the CCS scheme for two parties. However, this scheme controls noise accumulation during homomorphic computations by fixing the Hamming weight of NTRU keys, which Kim et al. [
32] pointed out compromises the scheme’s security, making it unsuitable for practical applications. Subsequently, Xiang et al. [
33] proposed the first practical multi-key NTRU ciphertext scheme based on NTRU. Distinct from the scheme put forward by Xu et al., the intermediate multi-key NTRU ciphertext employed in the bootstrapping algorithm of this scheme is structurally consistent with multi-key RLWE ciphertexts. Consequently, it can effectively mitigate noise growth while avoiding overstretched parameters. Nevertheless, this scheme shares the same limitation with Xu et al.’s construction, namely, the lack of support for parallel bootstrapping. Park et al. [
34] applied the hybrid product algorithm to the key switching key generation protocol, avoiding the invocation of the hybrid product during blind rotation, resulting in significant performance improvements over the CCS and KMS schemes. Nevertheless, it still does not support parallel execution.
2.3. Multi-Group Homomorphic Encryption Scheme
Currently, there are relatively few studies on constructing new multi-group homomorphic encryption schemes based on the MGHE framework proposed by Kwak et al. [
18], and all existing MGHE extensions are built on RLWE/RGSW-based primitives and have not integrated NTRU-based blind rotation or addressed the inefficiencies of RLWE/RGSW-based bootstrapping. To address the gap of TFHE-based MGHE construction, Wan et al. [
35] proposed the first MGHE scheme based on TFHE by relying on the original MGHE architecture. The bootstrapping algorithm of this scheme is consistent with that of the CCS scheme, directly migrating the RLWE/RGSW-based blind rotation and hybrid product from MKHE to the MGHE framework without customized optimization. Since the bootstrapping key of the CCS scheme is constructed based on RLWE and has a favorable linear structure, the joint bootstrapping key of each group only requires simple accumulation operations. The bootstrapping process of this scheme fully follows the execution paradigm of the CCS scheme, so it also inherits the inherent shortcomings of the CCS scheme. Therefore, the WLW scheme does not support parallel computing and suffers from slow bootstrapping due to the structure of RLWE/RGSW ciphertexts. Most importantly, this scheme and other existing MGHE works do not explore the integration of NTRU-based blind rotation with the MGHE framework, nor do they solve the technical challenges of NTRU-based bootstrapping key generation and parallel execution in the multi-group setting. This is the core research gap that our work addresses, and it is the key novelty that distinguishes our scheme from all existing MGHE and NTRU-based MKHE schemes.
3. Preliminaries
3.1. Notions
Boldface letters denote vectors (e.g., ), and the inner product between two vectors and is denoted as . denotes the ring of integers. For a given positive integer q, denotes the quotient ring , whose elements are integers in the interval . Similarly, given positive integers Q and N (where N is a power of 2), denotes the 2N-th cyclotomic ring, and the quotient ring consists of integer polynomials with coefficients in . indicates that the random variable e is sampled from the distribution . Similarly, denotes that the vector e is obtained by sampling n times independently from . For clarity, if e is a polynomial (even if its coefficients are sampled multiple times from a distribution), the former notation is still used. and denote the standard deviation and variance of a distribution, respectively. For a random variable a, denotes its variance if or the variance of its coefficients if . For a ciphertext c, denotes the ciphertext noise, and denotes the variance of the ciphertext noise. , , and denote the rounding function, ceiling function, and floor function, respectively. In secret sharing schemes, for a secret s, denotes the secret share belonging to the i-th party, and denotes the set of secret shares.
3.2. Hard Problems
Definition 1.
Decisional LWE problem [36]. Given positive integers q, n, and a distribution over , the decisional LWE problem is to distinguish between the following:
- 1.
Randomly sampled pairs ;
- 2.
Pairs , where is uniformly sampled from , is the i-th element of , is uniformly sampled from , is the i-th element of , and e is sampled from .
Definition 2.
Decisional RLWE problem [37]. Given positive integers Q, N, the polynomial ring , , and a distribution over R, the decisional RLWE problem is to distinguish between the following:
- 1.
Randomly sampled pairs ;
- 2.
Pairs , where are uniformly sampled from , and e is sampled from .
Definition 3.
Decisional NTRU problem [11]. Given positive integers Q, N, the polynomial ring , , and a distribution over R, let , with f invertible in . The decisional NTRU problem is to distinguish between the following:
- 1.
A randomly sampled element ;
- 2.
The element .
Definition 4.
Decisional Vector NTRU problem [38]. Given positive integers Q, N, d, the polynomial ring , , and a distribution over R, let with f invertible in . The decisional vector NTRU problem is to distinguish between the following:
- 1.
A randomly sampled vector ;
- 2.
The vector .
3.3. Gadget Decomposition
Gadget decomposition is a technique for decomposing an integer in
into multiple small integers in
. Given positive integers
B,
, and
, the gadget decomposition vector with base
B is defined as
. The decomposition function of the integer
a with base
B is given by the following:
where
. For brevity,
is denoted as
. Gadget decomposition is not limited to
but can also be extended to the polynomial ring
. For a polynomial
, it is treated as a coefficient vector, and the above conclusion holds by decomposing each element of the vector individually.
3.4. FINAL Scheme
The NTRU problem serves as a crucial hard problem for constructing post-quantum FHE schemes, and its parameter selection directly impacts the security of the cryptographic scheme. Schemes built on NTRU are vulnerable to sublattice attacks if “overstretched” parameters are used [
39]. To avoid overstretched parameters while ensuring the correctness of homomorphic operations, Bonte et al. proposed the FINAL scheme [
11]. Subsequently, Xiang et al. [
19] modified the ciphertext form of the scheme to construct their ring isomorphism-based blind rotation algorithm. The modified FINAL scheme is described as follows:
FINAL.Setup(): Input a security parameter , generate security-compliant parameters including the NTRU polynomial modulus Q, polynomial degree N, gadget decomposition base B, key distribution over R, and noise distribution over R. Output .
FINAL.KeyGen(): Input the parameters generated by the Setup algorithm, select an invertible polynomial from , and output the NTRU key f.
FINAL.ScalarEnc(
m,
f): Input a plaintext
and the NTRU key
f, randomly select noise
, set
as the scaling factor, and output the NTRU scalar ciphertext
FINAL.VectorEnc(
m,
f): Input a plaintext
and the NTRU key
f, randomly select noise
where
, and output the NTRU vector ciphertext
To implement the CMux gate, the TFHE scheme defines the external product between TRLWE and TRGSW ciphertexts. Similarly, the FINAL scheme defines the external product between scalar NTRU and vector NTRU ciphertexts and proves the upper bound of the noise variance for this external product operation.
Definition 5.
NTRU external product.
Let
denote a scalar NTRU ciphertext encrypting the plaintext
m with modulus
Q, scaling factor
, and NTRU key
f. Let
denote a vector NTRU ciphertext encrypting the plaintext
m with modulus
Q, gadget decomposition base
B, and NTRU key
f. The external product is defined as
where
Lemma 1.
Noise of NTRU external product.
Given positive integers
Q,
N,
B,
d, a scalar NTRU ciphertext
, and a vector NTRU ciphertext
, let
and
denote the noise of
c and
, respectively, and
and
denote their noise variances. Then, the noise variance of the ciphertext
satisfies
3.5. XZD Blind Rotation
The first automorphism-based blind rotation algorithm was proposed by Lee et al. [
28] (LMKC scheme). Unlike the AP scheme [
40], which achieves exponent accumulation through multiplication operations, the LMKC scheme leverages the automorphism map
to implement scalar multiplication on exponents, thereby significantly reducing the number of multiplication operations in the accumulator. Subsequently, the XZD scheme proposed by Xiang et al. [
19] further shortens the time required for key switching after multiplication in the accumulator by adopting scalar and vector NTRU ciphertexts, effectively reducing the overall computational overhead of blind rotation.
The order of the monomial
X over the 2N-th cyclotomic polynomial ring
is 2N, i.e.,
. Thus, for a positive integer
t, multiplying any element
by the monomial
results in a regular cyclic left or right shift of the polynomial’s coefficients. Blind rotation leverages this property to rotate specific coefficients to the leading term. Formally, given an element
, compute the rotation polynomial
For a ciphertext
satisfying
(where
is the LWE scaling factor,
q is the LWE ciphertext modulus, and
q divides 2N), the goal of blind rotation is to compute the following in the encrypted state
Before performing blind rotation, the XZD scheme preprocesses the ciphertext to be bootstrapped
by computing
ensuring the existence of the automorphism. Subsequently, the rotation polynomial is encrypted into a scalar NTRU ciphertext, and the monomial
(related to the
i-th component of the LWE secret key) is encrypted into a vector NTRU ciphertext. During blind rotation,
is iteratively multiplied into the rotation polynomial via the external product between the two types of ciphertexts, followed by key switching based on automorphism to multiply the ciphertext component
into the rotation polynomial.
The XZD blind rotation consists of two algorithms: the Blind Rotation Key Generation (BRKGen) algorithm and the Blind Rotation Evaluation (BREval) algorithm. Let be the public parameters output by , and . Define the set and let denote the LWE ciphertext encrypting the plaintext m with modulus q and secret key . The two algorithms are described as follows.
BRKGen(): Given an LWE secret key and an NTRU key , the algorithm outputs , where
- 1.
, for , ;
- 2.
.
BREval(
): Input an LWE ciphertext
, a rotation polynomial
r, the evaluation key
generated by BRKGen, and the NTRU scaling factor
. The algorithm computes and outputs
The detailed steps are presented in Algorithm 1.
| Algorithm 1 BREval( (adapted from [19]) |
Require: An LWE ciphertext A rotation polynomial Evaluation key Scaling factor Ensure: A scalar NTRU ciphertext - 1:
for to n do - 2:
- 3:
- 4:
end for - 5:
- 6:
- 7:
for to n do - 8:
- 9:
if then - 10:
- 11:
- 12:
end if - 13:
end for - 14:
- 15:
return
|
3.6. Additive-Only Multi-Party RLWE-Based Homomorphic Encryption
The core algorithms of the multi-party BFV scheme proposed by Mouchet et al. [
41] can be combined to form an additive-only (supporting scalar multiplication) multi-party RLWE homomorphic encryption scheme (AHE).
AHE.Setup(): Input a security parameter and output security-compliant public parameters including the RLWE ciphertext modulus Q, plaintext modulus t, polynomial degree N, secret key distribution over R, noise distribution over R, and a common reference polynomial . Output .
AHE.SKeyGen(): Each party selects an RLWE secret key .
AHE.PKeyGen(): Each party selects noise , computes , and sets .
AHE.JointPKeyGen(): Input the public keys of all parties, compute , and output the joint RLWE public key .
AHE.Enc(m): Input a plaintext , select noise , , randomly select a temporary secret polynomial , compute and , and output the ciphertext .
AHE.Dec(): Input a ciphertext encrypted under the joint RLWE public key and the RLWE secret keys of all parties and compute .
AHE.Add(): Input two multi-party RLWE ciphertexts and encrypting plaintexts under the same public key and compute and output .
AHE.ScalarMult(): Input a scalar polynomial and a multi-party RLWE ciphertext and compute and output .
4. Technical Overview and Structure
The core of the scheme proposed in this paper is parallelized bootstrapping, which consists of two phases: an offline phase for generating bootstrapping keys and an online phase for computing arbitrary function over ciphertexts. The online phase refers to rotating the plaintext corresponding to a ciphertext to the first term of the polynomial using the XZD blind rotation algorithm in
Section 3.5, and then extracting it into a new ciphertext with lower noise. The offline phase means that each group collaboratively generates a joint evaluation bootstrapping key (JEVK) with the same structure as that of the evaluation bootstrapping key (EVK) output by BRKGen through multiple rounds of communication within the group via multi-party computation technology based on secret sharing. This enables each group in MGHE to act as a single party in MKHE, thus allowing MGHE to perform bootstrapping in the manner of MKHE.
The parallel framework proposed in the KMS scheme partitions MKHE ciphertexts by secret keys. For an MKHE ciphertext involving k parties with respective secret keys , the decryption formula is roughly given by . Owing to this formulation, the decryption formula can be naturally decomposed into multiple subtasks, where each subtask computes the dot product . The partitioned ciphertexts are then processed independently (in parallel). Since the essence of bootstrapping is to homomorphically compute the decryption formula with all intermediate results remaining in the ciphertext domain, the outputs of these subtasks must be aggregated via the HybridProd algorithm at the final stage. This ultimately achieves the homomorphic computation of the complete decryption formula in the ciphertext domain. As the bootstrapping task is split into multiple subtasks, distributing these subtasks across different CPU cores makes the bootstrapping executed on each core equivalent to single-key bootstrapping.
To realize parallelized bootstrapping in our scheme, we also partition MGHE ciphertexts by groups, where the homomorphic decryption subtask on each core is implemented via the XZD blind rotation algorithm for single-key ciphertexts presented in
Section 3.5. To adapt to the parallel framework of the KMS scheme, we designed the MGHybridProd algorithm for MGHE ciphertexts, which has identical functional logic to the HybridProd algorithm in the KMS scheme. The multi-group hybrid product key (HPK) for the MGHybridProd algorithm is also generated on a per-group basis. Since most bootstrapping materials are generated via multiplication over secret sharing, we precompute multiplication triples for this purpose. In our scheme, the generation of multiplication triples is realized by the additive-only multi-party RLWE-based homomorphic encryption scheme introduced in
Section 3.6.
The overall workflow of our proposed scheme is illustrated in
Figure 1. First, each group sequentially executes the TripleGen, Enroll, JBRKGen, LKSKeyGen, and MGHPKeyGen algorithms in the offline phase to acquire three types of bootstrapping keys including
,
, and
. Several parties in each group then invoke MGHE.Enc to encrypt plaintexts and generate multiple ciphertexts, and each group subsequently transmits these ciphertexts and bootstrapping keys to the server. The server employs the received keys and ciphertexts to evaluate a circuit that corresponds to the target function Func, and such circuits are constructed with homomorphic NAND gates. Each homomorphic NAND gate is formed by a NAND operation and a single bootstrapping operation. The bootstrapping algorithm we proposed follows a specific procedure where the ciphertext is first split into several components, the BREval algorithm is then applied to each component individually, the components are aggregated through the MGHybridProd algorithm, and the bootstrapped ciphertext is finally output via key switching.
In the following, we present the basic circuit-model-based MGHE scheme in
Section 5. This scheme is not a fully homomorphic encryption (FHE) scheme capable of evaluating arbitrary functions, yet it can obtain the capability of homomorphically computing arbitrary functions by incorporating the bootstrapping operation, which entails reducing ciphertext noise through homomorphic decryption. In
Section 6, we divide bootstrapping into the offline phase and the online phase and elaborate on its specific implementation in detail.
5. Basic Multi-Group LWE-Based Homomorphic Encryption Without Bootstrapping
This section first introduces the basic LWE-based multi-group homomorphic encryption scheme.
Parties in each group encrypt plaintexts using the group joint public key to obtain ciphertexts , which are then sent to the server. After receiving the ciphertexts, the server performs homomorphic computation and bootstrapping and returns the new ciphertext to be decrypted. Under the MGHE framework, our basic scheme includes two sets of algorithms: The first set includes SKeyGen, PKeyGen, JointPKeyGenm, and Enc, which are dedicated to intra-group interactive computation, while the second set includes Setup, NAND, and Dec, which are for inter-group computation. In addition, to support asymmetric encryption while maintaining a small ciphertext modulus, we distinguish between the encryption modulus and the bootstrapping modulus q. The encryption modulus is much larger than q, and ciphertexts under the encryption modulus can tolerate greater noise. After encrypting a plaintext, a party needs to switch the ciphertext modulus to the bootstrapping modulus q through the ModulusSwitch algorithm to perform subsequent NAND and bootstrapping algorithms.
Let be a set of parties, denote the i-th group, j be the unique index of the party in the i-th group within , and denote the j-th party in the i-th group. Our MGHE includes the following algorithms.
MGHE.Setup(): Takes a security parameter as input and generates global parameters meeting security requirements, including LWE encryption modulus , LWE bootstrapping modulus q, LWE dimension n, LWE secret key distribution over , noise distribution over , and a common reference matrix . Outputs .
MGHE.SKeyGen(): Parties in each group independently generate a private LWE secret key and output the LWE secret key .
MGHE.PKeyGen(): Party selects noise , computes , and sets .
MGHE.JointPKeyGen(): Takes the LWE public keys of each party in a group , computes , and outputs the LWE joint public key .
MGHE.Enc(): Takes a plaintext bit and the LWE joint public key of a group as input, randomly selects a temporary secret vector , noise and , computes and , and outputs the LWE ciphertext , encrypting the plaintext m under the joint LWE public key .
MGHE.ModulusSwitch(): Takes the LWE ciphertext generated by the MGHE.Enc algorithm and the LWE bootstrapping modulus q for bootstrapping and computes and outputs .
MGHE.Dec(): Takes the multi-group LWE ciphertext and the LWE secret keys of each party in each group as input, computes , and outputs .
MGHE.NAND(): Takes two multi-group LWE ciphertexts and encrypted under the same set of public keys , which encrypt plaintext bits respectively. For , lets and , computes , and outputs the ciphertext encrypting the plaintext m NAND .
RLWE is a ring variant of LWE. The above multi-group homomorphic encryption scheme can be constructed based on RLWE. Since the RLWE-based multi-group scheme operates on the ring , the main difference between the RLWE-based multi-group homomorphic encryption scheme and the above LWE-based scheme lies in the encryption and decryption algorithms. Let the RLWE joint public key be . In the encryption algorithm, we compute and , where is a secret polynomial, and and are selected from a distribution over a certain polynomial ring. We denote as the multi-group RLWE ciphertext encrypted by the RLWE joint public keys of k groups, with the corresponding secret keys . The ciphertext satisfies , where is a scaling factor.
The encryption scheme in this paper is based on Boolean circuits. Since the NAND gate has functional completeness, we can use the NAND gate as the basic unit to construct any Boolean function. Since homomorphic computation is performed under the circuit model, the bootstrapping scheme introduced in this paper belongs to gate bootstrapping. That is, homomorphic decryption is performed immediately after computing a NAND gate, and the scaling factor is converted from to to support the next homomorphic NAND computation.
Lemma 2.
Correctness of Homomorphic NAND gate.
Given two MGHE ciphertexts , and that encrypt the plaintexts m and respectively, with a scaling factor of and an inserted noises denoted as e and whose absolute noise value is less than , the NAND algorithm outputs a ciphertext with a scaling factor of and an absolute noise value less than , which encrypts the plaintext m NAND .
Proof. Denote the corresponding secret key of
as
. Since
, subtracting the noisy encoded plaintext of this ciphertext from its encoded plaintext yields it noise:
Since the absolute values of e and are less than , the absolute value of the noise in the new ciphertext c is less than . This completes the proof. □
After multiple gate bootstrapping operations, the decryption algorithm MGHE.Dec requires each party in each group to execute an interactive protocol called “distributed decryption” to ensure the security of the joint key. The current mainstream implementation is based on the smudging lemma in the AJL scheme [
27]. Each party samples an super-polynomially large smudging noise
from a large noise distribution, computes
, and broadcasts it to mask the intermediate results during the decryption process. To ensure the correctness of decryption, the ciphertext modulus also needs to be set very large. However, in our multi-group ciphertext bootstrapping algorithm based on NTRU and LWE, since the NTRU ciphertext modulus
Q cannot be super-polynomially large, this method is not applicable.
For such schemes with limited ciphertext modulus, the KLO scheme proposed by Kraitsberg et al. [
42] constructs a secure three-party distributed decryption protocol using garbled circuit (GC), and the scheme can be extended to more parties. Although this decryption protocol requires additional communication overhead, no additional noise needs to be introduced, so the parameters of the encryption scheme do not need to be adjusted. In our scheme, we adopt the distributed decryption mechanism of the KLO scheme and implement the decryption computation via garbled circuits. The decryption formula
holds correctly as long as the noise
e satisfies
, i.e.,
. Crucially, the decryption procedure built on garbled circuits reveals no extra information other than the final plaintext
m—it leaks no intermediate values, noise terms, or private inputs of each party. This non-leakage property ensures the decryption phase introduces no additional security vulnerabilities and preserves the message privacy, which lays a solid foundation for our subsequent IND-CPA security analysis. Further implementation details of the distributed decryption can be found in the original KLO scheme [
42].
6. Bootstrapping for Multi-Group LWE Ciphertext
This section introduces how to bootstrap multi-group LWE ciphertexts. Bootstrapping can be divided into two parts: bootstrapping key generation (offline phase) and bootstrapping execution (online phase). In the blind rotation key output by the BRKGen algorithm, the NTRU key takes the form of a denominator, which must be invertible. To enable MGHE to perform computations in the MKHE manner, we assign an associated joint NTRU key F to each group and define , where each denotes an invertible NTRU key randomly selected by each party in the group, and this construction guarantees the invertibility of F. Setting the joint NTRU key as the product of all confers a distinct advantage, as the distribution of joint key shares can be realized through multiplication operations in secret sharing, and secret recovery only requires all parties to conduct a simple summation of their respective shares. By this approach, we can convert the non-linear F into its linearized secret shares, and this linearity will provide critical support for the subsequent generation of the remaining bootstrapping keys. Therefore, we can design a multi-group hybrid product algorithm suitable for multi-group ciphertexts to realize the multiplication between different types of ciphertexts and further construct a parallelizable bootstrapping algorithm.
6.1. Offline Phase
This section presents a systematic elaboration on the offline phase of bootstrapping, which takes the additive secret sharing technique introduced in
Section 6.1.2 as its core technical foundation. The implementation of multiplication operations over additive secret sharing relies on the multiplication triple generation algorithm proposed in
Section 6.1.1. Analysis shows that both the HybridProd algorithm in the KMS scheme and the XZD blind rotation key generation algorithm BRKGen frequently invoke the joint NTRU key
F, its inverse
, and the value
associated with each party’s secret key. For this reason, we perform unified precomputation on these reusable parameters via the Enroll algorithm; the remainder of this section will elaborate on the generation algorithms for the multi-group hybrid product key (MGHPKeyGen) and joint blind rotation key (JBRKGen) in turn.
6.1.1. Generating Polynomial Multiplication Triples
The multiplication triple
was proposed by Beaver [
43] to reduce the number of communication rounds in secret sharing multiplication, thereby converting communication overhead into precomputation overhead in the offline phase. Existing multiplication triple generation schemes mainly include the MASCOT scheme [
44] based on oblivious transfer (OT) and the low/high gear scheme [
45] based on additive-only homomorphic encryption (AHE). However, the triple elements generated by these schemes are all values over the integer ring (field), which cannot be used for secret multiplication over the polynomial ring
. Therefore, we design a multi-party multiplication triple generation algorithm, TripleGen, that supports polynomial secret multiplication according to the framework proposed in [
46]. The algorithm comprises two sub-algorithms: the Setup sub-algorithm is used to initialize public parameters, and the EvalGen is used to generate triples.
TripleGen.Setup(): Successively executes AHE.Setup, AHE.SKeyGen, AHE.PKeyGen, and AHE.JointPKeyGen and outputs public parameters , secret keys of each party, and joint public key .
TripleGen.EvalGen(): Takes the public parameters output by TripleGen.Setup, the secret keys of each party, and the joint public key as input and outputs a random polynomial multiplication triple. For the detailed specifications, refer to Algorithm 2.
When performing decryption in the fifth step, we also need to use a distributed decryption protocol. The difference is that party does not need to broadcast its partial decryption result, while other parties need to send their partial decryption results to . This asymmetric decryption method ensures that no party other than knows the decryption result. Since the AHE scheme can adopt the distributed decryption approach from the AJL scheme (one round of communication), the TripleGen.EvalGen algorithm requires rounds of communication.
Let the secrets corresponding to the triple shares output by the algorithm be
. Since we need
to hold over the ring
, the plaintext modulus
t of AHE is required to be larger than the coefficients of
c to ensure that the
c output by the algorithm is not implicitly modulo
t.
| Algorithm 2 TripleGen.EvalGen() |
Require: AHE public parameters . Set of RLWE secret keys has each belonging to . Joint RLWE public key . Ensure: Polynomial multiplication triple . - 1:
For , party randomly selects from a symmetric three-point distribution (probability for taking values −1 or 1 and for taking value 0), computes , and sends it to . - 2:
computes C=AHE.Add(AHE.Add(… AHE.Add( and broadcasts it to all parties. - 3:
For , party computes =AHE.Enc(0), =AHE.Add(AHE.ScalarMult(), and then sends to . - 4:
For , party randomly selects a polynomial from the symmetric three-point distribution, computes =AHE.Enc(), and sends it to . - 5:
computes =AHE.Add(…AHE.Add(), =AHE.Add(AHE.Add(…AHE.Add(), =AHE.Dec(). - 6:
let . - 7:
return
|
In the second step of the algorithm, party broadcasts the ciphertext C, which encrypts , and the upper bound of its plaintext coefficients is k. In the third step, each party computes the ciphertext , which encrypts the plaintext , with the upper bound of coefficients being . Similarly, the ciphertext in the fifth step encrypts , with the upper bound of plaintext coefficients being . The ciphertext encrypts , with the upper bound of its coefficients being . Therefore, to ensure correctness, it is required that .
6.1.2. Additive Secret Sharing over Polynomial Ring
In additive secret sharing, a secret dealer splits a secret into
k secret shares and distributes them to
k parties
. To reconstruct the secret, it is only necessary to simply sum the secret shares of each party. It should be noted that the secret cannot be reconstructed with fewer than
k secret shares. The classic additive secret sharing is defined over the integer ring (field) [
47], and we extend it to the polynomial ring
. Since the secret shares are elements over the polynomial ring, we add an automorphism algorithm. Therefore, additive secret sharing over polynomial rings has a total of 6 algorithms (all operations are implicitly performed over the polynomial ring
), as follows.
ASS.Split(s): Takes a secret belonging to as input. For , party randomly selects elements in , computes , and distributes the secret share of the secret s to party .
ASS.Recover(): Each party broadcasts the share of the secret s. After collection of sent by the other parties, computes .
ASS.Add(): Takes the secret shares of secrets x and y as input. For , party locally computes and outputs the secret shares of the secret .
ASS.ScalarMult(): Takes the secret shares of the secret x and a polynomial as input. For , party locally computes and obtains the secret shares of the secret .
ASS.Mult(): Takes the secret shares and of secrets x and y and the secret shares , , and of the multiplication triple as input. Each party locally computes , and broadcasts them. After receiving the broadcasts from other parties, party locally recovers the secrets and . For , locally computes ; for other parties , locally computes .
ASS.Auto(): Takes the secret shares of the secret x and an automorphism as input. For , party locally computes and obtains the secret shares of the secret .
In the same computation task, the multiplication triple input to the ASS.Mult algorithm cannot be reused; otherwise, other parties can infer the corresponding secret. For brevity, the parameter passed to ASS.Mult in the following is a set of triple slices, and the used triple is discarded after each call to secret multiplication. Meanwhile, if the number of parties k is already clear in the following, we use instead of to denote the secret shares of the secret x.
6.1.3. Party Enroll
This section presents the Enroll algorithm, which computes the reusable parameters repeatedly utilized in the scheme proposed in this paper via the additive secret sharing technique.
Enroll(): Takes the LWE secret key and its corresponding NTRU key of each party in a group as input and outputs , which respectively denote the secret share of the joint NTRU key F, the secret share of (multiplicative inverse of F), the secret share of the secret key, and the secret share of the negative sum secret keys. The algorithm is presented in Algorithm 3.
| Algorithm 3
|
Require: LWE secret key of all parties in the group NTRU key of all parties in the group Set of multiplication triples Ensure: Secret shares - 1:
For , each party computes =ASS.Split(), =ASS.Split(), = ASS.Split(), and =ASS.Split() and broadcasts the corresponding secret shares to other parties in the network. - 2:
For , computes =ASS.Split(1), =ASS.Split(1), =ASS.Split(1), =ASS.Split(1), and = ASS.Split(1). - 3:
for j in do - 4:
=ASS.Mult() ▹ corresponding to - 5:
=ASS.Mult() ▹ corresponding to - 6:
for to n do - 7:
=ASS.Mult( ▹ corresponding to - 8:
=ASS.Mult() ▹ corresponding to - 9:
end for - 10:
end for - 11:
- 12:
return
|
Lines 1 and 2 of the algorithm can be merged, and Lines 3 to 10 can be finished in one round of communication. Thus, the Enroll algorithm only requires rounds of communication. The secret shares , ,, are key information for generating the evaluation key in the XZD scheme. After obtaining the share sets of these four components, we can easily generate the joint bootstrapping key(multi-group version of ) in the multi-group scenario using additive secret sharing.
6.1.4. Multi-Group Hybrid Product
The hybrid product algorithm was proposed by Chen et al. [
17] in the MK-TFHE scheme in 2019 to support the product between multi-key RLWE ciphertexts and single-key Uni-Enc ciphertexts for constructing CMux gates in the multi-key scenario. Subsequently, Kwak [
30] generalized it to support the multiplication of single-key RLEV ciphertexts and multi-key RLWE ciphertexts, thereby realizing the parallelization of blind rotation. In our parallelized bootstrapping scheme, since the intermediate ciphertext of bootstrapping is a single-group NTRU ciphertext rather than a single-key RLEV ciphertext, we propose a multi-group hybrid product algorithm to support the parallelization of bootstrapping, which includes the hybrid product key generation(MGHPKeyGen), as well as the hybrid product(MGHybridProd) that takes scalar NTRU ciphertexts and multiple sets of ciphertexts as inputs.
MGHPKeyGen(
): Takes the RLWE secret key
of the
j-th party
in group
G and the secret share
of the joint NTRU key
F as input and randomly selects a common reference polynomial vector
; each party selects a secret polynomial
from the noise distribution over the ring
R and noise polynomial vectors
. Denote
and
as the decomposition base and decomposition degree of the ciphertext modulus
Q, respectively, and
as the corresponding decomposition vector. For
,compute
Then output .
MGHybridProd(
): Takes the MGRLWE public keys
, the
output by the
i-th group after executing MGHPKeyGen, the multi-group RLWE ciphertext
encrypting the plaintext
m, and the vector NTRU ciphertext
encrypting the plaintext
as input. For
, lets
, where
is the polynomial vector shared by multiple groups in MGHPKeyGen, computes
and then updates
Outputs the multi-group RLWE ciphertext encrypting the plaintext .
6.1.5. Joint Blind Rotation Key Generation
The JBRKGen algorithm generates multi-group version of the in the XZD scheme via additive secret sharing; specifically, it implements the encryption algorithm in the FINAL scheme using various algorithms under the framework of additive secret sharing and completes the encryption of the relevant keys in accordance with the flow of BRKGen algorithm in the XZD scheme.
JBRKGen(): Takes , , , and output by the Enroll algorithm and a set of multiplication triples as input and outputs the joint bootstrapping key . The details are as shown in Algorithm 4.
| Algorithm 4 JBRKGen() |
Require: Secret shares Set of multiplication triples Ensure: Joint bootstrapping key - 1:
For , each party randomly selects noise and and computes = ASS.Split(, = ASS.Split(), computes =ASS.Split(0), and =ASS.Split(0), and broadcasts the corresponding secret shares to other parties in the network. - 2:
for j in do - 3:
for to do - 4:
for to do - 5:
= ASS.Add() - 6:
end for - 7:
for u in S do - 8:
= ASS.Add() - 9:
end for - 10:
end for - 11:
end for - 12:
for to do - 13:
for to do - 14:
if then - 15:
- 16:
else if then - 17:
- 18:
else - 19:
- 20:
end if - 21:
end for - 22:
end for - 23:
for u in S do - 24:
for to do - 25:
- 26:
end for - 27:
end for - 28:
for to do - 29:
- 30:
end for - 31:
for u in S do - 32:
- 33:
end for - 34:
. - 35:
return
|
The broadcast in Line 1 of the algorithm requires one round of communication. The intermediate values computed via secret multiplication in Lines 12–27 are mutually independent, thus requiring only one round of communication. The secret reconstruction in Lines 28–33 also needs one round of communication. Therefore, the algorithm requires rounds of communication in total.
6.1.6. LWE Key Switching
LWE key switching is used to switch the secret key of an MGLWE ciphertext to another one. For completeness, we present the generation of the LWE key switching key and the corresponding switching algorithm. Note that only the generation of the LWE key switching key takes place in the offline phase, whereas the key switch procedure is invoked in the online phase.
LKSKeyGen(): Takes the LWE secret keys and of party in the group as input, randomly selects a matrix within the group, randomly samples the noise for , computes , denotes , and outputs .
LKeySwitch(): Takes the MGLWE ciphertext as well as the key switching key for the i-th group as input, denotes for , computes , , and outputs .
Since the generation of the LWE key switching key only requires each party to broadcast, accumulate, and aggregate its locally generated share, it incurs merely one round of communication. Furthermore, this communication round can be merged into the communication of JBRKGen, thereby eliminating this extra round.
6.2. Online Phase
The online phase of bootstrapping refers to the process where the server performs homomorphic computation on ciphertexts with high noise levels using the bootstrapping key to reduce the noise level of the ciphertexts. For the online phase, we design a parallelizable bootstrapping algorithm named BootMGCT, which is composed of the BREval and MGHybridProd algorithms mentioned above, as well as all core sub-algorithms introduced in
Section 6.2.1.
6.2.1. Core Algorithms for Bootstrapping
This subsection introduces other core algorithms for multi-group ciphertext bootstrapping, including the sample extraction algorithm SampleExt for extracting multi-group LWE ciphertexts from multi-group RLWE ciphertexts and the ModSwitch algorithm for switching the modulus of multi-group LWE ciphertexts.
SampleExt(): Takes the MGRLWE ciphertext as input, denotes as the j-th coefficient of the polynomial , sets and for , and outputs .
ModSwitch(): Takes the MGLWE ciphertext , the original modulus Q and the new modulus q as input, computes and for , and outputs the new ciphertext .
6.2.2. Parallelizable Multi-Group Ciphertext Bootstrapping Algorithm
In this subsection, we formally describe the multi-group LWE ciphertext bootstrapping algorithm based on LWE and NTRU proposed in this paper. The algorithm takes a multi-group LWE ciphertext to be bootstrapped and some precomputed bootstrapping materials as inputs and outputs a multi-group LWE ciphertext with a lower noise that encrypts the same plaintext.
In the proposed multi-group homomorphic encryption scheme, bootstrapping involves three types of keys: LWE secret keys, RLWE secret keys, and NTRU keys. For and , let and denote the LWE secret key, RLWE secret key, and NTRU key of , respectively. Let Q, , and q denote the ciphertext modulus of NTRU/MGRLWE, the LWE key switching modulus, and the LWE bootstrapping modulus, respectively, with . We define the following precomputed materials.
- 1.
Set of multiplication triples: TripleGen.
- 2.
Secret shares generated by Enroll algorithm of parties in group :
Enroll.
- 3.
Joint bootstrapping key of group : JBRKGen.
- 4.
Multi-group hybrid product key of group : MGHPKeyGen.
- 5.
LWE key switching key of group : LKSKeyGen.
We define the multi-group ciphertext bootstrapping algorithm BootMGCT in Algorithm 5.
| Algorithm 5
|
Require: Noisy MGLWE ciphertext . Rotation polynomial . Joint blind rotation keys . Hybrid product key . LWE key switching key . Ensure: Refreshed MGLWE ciphertext - 1:
. - 2:
for to k do - 3:
for to do - 4:
- 5:
end for - 6:
end for - 7:
Parse . - 8:
for to k do - 9:
- 10:
end for - 11:
() - 12:
- 13:
() - 14:
- 15:
- 16:
return
|
The core and most time-consuming operation of the BootMGCT algorithm is BREval, i.e., the XZD blind rotation algorithm. While BREval invokes at most polynomial multiplications, and a single execution of MGHybirdProd requires polynomial multiplications, it follows that the BootMGCT algorithm requires a total of polynomial multiplications. Through group-wise partitioning of the MGLWE ciphertext (splitting the original ciphertext into multiple ), we remove the input dependency on , thus enabling the invocations of BREval to be executed independently and in parallel across multiple CPU cores. In contrast, this step can only be performed serially on a single CPU core. This distinction in execution modes corresponds to the serialized and parallelized bootstrapping approaches described the experimental section below.
Theorem 1.
Correctness of algorithm BootMGCT.
Given a noisy MGLWE ciphertext and a rotation polynomial , along with the joint blind rotation keys (JEVKs), hybrid product keys (HPKs), and LWE key switching keys (LKSKs) of each group, the algorithm BootMGCT outputs an refreshed MGLWE ciphertext encrypted under the original public key, which encrypts the same plaintext as the input noisy MGLWE ciphertext.
Proof. We prove the theorem by analyzing the execution process of each step in the algorithm, verifying that the output MGLWE ciphertext maintains the consistency of the encrypted plaintext while reducing noise and is encrypted under the original public key.
Line 1 of the algorithm stores
into the accumulator ACC. Lines 2 to 6 split the MGLWE ciphertext on a group-wise basis and input it into the BREval algorithm to obtain the partial bootstrapping result (
). These two values are taken as inputs to perform
k rounds of iteration (MGHybridProd), outputting the multi-group RLWE (MGRLWE) ciphertext encrypted under the joint RLWE public key of each group. Specifically, the ciphertext encrypts the value of the expression
, which corresponds to the blind rotation formula given in Equation (
8).
Since the leading coefficient of is the plaintext to be extracted, we employ the SampleExt algorithm in Line 11 to extract the MGLWE ciphertext encrypting the leading coefficient of from the MGRLWE ciphertext output above. As this coefficient is either or 1, Step 12 accumulates into ACC, mapping its value to either 0 or 1.
Lines 13–15 perform the key switching of the MGLWE ciphertext to the key of the noisy ciphertext input by the BootMGCT algorithm, and the ACC stores a low-noise MGLWE ciphertext with as the scaling factor at the conclusion of the algorithm.
Therefore, the algorithm outputs an MGLWE ciphertext encrypted under the original public key, which encrypts the same plaintext as the input noisy MGLWE ciphertext. The theorem is thus proved. □
7. Noise Analysis
This section analyzes the noise generated by the proposed bootstrapping algorithm. For an input multi-group LWE ciphertext , the noise of the output ciphertext originates from BREval, MGHybridProd, ModSwitch, and LKeySwitch. We analyze the noise output by each of these algorithms separately and finally derive the total noise output by the bootstrapping algorithm.
The LWE scheme has parameters , q, , , , and n, which correspond to the LWE ciphertext modulus of MGHE.Enc, the LWE ciphertext modulus for bootstrapping, the ciphertext modulus for key switching, the gadget decomposition base, the gadget decomposition degree, and the LWE dimension, respectively. The RLWE/NTRU scheme has parameters Q, , and , N, which correspond to the RLWE/NTRU ciphertext modulus, the corresponding gadget decomposition base, the gadget decomposition degree, and the degree of the polynomial in the RLWE/NTRU ciphertext, respectively. Two bootstrapping schemes are involved in the bootstrapping process: LWE and RLWE/NTRU, with noise distributions and (corresponding variances and ) and key distributions and (corresponding variances and ). For the convenience of analysis, we assume that there are k groups participating in the computation, and each group has K parties.
Lemma 3.
Noise variance of BREval [19]. Let
denote the noise variance of the input
and
. For the ciphertext
c output by the BREval algorithm, the noise variance of
c satisfies
Proof. The BREval algorithm performs at most external products between scalar NTRU ciphertexts and vector NTRU ciphertexts. The rotation polynomial can be regarded as a vector NTRU ciphertext with zero noise. Hence, we complete the proof via Lemma 1. □
Lemma 4.
Noise variance of MGHybridProd.
Given a multi-group RLWE ciphertext
c with noise variance
, the noise
of the ciphertext
output by the MGHybridProd algorithm satisfies
Proof. Assume that the noise variance of the multi-group RLWE ciphertext
c encrypting the plaintext
m before MGHybridProd is
and that the noise variance of the ciphertext
encrypting the plaintext
after MGHybridProd is
. Let
Z denote the group joint RLWE secret key, and
R and
E denote the sums of
r and
e defined in the algorithm, respectively. According to the MGHybridProd algorithm, the noise
of the new ciphertext satisfies
Given that is a monomial with an absolute coefficient value of 1, the variance of the first term is . Since , it follows from Lemma 1 that . As and are the sum of the RLWE secret keys held by K parties, we can derive that . Accordingly, the variance corresponding to the second term in the noise expression is . On the other hand, and are both accumulations of random variables independently selected by K parties, which means their variances are and , respectively. Based on this, the variance of the third term in the expression can be expressed as . Similarly, the variance of the fourth term is given by , and the variance of the last term is . By integrating and rearranging all the aforementioned variance terms, the lemma is thus proved. □
Lemma 5.
Noise variance of ModSwitch.
Given positive integers
Q,
q, a multi-group LWE ciphertext
with noise variance
and the corresponding joint LWE secret key
, a new ciphertext
is obtained after modulus switching. The noise
of the new ciphertext satisfies
Proof. Consider an original ciphertext with modulus q, LWE dimension n, and secret keys of each party in each group, which needs to be switched to modulus Q. After modulus switching, , where . Here, denotes the rounding error, which follows a uniform distribution over . The noise satisfies , thus . □
Lemma 6.
Noise variance of LKeySwitch.
Given a multi-group LWE ciphertext
with LWE dimension
N encrypted under
k joint RLWE secret key coefficient vectors
, the LWE key switching algorithm outputs a multi-group LWE ciphertext
with LWE dimension
n encrypted under
k LWE joint secret keys
. The noise variance of the new ciphertext
satisfies
Proof. The components of the joint LWE secret key corresponding to the ciphertext
output by the LKeySwitch algorithm are denoted by
. The corresponding noise
satisfies
□
Since the variance of is , it follows that .
Theorem 2.
Noise variance of the multi-key bootstrapping algorithm
Given a ciphertext
to be bootstrapped with noise variance
, a rotation polynomial
r, joint bootstrapping keys
, hybrid product keys
,
, and LWE key switching keys
, the noise variance of the new ciphertext output by the BootMGCT algorithm, denoted as
, satisfies
Proof. According to Lemma 3, the noise variance of input to MGHybridProd is , denoted as . Before entering the i-th loop in Line 9 of the algorithm, the last terms of the multi-group RLWE ciphertext stored in ACC are all zero, so no noise accumulates. According to Lemma 4, after the MGHybridProd loop in Line 9 is executed, the noise variance of the ciphertext is . According to Lemma 5, after the modulus switching in Line 12, the noise variance of the ciphertext is . According to Lemma 6, after the LWE key switching in Line 13, the noise variance of the ciphertext is . Similar to the first modulus switching, the noise after the second modulus switching in Line 14 of the algorithm is . The theorem is proved by combining the above results. □
8. Security Model and Security Analysis
In this section, we conduct a security analysis of the proposed BootMGCT algorithm in the semi-honest model where the adversary is defined as corrupted parties that follow the protocol strictly and execute all required steps while recording all internal states including private inputs, random tapes, and message transcripts from other parties and attempting to infer honest parties’ additional private information via the collected data post-protocol execution. Next, we conduct a security analysis of the offline and online phases for the proposed bootstrapping process, respectively. Finally, we integrate the basic scheme with the bootstrapping process and prove the security of the full scheme proposed in this work.
Since all existing FHE schemes rely on the weak circular security assumption, and this assumption entails that computations over ciphertexts do not leak any private information, we directly regard the TripleGen, LKeySwitch, and MGHybridProd algorithms in the offline phase as secure against plaintext leakage (i.e., they cannot leak the underlying plaintexts), and thus we focus on proving the non-leakage security of the ASS scheme (
Section 6.1.2), Enroll algorithm (
Section 6.1.3) and JBRKGen algorithm (
Section 6.1.5) in the offline phase.
Lemma 7.
Security of additive secret sharing.
The ASS scheme can tolerate up to colluding parties in the semi-honest adversary model while ensuring the confidentiality of the original secret.
Proof. Under the semi-honest adversary model, the additive secret sharing (ASS) over the polynomial ring ensures secret confidentiality via strict share randomness and operational security. In ASS.Split, a secret is split into k shares with uniformly random in , with the rest being determined by the secret and other shares, making any subset of fewer than k shares contain no valid secret information. Local computations complete ASS.Add, ASS.ScalarMult, and ASS.Auto without interaction, avoiding intermediate information leakage. ASS.Mult relies on Beaver multiplication triples, and non-reuse of triples prevents adversaries from obtaining the original secret via intermediate differences. The triple generation protocol is secure based on the RLWE-based additive homomorphic encryption (AHE) scheme, whose security rests on the computational hardness of the decisional RLWE problem, thus precluding semi-honest adversaries from obtaining secrets in this process. This completes the proof. □
Lemma 8.
Security of Enroll algorithm.
For any semi-honest party , the output of Enroll avoids leaking the secret keys and with up to colluding parties.
Proof. The Enroll algorithm is fully implemented based on ASS and never invokes the secret recover operation (ASS.Recover). ASS ensures that a secret split into k shares has no valid information in any subset of fewer than k shares, and all its operations are local without intermediate leakage, with Beaver triple generation secured by the decisional RLWE problem. Thus completes the proof. □
Lemma 9.
Security of JBRKGen algorithm.
For any semi-honest party , the secret keys and remain unexposed in both the execution process and the final output of JBRKGen under the collusion of up to parties.
Proof. According to Lemma 7, any operation performed on the secret shares does not reveal the original secret. Specifically, the use of the secret shares output by Enroll will not leak or , and equivalently, no intermediate result exposes or . Prior to the invocation of the secret recovery algorithm ASS.Recover, all parties hold only the secret shares of ; after executing the secret recovery, the parties can obtain nothing but itself, which acts as the ciphertext of the FINAL scheme. Since the FINAL scheme satisfies semantic security, the output of the JBRKGen algorithm will not leak and , and the lemma is thus proven. □
In the online phase, we prove that the view of any PPT adversary in a real execution of BootMGCT (
Section 6.2.2) is computationally indistinguishable from that in a simulated execution, meaning the adversary obtains no extra private information.
Lemma 10.
Simulation security of BootMGCT algorithm.
For any PPT honest-but-curious adversary , the view of in the real game (executing BootMGCT with genuine , input ciphertext , and real intermediate computations) is computationally indistinguishable from its view in the simulated game (executed by simulator with simulated keys, simulated ciphertexts, and simulated intermediate results). That is, BootMGCT leaks no information and achieves simulation security.
Proof. We construct a PPT simulator that generates for any PPT honest-but-curious adversary . only has access to public parameters and does not know real plaintext m, secret keys, real input ciphertext , or real public bootstrapping keys. Its operation is simplified as follows, with all simulated keys sampled uniformly from their respective value ranges:
Simulate public bootstrapping keys: uniformly samples a random MGLWE ciphertext from the set of valid MGLWE ciphertexts (matching the dimension and modulus of the real input ciphertext ), which is computationally indistinguishable from the real by the IND-CPA security of the underlying MGLWE scheme. (Our basic scheme follows the standard LWE-based public-key encryption scheme, whose IND-CPA security has been rigorously proven in existing literature).
Simulate input ciphertext: uniformly samples a random MGLWE ciphertext from the set of valid MGLWE ciphertexts (matching the dimension and modulus of the real input ciphertext ), which is computationally indistinguishable from the real by the IND-CPA security of the underlying MGLWE scheme.
Simulate intermediate results and output ciphertext: generates random simulated intermediate results (for BREval,MGHybridProd,LKeySwitch,SampleExt, ModSwitch) and a simulated refreshed ciphertext , each sampled from the value range of their real counterparts. These simulated results are computationally indistinguishable from real ones, leveraging the IND-CPA security of the FINAL scheme and LWE/RLWE/NTRU hardness assumptions.
We are now ready to define the simulated game view as
This view shares an identical structure with the real game view , which refers to all genuine results produced during the practical execution of the BootMGCT algorithm. With all definitions above, we construct three consecutive games (real execution), (intermediate game), and (simulated execution) to prove , i.e., the two views are computationally indistinguishable.
- ‑
: The challenger uses real and real input ciphertext and executes real BootMGCT operations to send to .
- ‑
: The challenger uses simulated (sampled uniformly from their value ranges) but real and real operations to send the intermediate view to .
- ‑
: The challenger acts as , sending (all simulated elements) to .
From the above games, we consider the following claims.
Claim 1. and are computationally indistinguishable.
Proof. The only computational difference between and lies in the public bootstrapping keys (real keys vs. simulated ones). Since the simulated , , and are uniformly sampled from the same distribution as the real , , and (over their respective value ranges), the two sets of public bootstrapping keys are computationally indistinguishable. By the hardness assumption of the underlying LWE/RLWE-based encryption scheme, the distinguishing advantage of any PPT adversary between and is negligible, i.e., , where denotes the security parameter. □
Claim 2. and are computationally indistinguishable.
Proof. The only computational discrepancy between the two games resides in the input ciphertext and the intermediate/output computation results (real executions versus simulated outputs). Since all simulated components are uniformly sampled from the identical distribution as the genuine values over their respective domains, they are computationally indistinguishable under the standard hardness assumptions of LWE, RLWE, and NTRU. Consequently, the distinguishing advantage of any PPT adversary is bounded by a negligible function in the security parameter , i.e., . □
According to Claims 1 and 2 and to the transitivity of computational indistinguishability, the total distinguishing advantage of any PPT adversary satisfies That is, , as desired.
With the Lemmas 8–10, we are ready to prove the security of our full proposed scheme. Next, we adopt a game-based proof approach to establish the IND-CPA semantic security of the scheme.
Theorem 3.
Security of MGLWE scheme with bootstrapping.
Under the semi-honest model, our MGLWE scheme achieves semantic security, namely IND-CPA.
Proof. Fix the security parameter as , and let be k semi-honest parties and be the full MGLWE scheme. As the IND-CPA security of is defined via a game between a PPT adversary and a challenger , we begin our security proof by defining the game procedures:
Initialization Phase: The challenger first simulates the behavior of honest-but-curious parties (k groups with K parties in each group). Specifically, runs MGHE.Setup to generate the basic public parameters. Based on this, the simulator first invokes MGHE.SKeyGen, MGHE.PKeyGen, and MGHE.JointPKeyGen in sequence to generate the secret keys for individual parties, their public keys, and the group joint public key. It then simulates all algorithms in the offline phase of the bootstrapping procedure to derive the public bootstrapping keys and , as well as the LWE key-switching key . Finally, sends all the basic public parameters and above-generated key materials to the PPT adversary .
Challenge Phase: After receiving all materials generated in initialization phase from the challenger , the adversary selects two plaintexts from the plaintext space and sends them to as the challenge plaintexts. The challenger uniformly samples a random bit to determine which plaintext to encrypt and then strictly executes the full ciphertext processing pipeline specified by the scheme: first, runs MGHE.Enc() to generate the initial MGLWE ciphertext corresponding to the plaintext ; next, performs homomorphic NAND evaluation by inputting and a pre-specified dummy ciphertext into the MGHE.NAND, obtaining the noisy evaluated ciphertext ; finally, executes the BootMGCT algorithm to refresh the noisy into a low-noise ciphertext , which is sent to as the final challenge ciphertext.
Guess Phase: Based on all the information obtained during the game (including the challenge ciphertext ), the adversary performs polynomial-time computation to output a guess bit , which serves as ’s guess for the random bit b selected by the challenger .
We then define three games as follows: (real execution), (simulated group bootstrapping keys), and (all simulated execution).
- —
: corresponds to the real execution of the full IND-CPA security experiment, in which the challenger honestly runs the complete MGLWE pipeline: it simulates all semi-honest parties to interactively generate the genuine public bootstrapping keys and , as well as the LWE key-switching key ; performs honest MGLWE encryption of the challenge plaintext ; executes the homomorphic NAND operation on the resulting ciphertext; applies the BootMGCT algorithm to the noisy evaluated ciphertext; and sends the final refreshed ciphertext as the challenge to the adversary.
- —
: This game is identical to in all steps except for the generation of public bootstrapping keys: instead of executing the real interactive multi-party computation in offline phase, the challenger directly samples simulated keys , , and uniformly at random from their native distribution spaces that match the output of the real-world execution while keeping the encryption, homomorphic NAND, and BootMGCT completely honest and unchanged.
- —
: This game corresponds to and adopts the same setup with simulated public bootstrapping keys, but it differs from in the core process of generating the challenge ciphertext. The challenger does not encrypt either of the adversary’s challenge plaintexts or but instead samples a uniformly random MGLWE ciphertext . This ciphertext is then processed through the same homomorphic NAND and BootMGCT refresh pipeline to produce the challenge ciphertext , which is statistically independent of the challenge bit b as well as both plaintexts and .
We first prove the computational indistinguishability between adjacent games.
because the only difference lies in the generation of public bootstrapping keys, and due to the perfect hiding of additive secret sharing, no PPT adversary can distinguish these two games with non-negligible advantage, i.e.,
; next,
as their sole distinction is the source of the challenge ciphertext—
derives the challenge ciphertext from an encrypted challenge plaintext
via the homomorphic NAND operation and BootMGCT, while
derives it from a uniformly random MGLWE ciphertext
through the same pipeline—and due to the computational security of the BootMGCT algorithm (Lemma 10) and the IND-CPA security of the underlying MGLWE scheme, the adversary’s distinguishing advantage between these two games is also negligible—
; finally, in
, the challenge ciphertext
is uniformly random and statistically independent of the challenge bit
b and both challenge plaintexts
, meaning the adversary has no valid clues to guess
b, so the adversary’s guess is completely uniform, leading to
. By the triangle inequality for distinguishing advantages, the total IND-CPA advantage of any PPT adversary
in the real game
is bounded as
This shows that the advantage of any PPT semi-honest adversary is negligible. Therefore, under the semi-honest model, our MGLWE scheme achieves semantic security, namely IND-CPA, and the theorem follows. □
9. Parameters and Implementation
9.1. Parameter Selection
We consider the parameter selection of the multi-group homomorphic encryption scheme from two dimensions: usability and security. Usability means that the set parameters must ensure that the noise size of the ciphertext is always within a specified range to maintain the correctness of the decryption process. Security means that the parameter configuration should be able to resist common attack algorithms, making it impossible for attackers to successfully crack the scheme within the scope of computational feasibility.
According to Lemma 7 of the FHEW scheme [
26], for two LWE ciphertexts
and
encrypting plaintexts
with noises
respectively, after the homomorphic NAND operation is performed, the noise
of the new ciphertext
satisfies
. At this time, the scaling factor corresponding to the ciphertext is
, so the absolute value of the noise
needs to satisfy
, i.e.,
. Therefore, the sum of the noises of the two ciphertexts undergoing the homomorphic NAND gate needs to satisfy
. In gate bootstrapping, we need to control the upper noise bound of the two input ciphertexts, i.e., the upper noise bound of each ciphertext after bootstrapping needs to be lower than
. To ensure the correctness of decryption, the upper noise bound of each step in the bootstrapping algorithm is also required not to exceed the threshold
, where
is the ciphertext modulus of the current ciphertext. We use 6 times the standard deviation as the high-probability upper bound of the noise. Based on the noise variances of ciphertexts at different stages listed in the noise analysis, we obtain the constraints
which serve as one of the bases for parameter selection. The LWE secret key distribution is a symmetric three-point distribution over
, where the probability of taking values −1 and 1 is
and the probability of taking value 0 is
. The noise of the LWE scheme is sampled from a discrete Gaussian distribution with the mean of 0 and the standard deviation of 3. For the keys and noises of the NTRU and RLWE schemes, we also use the above two distributions respectively. Sampling a polynomial means sequentially sampling coefficients from the distribution, so
.
From the noise analysis, the noise level of NTRU ciphertexts reaches its peak after the MGHybridProd operation is executed. At this time, the NTRU modulus Q satisfies . From the perspective of the asymptotic complexity of noise, the parameter selection of this scheme can theoretically ensure that it is within a safe range.
Our scheme fundamentally relies on three core cryptographic primitives, LWE, RLWE, and NTRU, all of whose security is rooted in the computational hardness of lattice problems. For LWE and RLWE, we validate the security via the LWE estimator [
21], ensuring that the computational complexity required to withstand mainstream attacks including dual attack, hybrid dual attack, and uSVP attack exceeds the predefined security level. For NTRU, we employ the NTRU estimator [
22] to reduce the probability of DSD events to below a predefined threshold, thereby mitigating the risk of SKR attacks. Accordingly,
Table 1 and
Table 2 present the concrete parameter sets for 100-bit and 128-bit security, respectively.
9.2. Comparisons and Experimental Results
We conducted a comprehensive evaluation of our scheme against the WLW scheme in terms of both communication and computational overhead. As MGHE is equivalent to MKHE when the offline phase is neglected, we further compared our scheme with the state-of-the-art NTRU-based MKHE scheme (XZW) and the non-NTRU-based MKHE scheme (KMS). For the comparison with MGHE, we present the offline-phase communication rounds, offline-phase local computational overhead (number of polynomial multiplications), and online-phase computational overhead (number of polynomial multiplications) of our scheme and the WLW scheme. Since the bootstrapping keys of MKHE are mutually independent and it has no offline phase as defined in this work, our comparison with MKHE focused on the online-phase (bootstrapping) computational overhead.
Table 3 presents the theoretical comparisons among all schemes.
All experiments were conducted on a server equipped with an Intel(R) Xeon(R) Platinum 8481C processor (3.8 GHz, 56 physical cores, 112 logical threads) and 64 GB of memory, running Ubuntu 22.04.5 LTS. Our method was implemented using the OpenFHE library (v1.1.1), and we adopted thread-level parallelism with explicit CPU core binding to eliminate resource contention. Specifically, we leveraged OpenMP compiler directives (e.g., #pragma omp parallel) to spawn multiple worker threads, which were then explicitly bound to dedicated logical cores via OpenMP environment variables. Multi-party communication was simulated on a single machine using Docker containers, and we used the Linux tc tool to limit the network bandwidth to 100 Mbps, set the round-trip time (RTT) to 100 ms, and introduced a 0.1% packet loss rate to reproduce typical transmission characteristics of a wide area network (WAN).
9.2.1. Comparison Between MGHEs
The structure of the group bootstrapping key in the WLW scheme is consistent with the in our proposed scheme. When the for LWE key switching is also considered, the WLW scheme only involves a small and fixed number of polynomial multiplications in the offline phase. All parties in the group can complete the offline phase with local computation and 1 round of broadcasting. Our scheme needs to generate and as extra steps. It also computes multiplication triples with the TripleGen algorithm which takes five communication rounds. It computes the shares of all joint keys with the Enroll algorithm which takes two communication rounds. It computes with the JBRKGen algorithm which takes three communication rounds. These steps lead to a total of 10 communication rounds.
The Enroll algorithm requires multiplication triples and the JBRKGen algorithm requires multiplication triples. When we substitute the parameter sets given above, the exact number of required triples reaches the ten-thousand level. The local computation for generating one single triple includes AHE encryption, AHE scalar multiplication, and AHE addition operations. This computation takes no more than one second under our parameter settings, but it still remains one of the main bottlenecks of our scheme. The communication overhead is also high due to the large number of required triples.
The local computation in the Enroll and JBRKGen algorithms only introduces constant-order polynomial multiplication overhead brought by secret multiplication. The overall communication overhead and local computation overhead of the scheme are both dominated by the TripleGen algorithm. Different parameter sets support varying maximum numbers of intra-group parties. We chose the minimum number of supported parties across these parameter sets as the experimental setting.
We present the communication volume of the WLW scheme and our scheme in the offline phase in
Table 4. For brevity, we only present the communication volume of our scheme under the three algorithms in
Table 5. We show the local computation time overhead of each party in the group during the offline phase for both schemes in
Table 6,
Table 7,
Table 8,
Table 9,
Table 10 and
Table 11.
In terms of experimental results, our scheme exhibits significant weaknesses in communication overhead and local computation efficiency during the offline phase.
On the communication volume side, under both 100-bit and 128-bit security parameter configurations, the data sent by a single node in our scheme is much higher than that in the WLW scheme across scenarios with 2 to 7 parties in a single group. When there are two parties in a group, the per-node communication volume of our scheme ranges from 16.6 GB to 26.89 GB. The WLW scheme only shows a volume of 0.03 GB to 0.06 GB. The gap between the two schemes reaches hundreds of times. The communication overhead of our scheme increases steadily as the number of group participants grows. When the number of participants rises to seven, the per-node communication volume further increases to 39.93 GB to 64.96 GB. The WLW scheme remains at an extremely low level of 0.03 GB to 0.06 GB. The difference in communication efficiency is thus very obvious. In terms of the communication overhead required by the three algorithms, TripleGen and Enroll exhibit a relatively slow growth in communication volume as the number of participants increases, whereas the communication overhead of the JBRKGen algorithm rises sharply. This is because, under the same parameter settings, each additional participant in the group requires every existing participant in the network to communicate with them, resulting in a multiplicative increase in the data that each participant needs to send.
On the offline local computation side, our scheme adopts additional mechanisms to support key management and ciphertext bootstrapping for the multi-group architecture. These mechanisms include additive secret sharing, polynomial multiplication triple generation, party enroll and joint blind rotation key generation. They cause the total offline local computation time to be much longer than that of the comparison scheme. Taking the 100-bit security parameter set I as an example, the total offline local computation time of our scheme reaches 4778.83 s with two-group parties. The WLW scheme only takes 6.46 s. Among the core computation modules, the TripleGen algorithm accounts for the largest proportion of time at 1974.56 s. The generation of also further increases the total time consumption. The overall efficiency of the offline preparation phase is therefore significantly low. This phenomenon becomes more severe under the 128-bit security parameter configuration. In parameter set I’, the total offline local computation time of our scheme reaches 6780.02 s with two-group parties. The WLW scheme only takes 13.22 s. The time gap between the two schemes is further widened.
9.2.2. Comparison Between MKHEs
Bootstrapping speed has long been one of the core optimization objectives in FHE. Specifically, the offline phase of MPHE schemes is designed to generate unified keys that allow multiple participants to share the same ciphertext. Since all operations behave similarly to those in single-key homomorphic encryption, MPHE schemes can achieve extremely fast bootstrapping. By contrast, MKHE schemes support dynamic participant enrollment, but their ciphertext size grows drastically with the number of participants, and the bootstrapping time increases linearly accordingly. MGHE schemes have therefore been proposed to reduce bootstrapping time while maintaining scheme flexibility.
It should be emphasized that although our proposed scheme performs unsatisfactorily in the MPHE setting, it achieves significant advantages in bootstrapping speed over the state-of-the-art NTRU-based and non-NTRU-based MKHE schemes under identical parameter configurations (Note that since WLW and KMS are TFHE-based schemes, only the four parameters
,
n,
, and
N from the provided parameter sets are applicable to these schemes). As shown in the analysis in
Table 3, the number of polynomial multiplications required for bootstrapping in the other three competing schemes is positively correlated with the total number of parties in the network. To fully demonstrate the strength of our scheme, we minimized the value of
K for these three schemes across six different parameter sets. For MKHE schemes, we set the total number of participants in the network to
k. For MGHE schemes, we set the number of groups to
k and the number of participants per group to one. We used this setup to evaluate the fastest achievable bootstrapping speed of each scheme under different parameter sets. Since the bootstrapping time of our scheme is independent of
K, the above testing setup effectively highlights the core advantage of our construction. Detailed numerical results are presented in
Table 12.
According to the performance analysis of the Online phase in
Table 3, the XZW scheme requires only
polynomial multiplications for bootstrapping. This represents the lowest time complexity among all compared schemes. Accordingly, it achieves the shortest online phase latency in sequential bootstrapping mode. The WLW scheme exhibits slightly higher latency than does XZW. This is because its bootstrapping operations still rely on RLWE and RGSW ciphertexts, without adopting the more compact NTRU ciphertext structure. The serial execution efficiency of the KMS scheme is constrained by its multi-key ciphertext splitting strategy. This strategy partitions the multi-key ciphertext into multiple subtasks. Each subtask requires
polynomial multiplications, and the total cost is thus approximately
times that of the XZW and WLW schemes. Furthermore, the computational results of these split subtasks must ultimately be merged via a hybrid product operation, which further increases the computational overhead.
Our proposed scheme has half the time complexity of the KMS scheme. However, in sequential mode, the KMS scheme can leverage SIMD (single instruction, multiple data) compilation optimizations, enabling a single instruction to complete multiple integer multiplications. In contrast, our scheme decomposes operations that were originally amenable to SIMD optimization into independent steps. This corresponds to redundant computations performed by BootMGCT. Consequently, the sequential bootstrapping speed of KMS is approximately times faster than that of our scheme. Nevertheless, our scheme can distribute bootstrapping tasks across CPU cores for parallel execution. We also employ scalar NTRU ciphertexts and vector NTRU ciphertexts, which require fewer polynomial multiplications, as intermediate ciphertexts. In small-scale group scenarios, our parallel bootstrapping speed approaches half that of the KMS scheme.
As can be seen from the concrete data in
Table 3, under the 100-bit security parameter set I, when the number of groups
, the sequential bootstrapping time of the XZW scheme is 2.18 s. The WLW scheme takes 2.97 s. KMS (SER) takes 5.62 s. Our scheme’s sequential bootstrapping time is 42.58 s. In parallel mode, however, our scheme’s bootstrapping time is only 1.87 s. This value is even lower than the sequential latency of XZW and WLW. As
k increases, the parallel bootstrapping time of our scheme is significantly lower than that of the XZW and WLW schemes. For example, when
, our scheme’s parallel latency is 6.13 s. KMS (PAR) takes 8.15 s. XZW takes 27.13 s. This fully demonstrates the advantages of our scheme in parallel bootstrapping. A more intuitive line chart is shown in
Figure 2. For visual clarity, the bootstrapping times of our scheme and the KMS scheme under the serial mode are not displayed in the line chart. Instead, only the fastest bootstrapping execution time of each scheme is presented, i.e., with parallel execution employed wherever possible.
10. Discussion
10.1. Practical Application Scenario
In the field of artificial intelligence, federated learning enables collaborative model training among multiple institutions while protecting data privacy. Data holders such as research institutions do not need to provide raw data to external parties. They only need to encrypt the locally trained model parameters and upload them to the central node. The aggregation and update of the global model can then be completed.
The bootstrapping efficiency of fully homomorphic encryption is a key factor that determines whether federated learning can be deployed on a large scale. Traditional multi-party homomorphic encryption achieves efficient bootstrapping performance. It requires all participants to share a unified key and cannot support the dynamic joining and leaving of parties in federated learning. Multi-key homomorphic encryption allows dynamic changes of participants. Its ciphertext size grows linearly with the number of participants. Bootstrapping time also increases significantly. It can hardly meet the efficiency requirements of high-frequency parameter aggregation in large model training.
The multi-group homomorphic encryption scheme proposed in this work delivers faster bootstrapping speed than does the state-of-the-art WLW multi-group homomorphic encryption scheme, and it also supports dynamic user participation, thus making it highly compatible with the federated learning scenarios described above. However, the overhead of intra-group key generation in the proposed scheme is relatively high. To address this issue, the cost of the offline phase needs to be amortized by the efficiency improvement brought by bootstrapping in the online phase. As such, the scheme is more suitable for application scenarios with heavy-computation tasks in the MGHE setting, while scenarios with light-computation tasks can adopt the MKHE setting.
10.2. Limitations
From the perspective of experimental results and actual deployment conditions, this scheme still has clear performance constraints and applicable boundaries. In multi-party scenarios, the communication overhead of the scheme is relatively prominent. Both the communication volume and local computing overhead increase linearly with the number of parties in a group. This characteristic directly limits the scale of participants that a single group can accommodate in actual deployment.
Under the multi-key configuration, the scheme can maintain good performance under the established parameter settings. However, in order to meet the security strength requirements of 100 bit and 128 bit, this scheme adopts a relatively large polynomial dimension N and ciphertext modulus Q. Meanwhile, to alleviate the noise accumulation during the bootstrapping process, we also set a higher decomposition degree . Even with the above parameter optimization measures, the number of groups supported by the scheme cannot be increased indefinitely. The noise accumulation during the bootstrapping process is positively correlated with the total number of parties in the entire network. An excessive number of groups will lead to noise overflow. This situation will cause decryption failure even if it does not violate the security assumptions of the scheme. The failure of decryption will further result in the failure of the entire computing task. To avoid such decryption failure, it is necessary to further expand the parameter scale to maintain the preset security strength. Such parameter adjustments not only increase the demand for multiplication triples in the offline phase but also raise the number of polynomial multiplications required for bootstrapping. The overall performance of the scheme in multi-party or multi-key scenarios will eventually be significantly limited.
10.3. Directions for Future Improvement
Based on the design philosophy of the MGHE scheme constructed in this study, the future optimization directions are clear.
Firstly, it is necessary to explore a method for generating joint bootstrapping keys without relying on multiplication triples, thereby reducing the number of communication rounds and lowering the overhead of MGHE under the multi-party setting.
Secondly, in our scheme, we set the NTRU key as , with the core purpose of maintaining its invertibility in the polynomial ring. However, this design results in the coefficients of the NTRU key being randomly distributed in the integer ring, which in turn makes it impossible to use approximate gadget decomposition. Consequently, the external product between vector NTRU and scalar NTRU cannot be achieved with lower noise accumulation. Therefore, how to negotiate an invertible small element in the polynomial ring without leaking the input information of each party will be a key breakthrough to improve the performance of the proposed scheme.
Finally, our scheme can only preserve the privacy of inputs under the semi-honest adversary model at present. Introducing additional mechanisms such as zero-knowledge proof (ZKP) will incur extra overhead, yet this still represents a promising direction for future research.
11. Conclusions
This paper proposes a novel multi-group homomorphic encryption scheme based on LWE and NTRU. By linearizing the NTRU joint key through additive secret sharing technology, the scheme designs a multi-group hybrid product algorithm, enabling parallel bootstrapping of multi-group LWE ciphertexts for encrypted bits. In a multi-core server environment, the time cost of bootstrapping a multi-group ciphertext is comparable to that of bootstrapping a single-key ciphertext, significantly improving the practicality of the homomorphic encryption scheme. Additionally, specific parameter selections are provided to ensure the scheme can effectively resist sublattice attacks. Finally, the scheme was implemented on OpenFHE, and its effectiveness was verified. Experimental results show that although the overhead of our proposed scheme is considerable in multi-party setting and increases with the number of parties within each group, refreshing a collaborative computing ciphertext involving two groups still takes less than 2 s under 100-bit security. Therefore, this scheme provides a new solution suitable for application scenarios that involve heavy-computing tasks.