Pure Multi Key BGV Implementation*
Justine Paillet
1 a
, Olive Chakraborty
2 b
and Marina Checri
2 c
1
Hensoldt SAS France, 115 avenue de Dreux, Plaisir, France
2
Universit
´
e Paris-Saclay, CEA, List, F-91120, Palaiseau, France
Keywords:
Homomorphic Encryption, Pure Multi-Key, Multi-User Frameworks, Cloud Computing.
Abstract:
This paper offers an in-depth exploration of a Pure Multi-Key BGV Implementation. It provides a detailed
analysis of the calculations involved for both the server and parties in the scheme, specifically focusing on the
challenging and specific relinearisation of terms. Particular emphasis is given towards the extended RGSW
multiplication and the complexity of addition, multiplication, and keyswitch key generation.
1 INTRODUCTION
In the rapidly evolving landscape of cryptography,
ensuring the security and privacy of sensitive data
has become paramount. With the rise of cloud com-
puting, secure data processing techniques have gar-
nered significant attention. Homomorphic encryp-
tion, a groundbreaking concept in the field of cryp-
tography, allows computations to be performed on en-
crypted data without the need for decryption, thereby
ensuring end-to-end security and privacy. Among the
various homomorphic encryption schemes, the BGV
scheme (Brakerski et al., 2014) stands out for its effi-
ciency and versatility.
This paper delves into the realm of pure multi-key
BGV implementation, a topic of great significance
given the increasing reliance on secure computations
in various domains such as finance, healthcare, and
data analytics. A pure multi-key BGV encryption al-
lows multiple parties to jointly perform computations
on encrypted data without sharing their private keys.
This collaborative approach is essential in scenarios
where data privacy is non-negotiable, and parties must
work together while preserving the confidentiality of
their individual inputs.
a
https://orcid.org/0009-0009-6056-7766
b
https://orcid.org/0000-0003-0396-908X
c
https://orcid.org/0000-0002-0473-1164
∗
The first author contribution to this work was done
while at CEA List. The third author’s work was supported
by the France 2030 ANR project ANR-22-PECY-003 Se-
cureCompute.
1.1 Motivation
One of the modern questions linked to FHE is the pos-
sibility of creating multi-user cryptosystems. If it is
possible to perform calculations on encrypted data,
it could be interesting to be able to modify the data
collectively. This is why thinking about a multi-key
system could prove interesting.
A homomorphic multi-key system is one that al-
lows several users, each with a pair of keys, to interact
on an encrypted message. There are two main meth-
ods: threshold and multi-key. While each user has a
private key, the number of keys used differs according
to the type of scheme chosen. In the case of threshold,
there is one public key common to all participants
1
.
As in asymmetric cryptography, encryption is
done with the common public key. The direct con-
sequence will be the size of the ciphertext, which will
be said to be ”normal”, i.e. the size of a conventional
ciphertext. With pure multi-key – the second multi-
key approach – each party uses his or her own public
key to encrypt, meaning there will be as many cipher-
texts as public keys for encrypting a single piece of
data. Although the global ciphertext is now heavier
than the threshold ciphertext, the presence of a public
key for each party means that the pure multi-key sys-
tem is more scalable. Unlike the threshold approach,
it is not necessary to rebuild the entire system to add
or remove a party. Threshold schemes are normally
designed to be decryptable if at least m parties par-
ticipate in the decryption. This is not the case with
pure multi-key schemes, which require all the parties
1
Built using participants’ public keys during a pre-
calculation phase
Paillet, J., Chakraborty, O. and Checri, M.
Pure Multi Key BGV Implementation.
DOI: 10.5220/0012429000003648
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 807-814
ISBN: 978-989-758-683-5; ISSN: 2184-4356
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.
807

to participate in the decryption. However, it is not un-
common to see the threshold requiring all parties.
1.2 Our Contributions
We have implemented a Multi-Key Homomorphic
Encryption scheme using OpenFHE. This work
presents a detailed exposition of the necessary the-
ory and calculations, focusing mainly on refining the
methodology for performing multiplication on ex-
tended RGSW ciphertexts by choosing the needed
rows. Building upon this implementation, we present
a complexity analysis and report computational time
results.
1.3 Organization
The paper is organized as follows. Sec. 2 presents
related work on existing FHE multi-user approaches.
The next section, Sec 3 presents some preliminaries
on FHE and the MKHE scheme. Details on our con-
tributions are in Sec. 4. We conclude the paper with
experimental results in Sec. 5.
2 RELATED WORKS
Multi-user approaches for implementing FHE
schemes refer to Threshold Homomorphic Encryp-
tion (ThHE, also known as MultiParty HE) and
Multi-Key Homomorphic Encryption (MKHE).
They involve multiple keys during the decryption of
ciphertexts and ensure that no single entity holds the
decryption key (i.e. the private key).
ThHE schemes were introduced in (Asharov et al.,
2012; Boneh et al., 2018; Chowdhury et al., 2022).
These schemes allow a subset of the private key own-
ers to decrypt (collectively) a message encrypted with
a collective public key (computed from all the individ-
ual ones in a public way). The subset size is fixed and
defined at setup. However, ThHE has a static setup
and needs to remove and re-encrypt all the data each
time a user is removed.
In contrast, MKHE schemes (described in (L
´
opez-
Alt et al., 2013; Dor
¨
oz et al., 2016; Chen et al.,
2017; Chen et al., 2019)) remove the need for a key
setup by allowing the evaluation server to dynami-
cally extend ciphertexts from encryption under indi-
vidual keys to ones under the concatenation of several
users keys. Then, all the private key owners have to
collaborate for decryption. However, the increase in
ciphertext size in the number of users results in a con-
siderable increase in homomorphic operators’ com-
putational costs. For instance, a multi-key version of
TFHE (Chen et al., 2019) turns 2.19kB ciphertexts
into 17.32kB ciphertexts for the same clear data when
the number of users increases from 2 to 8. The com-
putation time for homomorphic evaluation on cipher-
texts increases even faster. The time for evaluating
a NAND gate is 0.27 seconds for two users and be-
comes 7.16 seconds for eight users.
Recently, hybrid approaches have been proposed
(Aloufi and Hu, 2019) to combine the advantages
of both ThHE and MKHE. However, to the best of
the authors’ knowledge, hybrid approaches have so
far been built only on BGV (Brakerski et al., 2014),
which restricts the set of functionalities that may be
implemented.
3 PRELIMINARIES
3.1 Notations
Let R be a ring. For example, R =
Z[X]
/X
d
+1, where
d is a power of two. We let λ denote the security
parameter throughout the paper. We denote K as a
bound on the number of keys and L as a bound on
the depth of the circuit, which defines the number of
levels. S will denote the set of all parties such that
|S| = k ≤ K.
Cryptosystem Parameters. We also need to create
parameters specific to BGV:
• Let χ = χ(λ,K,L) be a random distribution, B-
bounded (i.e. in the interval ] − B,B[) on R – de-
fined in the RLWE problem (Lyubashevsky et al.,
2010);
• Let q
L
≫ q
L−1
≫ ··· ≫ q
0
be L + 1 decreasing
moduli.
• Let p be a small integer, such that ∀ℓ ∈
J 0, L K, p ∧ q
ℓ
= 1.
• For each level ℓ ∈ J0,LK, let β
ℓ
= ⌊log(q
ℓ
)⌋ + 1;
and let a
ℓ
∈ R
2β
ℓ
q
ℓ
be a public vector.
Therefore each algorithm will take the following
parameters pp = (R,χ,B,{q
i
,a
i
}
i∈{L,···,0}
, p).
Extended Object. Let S’ be a subset of S. An ex-
tended object
o is the concatenation of a set of object
o = (o
′
1
∥ ··· ∥ o
′
k
), where
o
′
j
=

o
j
if j ∈ S
′
0 otherwise
Note that this definition is different than the RGSW
extended ciphertext. We will define and explain it
later.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
808

Subroutines. We define two useful subroutines.
POWERSOF2(s) := (s · 2
0
,· ·· ,s · 2
i
,· ·· ,s · 2
β
ℓ
−1
).
BITDECOMP(U) := (D
0
,· ·· ,D
i
,· ·· ,D
β
ℓ
−1
), where
U =
∑
β
ℓ
−1
i=0
2
i
· D
i
.
3.2 BGV
This subsection defines the construction of the BGV
system. The notations introduced here are essential
for understanding the multi-key part. The evaluation
of homomorphic operations is described later, espe-
cially in the multi-key case (which is quite similar to
the single-key case).
Secret Key. For each level ℓ ∈ J0, LK, party j ran-
domly chooses z
ℓ, j
← χ and sets s
ℓ, j
= (1,z
ℓ, j
) ∈ R
2
q
ℓ
.
Public Key. For each level ℓ ∈ J0,LK, party j com-
putes pk
ℓ, j
= [a
ℓ
· z
ℓ, j
+ p
j
· e
ℓ, j
,−a
ℓ
] =: [b
ℓ, j
,−a
ℓ
],
from the L + 1 public vectors a
ℓ
, and where e
ℓ, j
←− χ.
Note that pk
ℓ, j
· sk
ℓ, j
= a
ℓ
· z
ℓ, j
+ p · e
ℓ, j
− a
ℓ
· z
ℓ, j
=
p · e
ℓ, j
.
Encryption. To encrypt m ∈ R
p
, party j chooses
u
$
←− R
p
and e
1
,e
2
←− χ. Then, party j computes and
outputs a level-L BGV ciphertext
c = [u · pk
L, j
[0] + m + p · e
1
,u · pk
L, j
[1] + p · e
2
] ∈ R
2
q
L
Decryption. Given a level-ℓ BGV ciphertext c =
(c
0
,c
1
) ∈ R
2
q
ℓ
encrypted under pk
ℓ, j
, party j com-
putes m = ⟨c,s
ℓ, j
⟩ (mod q
ℓ
) (mod p), where m is the
plaintext.
3.3 Multi-Key
In 2017, Long Chen, Zhenfeng Zhang and Xueqing
Wang published a paper describing for the first time
a multi-key implementation of BGV: Batched Multi-
hop Multi-key FHE from Ring-LWE with Compact
Ciphertext Extension. (Chen et al., 2017).
3.3.1 Key Generation and Encryption
Extended Public and Secret Keys. Multi-key en-
cryption involves several parties, each holding its own
public/private key pair. From the individual public
keys, we can construct an extended public key p
k
,
which will be their concatenation. Similarly, we can
construct the extended secret key s
k
from the individ-
ual private keys. Still, it must be underlined that this
extended key is only a theoretical object, mainly used
to explain decryption.
Extended Ciphertext. Below, we define an ex-
tended ciphertext c. This ciphertext corresponds to
a message m encrypted under the extended public key
p
k
. Moreover, for any c
i
∈ c such that i ∈ S, we have
a message m
i
encrypted under the key sk
i
, such that:
m =
∑
i∈S
m
i
where m is the message shared between the users.
Decryption. As for classic BGV decryption, the
pure multi-key cryptosystems’ decryption is based on
a scalar product. For k parties, c
k
= (c
1
∥ ··· ∥ c
k
) and
s
k
= (sk
1
∥ · ·· ∥ sk
k
) = ((1,z
1
) ∥ ·· · ∥ (1,z
k
)), where
c
t
and sk
t
are respectively the ciphertext and the secret
key of party t ∈ J1,kK. Thus,
< c
k
,s
k
>=
k
∑
t=1
< c
t
,sk
t
>=
∑
i∈S
< c
i
,sk
i
>=
∑
i∈S
m
i
= m
Since the extended private key is a theoretical object,
all the participants must work collectively to decrypt
the message.
3.3.2 Operations
Multi-Key addition is simply a vector addition. The
case of the multiplication is quite different. As in the
single-key multiplication, the Multi-Key multiplica-
tion uses the tensor product, denoted ⊗. Due to the
increase of the ciphertext’s length (because of the ten-
sor product), we need to reduce it to its initial length
by using an evaluation key. The evaluation key is spe-
cific to FHE schemes and is another public element
constructed from the secret key. This key is neces-
sary for ciphertext relinearisation (dimension reduc-
tion) after multiplication. To create such a key in a
pure multi-key scheme, we must introduce the RGSW
cryptosystem (Gentry et al., 2013).
3.4 RGSW Scheme for the Generation
of Evaluation Key
Multiplication is the critical point in the BGV Multi-
Key cryptographic scheme, so we need to focus on
constructing the evaluation key, also known as the re-
linearisation key in the BGV scheme. To do so, we
need to use all the parties’ keys, which is precisely
this point that poses a problem and makes multiplica-
tion difficult. Sharing a secret key is a major security
flaw. That is why we need to find a solution to remedy
this. We use RGSW to encrypt users’ private keys and
obtain indices of keys to construct the relinearisation
key we need.
Pure Multi Key BGV Implementation
809

3.4.1 Key Generation and Encryption
The RGSW key pair of party j is the same as that
generated with BGV. We denote µ as the plaintext in
those algorithms and recall that p
k
= [b
l, j
,−a
l
].
Encryption. RGSW scheme uses two encryption
algorithms, described by Algorithms 1 and 2.
Data: µ
for i = 0 to β
ℓ
do
ri ← χ;
e
1
,e
2
← χ;
f
1
= b
ℓ, j
[i]r
i
+te
1
+ POWERSOF2(µ)[i];
f
2
= b
ℓ, j
[i]r
i
+te
1
;
F[i] = { f
1
, f
2
};
end
Result: F
Algorithm 1: RGSW.RANDENC.
Data: µ
E ← χ
2·β
ℓ
, error vector;
r ← χ
2
;
G := (I
2
,· ·· ,2
i
I
2
,· ·· ,2
β
ℓ−1
I
2
);
C := vP + pE + G
t
µ, P the public key;
Result: (C,F = RGSW.RANDENC(r))
Algorithm 2: RGSW.ENC.
Algorithms 1 and 2 have two important properties:
• F · s = pe
′
+ POWERSOF2(µ)
T
,
with e
′
= er + e
1
− e
2
· z
• C · s = pe
′
+ µGs ∈ R
2β
ℓ
q
Decryption. To decrypt, perform a standard BGV
decryption on the first row of C.
3.4.2 Operations
Addition. To perform a Multi-Key addition, per-
form a classic matrix addition, i.e. add the rows one
by one:
C + C
′
:= (v + v
′
)P +t(E + E
′
) + G(µ + µ
′
)
Multiplication. Unlike addition, multiplication is
a more complex operation. In the following, the
RGSW multiplication is denoted by C
1
⊙C
2
. To com-
pute it, first calculate the bit decomposition of C
1
:
BITDECOMP(C
1
) = {D
0
,· ·· ,D
β
ℓ
−1
} ∈ (R
(2×β
ℓ
)
)
β
ℓ
,
such that C
i
=
∑
β
ℓ
−1
i=0
2
i
· D
i
. Then, calculate the fol-
lowing classical matrix product:
C
1
⊙ C
2
:= BITDECOMP(C
1
) · C
2
(1)
Extended RGSW Ciphertext. The extended
RGSW ciphertext is the last object we need to
construct the evaluation key. To extend an RGSW ci-
phertext C
i
produced with the function RGSW.ENC
(Alg. 2), we construct X
j
from the result F of
RGSW.RANDENC (Alg. 1), and
e
b
j
:= b
j
− b
i
∈ R
2β
q
(where b
i
, b
j
are the first elements of the correspond-
ing public keys). For each u ∈ {0, ··· , 2β
ℓ
− 1}, and
for v ∈ {0, ·· · ,β
ℓ
− 1},
X
j
[u] := BITDECOMP(
e
b
j
[u]) · F
i
=

e
b
j
[u]
(0)
·· ·
e
b
j
[u]
(β
ℓ
−1)

·








f
1
(0)
f
2
(0)
.
.
.
.
.
.
f
1
(v)
f
2
(v)
.
.
.
.
.
.
f
1
(β
ℓ
−1)
f
2
(β
ℓ
−1)








(2)
Finally, put the X
j
blocks obtained in the i
th
column
of a matrix, and C
i
on the diagonal. Initialise the rest
of the matrix at 0. We obtain the following result:
C =









C
i
X
1
0
.
.
.
.
.
.
.
.
. C
i
.
.
.
.
.
.
.
.
.
0 X
k
C
i









∈ R
2kβ
ℓ
×2k
q
(3)
We define the extended RGSW ciphertext construc-
tion as RGSW.CTEXT(C
i
, pk
S
,F
i
).
3.5 Evaluation/Relinearisation Key
In pure Multi-Key BGV, the relinearisation key stands
for the evaluation key. There are three main steps to
create the evaluation key:
• Pre-calculations on secret keys (each party);
• Computations from the encrypted data (server);
• Selection of the rows for the Key Switch key.
Pre-Calculations: Each user must perform pre-
calculations to transmit encrypted information about
their secret keys. To do this, each party j computes
the RGSW ciphertexts for powers of 2 of its secret
keys (4) and (5) and encrypts the bit decomposition
of its secret keys (6) and (7). The idea is to multiply
the powers of two of one key with the bit decompo-
sition of another to obtain the multiplication of these
two keys.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
810

Φ
i,ℓ, j
= RGSW.ENC
s
ℓ−1, j
(POWERSOF2(s
ℓ, j
)[i])
= r
i,ℓ, j
· [b
ℓ−1
,a
ℓ−1
] + p · E
i,ℓ, j
+ POWERSOF2(s
ℓ, j
)[i] · G (4)
F
i,ℓ, j
= RGSW.ENCRAND(r
i,ℓ, j
, pt
ℓ−1, j
) ∈ R
β
ℓ
×2
q
ℓ
(5)
Ψ
i,ℓ, j
= RGSW.ENC
s
ℓ−1
, j
(BITDECOMP(s
ℓ, j
)[i])
= r
i,ℓ, j
· [b
ℓ−1
,a
ℓ−1
] + p · E
i,ℓ, j
+ BITDECOMP(s
ℓ, j
)[i] · G (6)
F
′
i,ℓ, j
= RGSW.ENCRAND(r
i,ℓ, j
, pt
ℓ−1, j
) ∈ R
β
ℓ
×2
q
ℓ
(7)
These individual pre-computations are then used to
construct the following extended RGSW ciphertexts:
Φ
i,ℓ, j
∗
= RGSW.CTEXT(Φ
i,ℓ, j
∗
, pk
S
,F
i,ℓ, j
∗
)
= RGSW.ENC
s
ℓ−1
(POWERSOF2(s
ℓ, j
∗
)[i])
(8)
Ψ
i,ℓ, j
∗
= RGSW.CTEXT(Ψ
i,ℓ, j
∗
, pk
S
,F
′
i,ℓ, j
∗
)
= RGSW.ENC
s
ℓ−1
(BITDECOMP(s
ℓ, j
∗
)[i])
(9)
The last calculations (the extended RGSW ciphertexts
(8) and (9)) can be performed by the server, although
it is still technically possible to let each client perform
them.
Server Calculations. First, remember the writing
of the (theoretical) level-ℓ extended secret key:
sk
ℓ
= (s
ℓ, j
1
∥ ··· ∥ s
ℓ, j
k
) = (1, z
ℓ, j
1
,· ··1,z
ℓ, j
k
) ∈ R
2k
q
ℓ
From the previous pre-calculations, the server has to
create a ciphertext of the product of the secret key
sk
ℓ, j
of party j at level ℓ and the secret key sk
ℓ, j
′
of
party j
′
at the same level. In other words, the server
computes RGSW.ENC(sk
ℓ, j
[t]·sk
ℓ, j
′
[t
′
]) from Φ
j
and
Ψ
j
′
, where t,t
′
∈ {0, 1} are the indexes of the key
s
ℓ, j
. The server performs the following calculations
for t = t
′
= 1.
RGSW.ENC
s
ℓ−1
(sk
ℓ, j
[t] · sk
ℓ, j
′
[t
′
])
=
β
ℓ
∑
i=1
(RGSW.ENC
s
ℓ−1

POWERSOF2(sk
ℓ, j
[t])[i])
⊙ RGSW.ENC
s
ℓ−1
(BITDECOMP(sk
ℓ, j
′
[t
′
])[i])

=
β
ℓ
∑
i=1
Φ
j
[i] ⊙ Ψ
j
′
[i] (10)
Key Construction. In the previous section, we
saw how to calculate C
δ
:= RGSW.ENC
s
ℓ−1
(s
′
ℓ
[δ]) ∈
R
2kβ
ℓ
×2k
q
ℓ
, where s
′
ℓ
= s
ℓ
⊗ s
ℓ
and δ ∈ {1,· ·· ,4k
2
}.
Constructing the evaluation key involves choosing the
right rows in the matrix to perform a Key Switch. Re-
member that to create a Key Switch, we must have
rows c
d,δ
for d ∈ {1,· ·· , β
ℓ
} such as:
< c
d,δ
,s
ℓ
>= p · e
d,δ
+ 2
d−1
· s
′
ℓ
[δ]
For d
′
∈ {1, ·· ·β
ℓ
}, we choose the rows with indices
2 · k · (d
′
− 1) if the first index of the rows starts at
0, and we add 1 to this number if the index starts at
1. Contrary to the original article (Chen et al., 2017),
where the authors use the d above to select the rows,
we introduce the notation d
′
to choose them. We make
this slight correction because the powers do not match
otherwise, and the rows are incorrectly indexed.
4 CONTRIBUTIONS
This section will focus mainly on the paper presenting
implementation ideas: Batched Multi-hop Multi-Key
FHE from ring-LWE with Compact Ciphertext Exten-
sion (Chen et al., 2017).
4.1 Explanations of Multi-Key BGV
Operations
Let k be the number of parties.
Multiplication. When multiplying two ciphertexts
encrypted under two different keys pk
1
and pk
2
,
the result ciphertext is then decryptable by the cor-
responding secret keys’ tensor product s
1
⊗ s
2
=
(1,s
1
,s
2
,s
1
· s
2
). Therefore, this new ciphertext
should be relinearised to put it back under a key of
the usual form.
4.2 Multiplication on Extended RGSW
Ciphertexts
In (Chen et al., 2017), the authors do not explain how
to perform multiplication on extended RGSW cipher-
texts. Instead, the article implies that the calculations
are the same as for non-extended multiplication – that
the operation is analogous – which is not the case.
This section explains why it differs from multiplica-
tion on classic RGSW ciphertexts and how to perform
this operation on extended ciphertexts.
Pure Multi Key BGV Implementation
811

4.2.1 Explanation of the Product on Extended
RGSW Ciphertexts
Decryption of an Extended Ciphertext. An RGSW
extended ciphertext C, extended from the ciphertext
C
i
of party i to k participants, is a matrix of k rows,
with C
i
on the diagonal and X
j
blocks in the i
th
column (cf eq. (3)). To decrypt such a ciphertext,
each line of blocks must be considered (remembering
that correct decryption is achieved by examining
every other line). Given j ∈ {1,·· · ,k}, there are two
possibilities:
(i = j) On line i, there is only one non-zero element,
C
i
, in column i. Therefore, < l
j
,s
ℓ
>= C
i
· s
i
.
The result is correct since the decryption is
done with the right key.
(i ̸= j) On line j, there are two non-zero elements, C
i
and X
j
. Hence,
< l
j
,s
ℓ
> = X
j
· s
i
+ C
i
· s
j
= pe
′
+
˜
b
j
r + C
i
s
j
= pe
′
+ pe
j
r − as
j
r − pe
i
r + as
i
r + rpe
i
− as
i
r + pe
01
+ µ + ras
j
+ ps
j
e
02
= p(e
′
+ e
j
r + e
01
+ s
j
e
02
) + Gµs
j
(11)
Which is a right decryption.
Applying RGSW Multiplication. This section ex-
plains applying the multiplication described above
(see eq. (1)) to an extended ciphertext. First, let us
start by doing it naively on a simple case.
Example 1. We want to compute
C ⊙ 1 =

5 2 2 1
3 4 6 0

⊙

G 0
0 G

with G = (I
2
| 2I
2
| 4I
2
).
BITDECOMP(C) =

1 0 0 1 0 1 1 0 1 0 0 0
1 0 0 0 1 0 1 0 0 1 1 0

If we perform matrix multiplication, the first element
is different from the expected result (1 instead of 5).
So, there is a problem applying the multiplication
using the earlier definition. On the other hand, if we
change this product into a matrix product and then a
multitude of RGSW products, we get a correct result.
4.2.2 Extended RGSW Multiplication
Algorithm
As explained above, this multiplication is essential
for constructing an evaluation key. This section fo-
cuses on performing an RGSW-extended multiplica-
tion, avoiding the calculation of duplicate multiplica-
tions, which are time-consuming operations.
As previously, there are two cases: where i = j
and where i ̸= j. The first one is less useful because it
allows the calculation of Key Switch keys of the form
s
i
× s
i
. Thus, we focus on the second one: for i ̸= j,
the matrix product is calculated as follows
2
.
(1) Initialize a block matrix to 0.
(2) Set the matrix diagonal to C
i
⊙C
j
;
(3) On column i, if v ̸= i, add X
v
⊙C
j
to location v;
(4) On column j, if v ̸= i, add X
v
⊙ X
′
i
to location v;
(5) On column j, if v ̸= j, add C
i
⊙ X
′
v
to location v.
Regarding the number of internal multiplications, step
(2) requires only one multiplication, while steps (3),
(4) and (5) each require two times (k − 1) multiplica-
tions. This algorithm requires a total of 6(k − 1) + 1
internal multiplications to create this type of Key
Switch key.
Remarks on the Choice of Rows. By construct-
ing matrices this way and choosing rows within each
block, we compute many costly multiplications. That
increases considerably with the number of parties.
Recall that the choice of rows only justifies the condi-
tion < c
d,δ
,s
ℓ
>= p · e
d,δ
+ 2
d−1
· s
′
ℓ
[δ].
Consequently, there are two interesting remarks.
The first one is that only β
ℓ
rows are required for the
computation, instead of 2kβ
ℓ
. The second one comes
from the fact that all blocks of rows encrypt the same
information. This implies that the information is cal-
culated k times. Thus, choosing the rows in a differ-
ent way is possible by considering only one block of
rows.
4.3 Multi-Key Key Switch
The Key Switch used for relinearisation is similar to
the one used in BGV. We will, therefore, describe a
relinearisation based on a Key Switch protocol.
Recall. Let c = (c
0
,c
1
,c
1,2
∥ c
′
0
,c
2
,c
2,1
). We as-
sume that we have already split the elements to be
multiplied by s
1
, s
2
and that we have already relin-
earised the terms into s
1
s
1
and s
2
s
2
. In this way, we
only
3
have to relinearise the terms to be multiplied by
s
1
s
2
. We also need to recall that
m
1
·m
2
= (c
0
+c
′
0
)+c
1
·s
1
+c
2
·s
2
+(c
1,2
+c
2,1
)·s
1
s
2
However, as explained above, it is neither rea-
sonable nor secure to share one’s secret key to cre-
ate a key product. We will therefore have to use
2
Remember that a matrix product is not always commu-
tative
3
This operation will be the same in all cases
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
812

an evaluation key κ = {κ
i
}
i∈J0,β
ℓ
−1K
such that for all
i ∈ J0,β
ℓ
− 1K, remembering that s
ℓ
is the extended
key of the system:
2
i
· s
1
s
2
=< κ
i
,s
ℓ
>
= κ
i
[0] · 1 + κ
i
[1] · s
1
+ κ
i
[2] · 1 + κ
i
[3] · s
2
(12)
Relinearisation. To relinearise the term c
1,2
+ c
2,1
,
denoted η, the server first adds the two elements c
1,2
and c
2,1
4
, so that there is only one relinearisation step.
Then, the server computes for each i and for each j ∈
{0,1, 2,3}:
η · κ
i, j
= BITDECOMP(c
1,2
+ c
2,1
)[i] · κ
i
[ j] (13)
We remark, by using (12) and (13), that
c · κ[i] =< (η · κ
i,0
,η ·κ
i,1
,η ·κ
i,2
,η ·κ
i,2
,η ·κ
i,3
),s
ℓ
>
= BITDECOMP(η)[i] · 2
i
s
1
s
2
(14)
= BITDECOMP(c
1,2
+ c
2,1
)[i] · 2
i
s
1
s
2
(15)
Having said all this, we can now carry out the relin-
earisation and demonstrate that it is a correct opera-
tion. The next step is to transform the initial cipher-
text ct into the relinearised ciphertext ct
′
, as follows:
c
′
:= (c
0
+
β
ℓ
−1
∑
i=0
η · κ
i,0
, c
1
+
β
ℓ
−1
∑
i=0
η · κ
i,1
,
c
′
0
+
β
ℓ
−1
∑
i=0
η · κ
i,2
, c
2
+
β
ℓ
−1
∑
i=0
η · κ
i,3
)
(16)
Decryption. The desired result of decrypting c
′
is m
1
·
m
2
. To decrypt c
′
, calculate the scalar product of c
′
with the extended key
s
ℓ
.
< c
′
,s
ℓ
>= (c
0
+ c
′
0
) · 1 + c
1
· s
1
+ c
2
· s
2
+
β
ℓ
−1
∑
i=0
η · (κ
i,0
· 1 + κ
i,1
· s
1
+ κ
i,2
· 1 + κ
i,3
· s
2
)
By using this transformation,
< c
′
,s
ℓ
>
= (c
0
+ c
′
0
) · 1 + c
1
· s
1
+ c
2
· s
2
+
β
ℓ
−1
∑
i=0
η · κ[i]
= (c
0
+ c
′
0
) · 1 + c
1
· s
1
+ c
2
· s
2
+
β
ℓ
−1
∑
i=0
BITDECOMP(c
1,2
+ c
2,1
)[i] · 2
i
s
1
s
2
by (15)
4
The operation can be performed separately, but the re-
linearisation operation is much more costly than the addi-
tion operation.
= (c
0
+ c
′
0
) · 1 + c
1
· s
1
+ c
2
· s
2
+ (c
1,2
+ c
2,1
)s
1
s
2
= m
1
· m
2
4.4 Multiplication Complexity
Parameters. To compute some complexity calcu-
lus, we need to define some parameters:
• p: plaintext modulus;
• n: cyclotomic order/2;
• Q =
∏
q
i
: ciphertext modulus;
• k: number of party;
• d: multiplicative depth.
Multiplication on Z/qZ.
1. Multiplication complexity: naive (O(log(q)
2
))
and karatsuba (O(log(q)
log(3)
))
2. Reduction modulus q: O((2 log(q) − log(q) +
1)log(q)) = O(log(q)
2
). Due to the complexity
of this division, the result for the addition in Z/qZ
will be the same as the multiplication.
Global complexity: C
mult
= O(log(q)
2
)
Multiplication of Two DCRTPoly. A DCRTPoly
is a vector of (d+2) elements. These are vectors of n
elements in Z/qZ, each associated with a modulus q.
To multiply it, we need to perform the multiplica-
tion term by term, i.e. there will be n multiplications
in Z/qZ per vector. Let log(q
i
) ∼ log(q).
Global complexity: C
multDCRTPoly
= O(n·d·C
mult
) =
O(n · d · log(q)
2
).
BitDecomp(NUM). To find one bit i, we need to
apply NUM & 0 · ·· 0 1
|{z}
i
0· ··0. This operation
complexity is O(log(Q)). We need to repeat it for
each bit and number in interpolating the DCRTPoly
(only one vector left).
Global complexity
5
: C
BitDecomp
= O(log(Q)
2
· n)
RGSW Multiplication.
1. Loop from 0 to 2k log(Q)/2k – the number of
rows we want to compute here is log(Q). At
this level we know the complexity bound as:
C
RGSWmult
= O(log(Q) · C
firstLoop
)
5
This complexity is valid for the version of OpenFHE
we used. It could be improved in future versions of the
library.
Pure Multi Key BGV Implementation
813

2. Let’s compute C
firstLoop
. It consists of two-
bit decompositions and a loop from 0 to
2log(Q) – this time, we need all the rows.
C
firstLoop
= O(C
BitDecomp
+log(Q) ·C
secondLoop
) =
O(log(Q)
2
· n + log(Q) · C
secondLoop
)
3. Determining the complexity of the second loop.
Let us enumerate all the operations in this loop:
• 4 multiplications of DCRTPoly;
• 4 additions of DCRTPoly.
Consequently, C
secondLoop
= O(4(C
multDCRTPoly
+
C
addDCRTPoly
)) = O (n · d · log(q)
2
)
Global complexity: C
RGSWmult
= O(log(Q)
2
· n · d ·
log(q)
2
).
5 RESULTS AND CONCLUSION
For these results, the computer used has an Intel Core
processor i7-12800H, 14 cores (6 performance-cores
– max turbo frequency cores 4.80 GHz and 8 efficient-
cores – max turbo frequency cores 3.70 GHz) for a
total of 20 threads. The library is OpenFHE version
1.1.1 (1.0.3 was used for comparison). We used a
plaintext modulus of 65537, and the multiplicative
depth was 3. The other parameters were OpenFHE
default ones.
Table 1: Addition.
parties 2 3 4 5 8 10
time (ms) 98 157 219 279 460 579
Table 2: Multiplication.
parties 2 3 4 5 8 10
time (ms) 115 252 397 550 1136 1642
We did the two operations (addition and multipli-
cation) for 2, 3, 4, 5, 8 and 10 parties. The corre-
sponding results can be found in the tables 1 and 2.
Multiplication time is to be understood without relin-
earisation: we just decrypted the ciphertext to verify
the correctness of the algorithm.
The last step was to create the relinearisation key.
The time result (described in 3 and 4)is only for one
element of the evaluation key and does not include
the pre-calculation time (which must be done inde-
pendently by every party because it is the secret key’s
encryption).
As shown by these last results, the implementation
of the library is crucial to evaluation key’s calculation
time. Refinement of core functions can very likely
lead to substantial improvements in calculation time
Table 3: RGSW multiplication v1.1.1, One row.
threads 1 2 4 8 16 20
time (min) 3:38 3:43 3:25 3:38 3:40 3:23
Table 4: RGSW multiplication v1.0.3, One row.
threads 1 2 4 8 16 20
time (min) 6:23 5:51 5:40 5:25 4:53 6:13
6
, and it will hopefully be enhanced in future versions
of OpenFHE.
REFERENCES
Aloufi, A. and Hu, P. (2019). Collaborative Homomorphic
Computation on Data Encrypted under Multiple Keys.
IWPE’19.
Asharov, G., Jain, A., L
´
opez-Alt, A., Tromer, E., Vaikun-
tanathan, V., and Wichs, D. (2012). Multiparty Com-
putation with Low Communication, Computation and
Interaction via Threshold FHE. In EUROCRYPT
2012, volume 7237, pages 483–501. Springer.
Boneh, D., Gennaro, R., Goldfeder, S., Jain, A., Kim, S.,
Rasmussen, P. M. R., and Sahai, A. (2018). Threshold
Cryptosystems from Threshold Fully Homomorphic
Encryption. In CRYPTO 2018, volume 10991, pages
565–596. Springer.
Brakerski, Z., Gentry, C., and Vaikuntanathan, V. (2014).
(leveled) fully homomorphic encryption without boot-
strapping. ACM Transactions on Computation Theory
(TOCT), 6(3):1–36.
Chen, H., Chillotti, I., and Song, Y. (2019). Multi-key ho-
momorphic encryption from TFHE. In ASIACRYPT
2019, volume 11922, pages 446–472. Springer.
Chen, L., Zhang, Z., and Wang, X. (2017). Batched Multi-
hop Multi-key FHE from ring-LWE with Compact Ci-
phertext Extension. TCC 2017, 10678:17.
Chowdhury, S., Sinha, S., Singh, A., Mishra, S., Chaudhary,
C., Patranabis, S., Mukherjee, P., Chatterjee, A., and
Mukhopadhyay, D. (2022). Efficient threshold FHE
with application to real-time systems. IACR Cryptol.
ePrint Arch., page 1625.
Dor
¨
oz, Y., Hu, Y., and Sunar, B. (2016). Homomorphic
AES evaluation using the modified LTV scheme. De-
signs, Codes and Cryptography, 80(2):333–358.
Gentry, C., Sahai, A., and Waters, B. (2013). Homomorphic
encryption from learning with errors: Conceptually-
simpler, asymptotically-faster, attribute-based.
L
´
opez-Alt, A., Tromer, E., and Vaikuntanathan, V. (2013).
On-the-fly multiparty computation on the cloud via
multikey fully homomorphic encryption. IACR Cryp-
tol. ePrint Arch., page 94.
Lyubashevsky, V., Peikert, C., and Regev, O. (2010). On
ideal lattices and learning with errors over rings. In
EUROCRYPT 2010, pages 1–23.
6
For instance, the bit decomposition could still be sig-
nificantly optimized.
ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy
814