B RIDGING THE G AP B ETWEEN PHE AND FHE: A P ERFORMANCE AND T RADE - OFF A NALYSIS OF T HE S OMEWHAT H OMOMORPHIC BGN C RYPTOSYSTEM A P REPRINT
arXiv:2607.28700v1 [cs.CR] 30 Jul 2026
Sefik Serengil Department of Engineering Neo4j London, SE1 0LH, UK [email protected]
Alper Ozpinar Department of Management Ibn Haldun University Istanbul, 34480, Turkiye [email protected]
August 3, 2026
A BSTRACT Homomorphic encryption stands as a pivotal paradigm for privacy-preserving data analytics, yet practitioners are frequently forced into a polarizing choice between lightweight Partially Homomorphic Encryption (PHE) and computationally dominant Fully Homomorphic Encryption (FHE). The BonehGoh-Nissim (BGN) cryptosystem theoretically bridges this divide as a Somewhat Homomorphic Encryption (SWHE) scheme by supporting unlimited additions and exactly one ciphertext-ciphertext multiplication. However, despite its profound algebraic elegance, the practical adoption of BGN has remained stagnant due to the lack of accessible, production-ready software implementations. This paper introduces a rigorous comparative trade-off analysis of the BGN cryptosystem against both PHE and FHE paradigms, evaluated through its definitive open-source integration into the lightphe Python framework. Through this integration, a fully functional BGN cryptosystem can be initialized and deployed for homomorphic operations within just a few lines of Python code, drastically reducing the implementation barrier. We benchmark encrypted vector operations over a 128-dimensional space under strict 80-bit and 112-bit security compliance, cross-evaluating BGN against prominent PHE schemes—specifically Paillier, Damgård-Jurik, and Okamoto-Uchiyama—as well as the FHE-backed CKKS scheme via TenSEAL. Our empirical results expose a striking computation-communicationprecision paradox across the cryptographic spectrum. We explicitly demonstrate that, computationally, BGN is heavily penalized by expensive bilinear pairing evaluations, making it significantly slower than both traditional PHE counterparts and modern FHE frameworks that leverage highly optimized C++ SIMD architectures. However, our integrated BGN framework successfully capitalizes on a profound communication and architectural advantage: it retains a microscopic public key footprint of just 3 to 6 KB—an improvement of up to five orders of magnitude over FHE. Crucially, we demonstrate that although BGN permits only a single ciphertext multiplication, the resulting product terms are projected onto the identical target algebraic plane, allowing them to be homomorphically aggregated without bounds. This structural harmony enables the seamless execution of complex multivariate algorithms such as linear regression inference, Cosine Similarity, and Squared Euclidean Distance metrics over fully encrypted payloads. Furthermore, we demonstrate that an optimized precision of 2 digits in BGN is entirely sufficient to match plaintext ranking baselines, effectively neutralizing the target-group discrete logarithm decryption bottleneck. By open-sourcing this pipeline, this work democratizes the BGN scheme, establishing lightphe as the foundational engine for future SWHE-driven decentralized and bandwidth-constrained architectures where usability and minimal communication footprints outweigh raw server-side computational latency. Keywords Cryptography, Homomorphic Encryption, Somewhat Homomorphic Encryption, BGN, Python, PrivacyPreserving Machine Learning, Privacy-Preserving Vector Search, Homomorphic Vector Embeddings, Federated Learning
Bridging PHE and FHE: Performance Analysis of BGN
1
A P REPRINT
Introduction
The rapid proliferation of Privacy-Preserving Machine Learning (PPML), decentralized edge architectures, and collaborative frameworks like Federated Learning (FL) has fundamentally transformed modern data analytics. Moreover, with the exponential rise of Large Language Models (LLMs) and Retrieval-Augmented Generation (RAG) pipelines, organizations increasingly rely on Vector Databases to index and query high-dimensional data embeddings. However, outsourcing sensitive multi-dimensional vectors—such as clinical medical records, financial transactions, biometric profiles, or proprietary LLM vector embeddings—to untrusted cloud infrastructures introduces severe privacy, security, and compliance risks. Traditional cryptographic frameworks secure data at rest and in transit but fail when data must be processed, forcing systems to decrypt information in memory and creating a prime target for runtime exploits. Homomorphic Encryption (HE) offers a definitive mathematical solution to this paradigm by enabling computation directly on encrypted payloads without requiring access to secret keys. In the context of Privacy-Preserving Vector Search and biometric retrieval, maintaining the privacy of Homomorphic Vector Embeddings during similarity scoring (e.g., Cosine Similarity or Distance evaluation) has become a primary bottleneck. Despite its immense theoretical promise, the practical deployment of homomorphic encryption is frequently hindered by a stark architectural polarization within the cryptographic spectrum. On one end of this spectrum reside Partially Homomorphic Encryption (PHE) schemes [1], which natively support only a single type of algebraic operation (either addition or multiplication) with an arbitrary execution depth. Conversely, Fully Homomorphic Encryption (FHE) [2] frameworks accommodate arbitrary circuits comprising both additions and multiplications, but introduce an overwhelming operational tax known as noise management [3] [4]. Every ciphertext-ciphertext multiplication in FHE injects algebraic noise into the underlying data structure; preventing its corruption requires complex bootstrapping techniques or highly parameterized, deep slot allocations that inflate ciphertext structures. Consequently, deploying FHE pipelines requires massive public keys (frequently scaling from tens to hundreds of megabytes) and substantial communication bandwidth. This creates a severe computation-communication paradox, disqualifying FHE from being used in bandwidth-constrained environments, Internet of Things (IoT) nodes, and real-time edge computing architectures. The Boneh-Goh-Nissim (BGN) cryptosystem, introduced as a Somewhat Homomorphic Encryption (SWHE) paradigm, theoretically bridges this widening chasm between the restrictive linearity of PHE and the prohibitive communication overhead of FHE [5]. By leveraging the elegant mathematics of bilinear pairings over elliptic curves, BGN accommodates an arbitrary, unlimited depth of homomorphic additions alongside exactly one layer of ciphertext-ciphertext multiplication. Crucially, because all resulting product terms are projected onto the identical target algebraic plane via the pairing operation, these post-multiplication ciphertexts can be homomorphically aggregated and accumulated without bounds. This specific cross-term additive harmony provides the exact algebraic blueprint required to evaluate fundamental multivariate algorithms—such as linear regression inference, Cosine Similarity (dot product), and Squared Euclidean Distance metrics—over fully encrypted multi-dimensional payloads. Furthermore, BGN achieves this without the multi-megabyte key inflation or noise-management overhead characteristic of FHE, maintaining a microscopic public key footprint that mirrors the lightweight nature of traditional PHE schemes. Yet, despite its profound algebraic elegance and clear utility for vector analytics, the practical adoption of the BGN cryptosystem has remained stagnant for over two decades. The root of this stagnation is not mathematical, but softwarecentric. The vast majority of cryptographic toolkits either ignore BGN entirely or relegate it to archaic, low-level C++ academic proof-of-concepts that require profound manual parameter tuning and lack integration with modern data science languages. Researchers and data engineers working in Python—the undisputed language of modern machine learning and analytics—have been completely locked out of deploying BGN in actual production pipelines. To systematically address this software barrier and democratize access to advanced homomorphic structures, this paper introduces the definitive open-source integration and empirical evaluation of the BGN cryptosystem within the lightphe Python framework [6]. Developed to serve the broader scientific and industrial communities, lightphe is distributed under the permissive MIT License and hosted as a public, open-source project on GitHub at https://github.com/serengil/LightPHE, thereby ensuring unrestricted academic reproducibility and crossindustry utility. The lightphe ecosystem functions as a comprehensive, abstract computational engine designed to provide uniform access to a wide array of homomorphic algorithms. By embedding BGN directly into this operatoroverloaded framework, a fully functional SWHE environment can now be initialized, managed, and deployed for vector analytics within just a few lines of clean Python code. To contextualize the versatility of this framework, lightphe natively orchestrates an unparalleled, exhaustive suite of cryptographic paradigms, establishing a global benchmarking environment that includes: • Multiplicative PHE Algorithms: Classic unpadded RSA [7] and standard ElGamal [8] implementations. 2
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
• Additive & Advanced ElGamal Variants: Exponential ElGamal alongside Elliptic Curve ElGamal (ECElGamal) [9], featuring full algebraic support for Short Weierstrass [10], Koblitz [11], and Twisted Edwards [12] curve coordinates to optimize scalar point multiplications. • Advanced Additive PHE Schemes: The widely adopted Paillier cryptosystem [13], its arbitrary higher-power integer generalization via the Damgård-Jurik scheme [14], and Okamoto–Uchiyama [15]. • Specialized Historic & Algebraic PHE Paradigms: The Benaloh cryptosystem [16] (supporting dense plaintext blocks), the Naccache–Stern [17] higher-radix framework, the Goldwasser–Micali [18] probabilistic bit encryption scheme, and the Sander–Young–Yung (SYY) [19] homomorphic log-depth circuit evaluator. • Somewhat Homomorphic Encryption: The newly integrated Boneh-Goh-Nissim (BGN) [5] elliptic curve pairing-based engine. As systematically codified in Table 1, the homomorphic capabilities across the comprehensive lightphe ecosystem exhibit distinct algebraic boundaries. While traditional frameworks strictly isolate additive or multiplicative properties, the newly integrated Boneh-Goh-Nissim cryptosystem uniquely accommodates an infinite sequence of additions intertwined with exactly one layer of homomorphic multiplication, thereby executing complex multivariate calculations over uniform pipelines. Table 1: Homomorphic Capability Taxonomy of Cryptosystems Algorithm RSA ElGamal Exponential ElGamal Elliptic Curve ElGamal Paillier Damgård-Jurik Benaloh Naccache-Stern Okamoto-Uchiyama Goldwasser-Micali Sander-Young-Yung Boneh-Goh-Nissim
Multiplicatively Homomorphic ✓ ✓ × × × × × × × × × 1
Additively Homomorphic × × ✓ ✓ ✓ ✓ ✓ ✓ ✓ × × ✓
Scalar Multiplication × × ✓ ✓ ✓ ✓ ✓ ✓ ✓ × × ✓
Bitwise-XOR Homomorphic × × × × × × × × × ✓ × ×
Bitwise-AND Homomorphic × × × × × × × × × × ✓ ×
In our baseline comparisons, we restricted the PHE spectrum to the Paillier, Damgård-Jurik, and Okamoto-Uchiyama cryptosystems. Other additively homomorphic schemes—such as Benaloh, Naccache-Stern, Exponential-ElGamal, and Elliptic Curve ElGamal (EC-ElGamal)—were deliberately excluded due to critical practical limitations. Specifically, schemes like Benaloh and Naccache-Stern incur substantial computational overhead for high-dimensional vector representations. Meanwhile, Exponential-ElGamal and EC-ElGamal require solving the Discrete Logarithm Problem (DLP) during the decryption phase; as vector dimensions and floating-point precision scale, resolving the plaintext value via Pollard’s rho or brute-force search becomes computationally prohibitive for real-time applications. Conversely, Paillier, Damgård-Jurik, and Okamoto-Uchiyama offer direct algebraic decryption without DLP search bottlenecks, alongside seamless support for scalar multiplication required in encrypted-plain vector dot products. The primary contribution of this work is a rigorous, three-way empirical benchmark that maps the exact trade-off boundaries between PHE (specifically benchmarking against Paillier, Damgård-Jurik, and Okamoto–Uchiyama), SWHE (via our BGN integration), and FHE (via TenSEAL’s CKKS implementation [20]). We evaluate these paradigms over a 128-dimensional encrypted vector space under strict 80, 112 and 128-bit cryptographic security compliance, exploring the multi-dimensional trade-offs between computational throughput, public key size, and decimal precision. Our results expose a dramatic communication-precision trade-off: while TenSEAL achieves rapid SIMD packaging, it demands public keys up to 451 MB. In stark contrast, our BGN framework operates with a microscopic key size of just 3 to 6 KB—a reduction of five orders of magnitude—while fully maintaining numerical ranking fidelity at an optimized decimal precision of 2. By delivering this pipeline to the open-source community, this work removes the mathematical pairing barriers surrounding BGN and establishes lightphe as the definitive computational platform for future bandwidth-constrained, privacy-preserving analytical architectures.
2
Mathematical Foundations of the BGN Cryptosystem
The Boneh-Goh-Nissim (BGN) cryptosystem relies on the algebraic properties of bilinear pairings [21] evaluated over supersingular elliptic curves. Unlike traditional Partially Homomorphic Encryption (PHE) frameworks that operate 3
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
entirely within a single algebraic group, BGN utilizes an evaluation pipeline that maps elements contextually from a source elliptic curve group to a multiplicative target field extension [22]. This section formalizes the cryptographic primitives, key generation constraints, operational algebraic transformations, and decryption mechanics instantiated within the framework. 2.1
Key Generation and Curve Constraints
The setup phase mandates the selection of a composite modulus that governs the underlying algebraic structures. The execution sequence proceeds as follows: 1. Select two large, distinct cryptographic odd primes q1 and q2 of equal bit-length, and compute the composite RSA modulus: n = q1 × q2
(1)
2. Construct a large prime p acting as the finite field characteristic such that: p=n×l−1
(2)
where l ∈ Z+ is a systematic multiple of 4, ensuring that p ≡ 3 (mod 4). This precise congruence is an absolute mathematical prerequisite to guarantee the supersingularity of the chosen elliptic curve. 3. Define a supersingular elliptic curve over the prime field Fp via the Weierstrass form: E(Fp ) : y 2 = x3 + x
(3)
where the curve parameters are strictly bound to a = 1 and b = 0. The total number of points on this curve is given by #E(Fp ) = p + 1 = n × l, meaning the curve order is a direct multiple of the composite modulus n. 4. Locate a base generator point G ∈ E(Fp ) of order n. To achieve this, a random point on the curve is scaled by the cofactor l. 5. Generate the blinding parameters by choosing a random integer r ∈ [2, n − 1] such that gcd(r, n) = 1. The public blinding point u is evaluated via scalar multiplication as u = r · G. The final structural public key component h is computed by scaling u with the hidden prime factor q2 : h = q2 · u = (q2 · r) · G
(4)
Due to this construction, the point h possesses a strict order of q1 within the group, since n·u = (q1 ·q2 ·r)·G = O. The resulting Public Key is exported as (E, G, n, h, l), while the corresponding Private Key is the prime pair (q1 , q2 ). It is critical to distinguish the structural properties of the BGN cryptosystem from standard Elliptic Curve Cryptography (ECC). In mainstream ECC operating over prime fields (e.g., ECDSA or Ed25519), security relies entirely on the Elliptic Curve Discrete Logarithm Problem (ECDLP). This allows ECC to achieve equivalent security tiers with drastically smaller key footprints compared to factoring-based schemes; for instance, a 160-bit or 224-bit ECC key offers security parity with 1024-bit or 2048-bit RSA keys, respectively. Conversely, the BGN cryptosystem deviates from this lightweight key convention due to its foundational reliance on both the Subgroup Decision Problem and the factorization of the composite RSA modulus n = q1 × q2 . Because the underlying algebraic infrastructure utilizes a supersingular elliptic curve where the order is bound to a multiple of n, BGN does not inherit the compact key-size advantage typical of standard ECC. Instead, its key scaling and security parameters are strictly constrained by RSA factorization bounds. To guarantee robust 128-bit security compliance, the 4
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
composite modulus n must span at least 3072 bits, reflecting a key size paradigm that mirrors RSA variants rather than conventional ECC frameworks. 2.2
Homomorphic Encryption and Layer-1 Addition (G1 )
Given a plaintext integer message m ∈ Zn , encryption requires a fresh, single-use random blinding factor r ∈ [1, q2 −1]. The ciphertext C is constructed as a point on the elliptic curve group G1 = E(Fp ) via: C = (m · G) + (r · h) ∈ G1
(5)
Homomorphic addition of two independent Layer-1 ciphertexts, C1 = (m1 · G) + (r1 · h) and C2 = (m2 · G) + (r2 · h), is achieved directly via standard elliptic curve point addition: Cadd = C1 + C2 = (m1 + m2 ) · G + (r1 + r2 ) · h
(6)
Because (r1 +r2 ) acts as a combined valid blinding factor, Cadd constitutes a structurally sound encryption of (m1 +m2 ). Scalar multiplication of a ciphertext by a plaintext constant k is executed via standard point scaling: Cscalar = k · C1 = (k · m1 ) · G + (k · r1 ) · h
(7)
This confirms that linear evaluations can be executed to an arbitrary, infinite depth within the source curve group G1 . 2.3
Bilinear Pairings and Layer-2 Multiplication (GT )
The core breakthrough of BGN is its ability to perform a non-linear homomorphic multiplication between two independent ciphertexts. Figure 1 presents a high-level overview of how elliptic curve pairings are performed. This is governed by a modified Weil or Tate pairing acting as a non-degenerate bilinear map: e : G1 × G1 → GT
(8)
where GT is a multiplicative target subgroup residing within the quadratic extension field F∗p2 . Elements in this target group are represented algebraically as complex coordinates (a, b) ≡ a + b · i where i2 ≡ −1 (mod p). When evaluating the pairing of two Layer-1 ciphertexts, the bilinearity property unfolds as follows: Cmul = e(C1 , C2 ) = e(m1 · G + r1 · h, m2 · G + r2 · h) = e(G, G)m1 m2 · e(G, h)m1 r2 · e(h, G)r1 m2 · e(h, h)r1 r2
(9)
Substituting h = (q2 · r) · G into the pairing relations, and utilizing the identity e(G, G)n = 1, the cross-terms and blinding terms aggregate into a single target-group blinding factor. Let g = e(G, G) ∈ GT represent the target generator, and hT = e(G, h) ∈ GT . The equation simplifies directly to: Cmul = g m1 ·m2 · hR T ∈ GT
(10)
where R is a combined blinding scalar in the field extension. Because the output Cmul now resides in the multiplicative target group GT , it can never be fed back into the pairing engine, enforcing a strict maximum multiplicative depth of exactly one. 5
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
Crucially, because all post-multiplication ciphertexts are mapped to this identical target plane GT , they can be aggregated homomorphically. Since the group operation in GT is multiplicative, accumulating separate product terms requires field multiplication (Fp2 multiplication) instead of curve addition: 1 +R2 Ctotal = Cmul_1 × Cmul_2 = g (m1 m2 )+(m3 m4 ) · hR T
(11)
This specific property enables the boundless summation of products, providing the exact mathematical environment necessary to compute encrypted dot products and vector distances.
Figure 1: Elliptic Curve Pairings [23] To support homomorphic multiplication over supersingular curves, our implementation in lightphe dynamically employs the Modified Tate Pairing combined with an explicit distortion map via its lightecc dependency. 2.4
Two-Tiered Decryption and the Discrete Logarithm Bottleneck
Decryption is context-dependent, relying entirely on whether the target ciphertext resides in the source curve group G1 or the pairing field extension GT . 2.4.1
Decryption in G1 (Linear Layer)
To decrypt a curve-level ciphertext C, the private key factor q1 is applied to strip the blinding term. Since h has an order of q1 , multiplying by q1 eliminates the blinding element completely: q1 · C = q1 · (m · G + r · h) = q1 · m · G + r · (q1 · h) = m · (q1 · G)
(12)
Let P = q1 · G represent a modified base point whose order is exactly q2 . The system isolates m · P . To recover the plaintext integer m, the system must solve the Discrete Logarithm Problem (DLP) for m relative to the base P . Because P has an order bounded by q2 , recovery is performed via a localized brute-force or bounded search loop within the interval [0, q2 ). 2.4.2
Decryption in GT (Multiplicative/Target Layer)
For a post-multiplication ciphertext Cmul ∈ GT , the private key element q1 is mapped exponentially to eliminate the target blinding factor, utilizing the property that hqT1 = 1: (Cmul )q1 = g m1 m2 · hR T
q 1
m1 m2
= (g q1 ) 6
R
m1 m2
· (hqT1 ) = (g q1 )
(13)
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
By defining the field base as gbase = g q1 (mod p) and the target element as gtarget = (Cmul )q1 (mod p), the problem reduces to a target-group discrete logarithm challenge: m gbase ≡ gtarget
(mod Fp2 )
(14)
The recovery of the combined product m = m1 · m2 requires an explicit iterative search or a Pollard’s rho evaluation over the group order boundary q2 . As the plaintext precision scale expands, the search space for this discrete logarithm grows exponentially, highlighting why minimizing decimal precision to a threshold of 2 is mandatory to prevent crippling decryption latency while maintaining absolute vector ranking accuracy.
3
Implementation
This implementation formally validates the precise algebraic limits of Somewhat Homomorphic Encryption (SWHE). As demonstrated in Snippet 1, the system effortlessly accommodates arbitrary linear evaluation depth, allowing standard homomorphic additions (c3 = c1 + c2 ) and scalar multiplications (c5 = k × c1 ) to be executed transparently via an intuitive high-level API. The non-linear homomorphic multiplication (c4 = c1 × c2 ) successfully leverages the single multiplicative depth inherent to the BGN cryptosystem, shifting the evaluation from the source group to the target group via the bilinear pairing. Crucially, the snippet highlights the dynamic operational flexibility of the scheme through the subsequent evaluations of c6 = c3 + c3 = (c1 + c2 ) + (c1 + c2 ) and c7 = k × c5 = k × (k × c1). This demonstrates two vital properties:
• Scalar multiplications can be applied sequentially to existing ciphertexts without precision degradation.
• Homomorphic additions remain fully functional even when combining a first-order ciphertext (c3 ) with a second-order, post-multiplication ciphertext (c4 ). This specific cross-term additive property is what enables the practical evaluation of complex multivariate polynomials, linear regressions, and squared distance metrics.
Finally, because BGN strictly permits only a single ciphertext-ciphertext multiplication circuit, the implementation includes a defensive validation layer. Attempting a second multiplicative layer (e.g., squaring a previously multiplied ciphertext via c4 × c1 ) is actively intercepted by the engine, dynamically raising a managed ValueError. This programmatic guardrail prevents silent algebraic degradation or runtime pairing failures, providing a stable interface that formally enforces the cryptographic limits of Somewhat Homomorphic Encryption. 7
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
Snippet 1: Somewhat Homomorphic Encryption with BGN # experiments are done with lightphe 0.0.25 version # ! pip install lightphe ==0.0.25 # import lightphe library from lightphe import LightPHE # build a BGN cryptosystem with random keys - it ’s somewhat homomorphic cs = LightPHE ( algorithm_name = " Boneh - Goh - Nissim " , key_size = 1024) # define plaintexts m1 = 10000 m2 = 200 # define a constant k = 3 # find ciphertexts c1 = cs . encrypt ( m1 ) c2 = cs . encrypt ( m2 ) # allowed homomorphic operations c3 = c1 + c2 c4 = c1 * c2 c5 = k * c1 # unlimited additions and scalar multiplications are also allowed c6 = c3 + c3 c7 = k * c5 # however only one multiplication is allowed with pytest . raises ( ValueError , match = " Boneh - Goh - Nissim only supports multiplication ciphertexts once ! " ): _ = c4 * c1 # proof of work - private key is only required in this stage assert cs . decrypt ( c3 ) == m1 + m2 assert cs . decrypt ( c4 ) == m1 * m2 assert cs . decrypt ( c5 ) == k * m1
3.1
Privacy-Preserving Vector Similarity and Distance Metrics
The architectural significance of the Boneh-Goh-Nissim (BGN) cryptosystem in privacy-preserving data analytics stems from its unique algebraic behavior during multivariate computations. Although the scheme strictly limits ciphertextciphertext evaluations to a single multiplicative depth, all product terms are mapped into the identical target algebraic group via the bilinear pairing. Consequently, because these post-multiplication ciphertexts reside within the same geometric and mathematical plane, they can be homomorphically aggregated without bounds. This structural harmony enables the direct evaluation of core machine learning primitives, such as linear regression inference, covariance matrix calculations, and multi-dimensional vector metrics, without requiring the immense noise management overhead of fully homomorphic encryption (FHE). To demonstrate this capability, Snippet 2 presents the complete programmatic validation for computing both the dot product and the Squared Euclidean Distance over fully encrypted 3-dimensional vectors using a high-level Python API. If the input vectors are already L2 normalized in dot product calculation, then it finds cosine similarity as well. 8
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
Snippet 2: Homomorphic Vector Metrics on the BGN Target Group def test_dot_product () : # Vector 1 = [5 , 2 , 8] and Vector 2 = [1 , 1 , 2] , i1_enc = cs . encrypt (5) ; i2_enc = cs . encrypt (2) ; i3_enc = cs . encrypt (8) j1_enc = cs . encrypt (1) ; j2_enc = cs . encrypt (1) ; j3_enc = cs . encrypt (2) # Parallel ciphertext - ciphertext multiplications aggregated homomorphically dot_enc = i1_enc * j1_enc + i2_enc * j2_enc + i3_enc * j3_enc # Verification on the target group plane assert cs . decrypt ( dot_enc ) == (5*1 + 2*1 + 8*2) def t e s t _ s q u a r e d _ e u c l i d e a n _ d i s t a n c e () : # Vector 1 = [5 , 2 , 8] and Vector 2 = [1 , 1 , 2] ( negated for subtraction ) i1_enc = cs . encrypt (5) ; i2_enc = cs . encrypt (2) ; i3_enc = cs . encrypt (8) j1_enc = cs . encrypt ( -1) ; j2_enc = cs . encrypt ( -1) ; j3_enc = cs . encrypt ( -2) # Linear subtraction followed by a single squaring circuit per dimension sq_dist_enc = ( ( i1_enc + j1_enc ) * ( i1_enc + j1_enc ) + ( i2_enc + j2_enc ) * ( i2_enc + j2_enc ) + ( i3_enc + j3_enc ) * ( i3_enc + j3_enc ) ) # Verification of the accumulated distance assert cs . decrypt ( sq_dist_enc ) == (5 -1) **2 + (2 -1) **2 + (8 -2) **2
As formally validated in the implementation, these fundamental metrics are successfully evaluated over fully protected payloads through the following algebraic paths: • Cosine Similarity (Dot Product): The dot product of two fully encrypted vectors coming from L2 normalized vectors is processed by executing parallel multiplications (ik × jk ), which instantly projects each term into the target group. Once in the target group, the individual products are accumulated homomorphically via standard additive operators. • Squared Euclidean Distance: By leveraging the linear additive properties of the scheme to execute internal subtractions (ik + (−jk )) during the initial step, the single available multiplicative depth is then perfectly deployed to compute individual coordinate squares. Because these squared differences are natively generated in the same target group plane, they can be sequentially summed to yield the exact squared distance. This operational alignment bridges the practical gap between partially and fully homomorphic systems. It demonstrates that for a vast class of distance-based clustering algorithms (such as k-NN or k-Means) and similarity-based retrieval tasks, the somewhat homomorphic nature of BGN provides a complete algebraic solution while avoiding the communication bottlenecks typically associated with FHE frameworks. Despite its advantages, BGN is not intended to replace general-purpose FHE schemes. Its single multiplication level restricts computations requiring deeper circuits. Instead, BGN occupies an intermediate position between PHE and FHE, targeting applications dominated by linear operations with occasional quadratic terms.
4
Results and Performance Analysis
Before diving into the numerical evaluation, it is crucial to position this section as an open, standardized benchmark framework for researchers and academics in the homomorphic encryption domain. By systematically mapping the execution latencies, communication overheads, and precision boundaries of PHE, SWHE, and FHE paradigms under identical vector-analytics workloads, we establish a concrete empirical baseline. Researchers can utilize our documented metrics and the open-source lightphe environment as a standardized sandbox to test novel optimization techniques, hardware accelerators (such as GPU/FPGA implementations), pairing libraries, or decryption algorithms, thereby bridging the gap between abstract cryptographic theory and practical, measurable system performance. In this section, we evaluate the empirical performance of the Boneh-Goh-Nissim (BGN) cryptosystem within the lightphe library. Our analysis is divided into two core benchmarks reflecting realistic deployment scenarios for 9
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
privacy-preserving vector analytics: (i) Encrypted × Plain operations compared against standard Partially Homomorphic Encryption (PHE) schemes [24], and (ii) Encrypted × Encrypted vector operations evaluated against a state-of-theart Fully Homomorphic Encryption (FHE) framework (TenSEAL) [25]. All benchmarks were executed utilizing 128-dimensional vectors across multiple standard security tiers. To ensure maximum empirical validity and reflect realistic deployment scenarios for privacy-preserving biometric retrieval, all benchmarks were executed using real 128-dimensional facial embeddings extracted from the standard Labeled Faces in the Wild (LFW) dataset [26]. Facial feature vectors were extracted utilizing the FaceNet model [27] architecture via the open-source DeepFace library [28]. These 128-dimensional floating-point vectors were then normalized and encrypted across the evaluated cryptographic paradigms (PHE, SWHE/BGN, and FHE/TenSEAL) to evaluate Cosine Similarity and Squared Euclidean Distance metrics under true biometric data distribution. Table 2 provides a comparative analysis of key generation latencies across traditional additive Partially Homomorphic Encryption (PHE) schemes, the Boneh-Goh-Nissim (BGN) SWHE cryptosystem, and the CKKS-backed TenSEAL FHE framework. Standard PHE algorithms display near-instantaneous key generation (0.038–0.064 s for 1024-bit and 0.317–0.410 s for 2048-bit keys), while TenSEAL achieves rapid setup times of 0.1766 s (TenSEAL #1) and 1.3147 s (TenSEAL #2) under 128-bit security compliance. Conversely, BGN exhibits a significantly higher setup cost, averaging 90.48 s at 1024-bit security and rising to 954.06 s (≈ 15.9 minutes) at 2048-bit security. Due to the highly variable iterations required for composite prime discovery, BGN key generation times exhibit a heavily right-skewed distribution; thus, the high standard deviations reflect extreme upper-bound tail values while physical setup times remain strictly non-negative. This substantial initialization discrepancy stems from the heavy search for composite-order prime factors and bilinear pairing parameter setups required by BGN. Importantly, key generation remains a strictly offline, one-time setup phase per client instance. Practical production pipelines can entirely bypass this runtime latency by loading pre-generated keypairs or persistent key stores, ensuring that online evaluation and inference throughput remain completely unpenalized. Table 2: Key Generation Comparison of PHE and SWHE Algorithms Cryptosystem
Key Size (bits)
Security Level (bits)
KeyGen (s)
Paillier Damgård-Jurik Okamoto-Uchiyama BGN Paillier Damgård-Jurik Okamoto-Uchiyama BGN TenSEAL TenSEAL
1024 1024 1024 1024 2048 2048 2048 2048 213 × 200 214 × 422
80 80 80 80 112 112 112 112 128 128
0.0642 ± 0.0367 0.0429 ± 0.0147 0.0384 ± 0.0146 90.48 ± 78.94 0.3174 ± 0.1871 0.3979 ± 0.2293 0.4104 ± 0.2169 954.06 ± 992.36 0.1766 ± 0.0065 1.3147 ± 0.0158
Table 3 presents a comprehensive performance breakdown for computing the Cosine Similarity between an encrypted vector and a plaintext vector. This scenario simulates a privacy-preserving retrieval system where a client queries a server using a protected profile against public database items. Table 3: Performance Comparison of PHE and SWHE for Encrypted × Plain Cosine Similarity (128-d Vectors) Cryptosystem Paillier Damgård-Jurik Okamoto-Uchiyama BGN Paillier Damgård-Jurik Okamoto-Uchiyama BGN
Security (Bits) 80 80 80 80 112 112 112 112
Encryption (secs) 0.8865 ± 0.020 0.9956 ± 0.0307 0.8567 ± 0.0198 1.8254 ± 0.0566 1.6340 ± 0.0199 2.5572 ± 0.044 1.5348 ± 0.0326 6.9733 ± 0.0841
Hom. Op. (secs) 0.0958 ± 0.005 0.1864 ± 0.0062 0.0549 ± 0.0037 70.4133 ± 0.5681 0.3131 ± 0.004 0.6430 ± 0.0131 0.1776 ± 0.0021 496.1876 ± 2.2720
Decryption (secs) 0.0182 ± 0.0006 0.0360 ± 0.0013 0.005 ± 0.0006 29.6206 ± 0.6449 0.1233 ± 0.001 0.2618 ± 0.0057 0.0343 ± 0.0008 102.1479 ± 0.6278
Public Key (MB) 0.0006 0.0006 0.0013 0.0030 0.0012 0.0012 0.0027 0.0060
Similarity (MB) 0.00120 0.00170 0.00090 0.00002 0.00220 0.00310 0.00170 0.00002
Methodological Note on Benchmark Consistency and Local Environment: It is critical to note a structural variance in the hardware environments across the reported performance metrics. The empirical execution times and standard 10
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
deviations for the newly integrated Boneh-Goh-Nissim (BGN) cryptosystem were measured directly via our rigorous, multi-run local testing pipeline executed on a cutting-edge Apple Silicon host environment equipped with an Apple M4 Max chip and 64 GB of unified memory. To ensure a fair and consistent comparison, all benchmarks across all cryptosystems—including the baseline PHE schemes (Paillier, Damgård-Jurik, and Okamoto-Uchiyama) and the FHE framework (TenSEAL)—were re-executed natively on the exact same environment, using the standard test suites established in prior literature [24] [25]. Our empirical findings reveal a distinct architectural trade-off between traditional PHE schemes (Paillier, Damgård-Jurik, Okamoto-Uchiyama) and the BGN Somewhat Homomorphic Encryption (SWHE) scheme: - Computational Efficiency: As expected, traditional PHE schemes significantly outperform BGN in terms of execution speed. At the 80-bit security level, Okamoto-Uchiyama exhibits the fastest homomorphic operation and decryption, followed closely by Paillier. Conversely, BGN requires 1.8254 ± 0.0566 seconds for encryption, 70.4133 ± 0.5681 seconds for the homomorphic dot product, and 29.6206 ± 0.6449 seconds for decryption. This computational gap widens exponentially at the 112-bit security level, where BGN’s homomorphic operation reaches 496.1876 ± 2.2720 seconds due to the heavy underlying bilinear pairing operations. - Communication Overhead, Key Management, and the RSA-Modulus Paradox: While BGN demonstrates a massive communication advantage over the multi-megabyte public keys of lattice-based FHE schemes, its underlying algebraic structure introduces a unique cryptographic paradox. Structurally, BGN relies on bilinear pairings evaluated over elliptic curves; however, to achieve security and isolate the secret factors during decryption, it mandates a composite RSA-like modulus n = q1 × q2 . Consequently, despite being an elliptic curve-based cryptosystem, BGN cannot leverage the compact bit-lengths typical of standard EC cryptography (e.g., a 256-bit curve providing 128-bit security). Instead, its key sizes must scale identically to classic RSA security parameters (e.g., requiring a 1024-bit to 3072-bit modulus for baseline compliance). Yet, even under this strict RSA-modulus constraint, the communication footprint of our lightphe BGN implementation remains exceptionally compact compared to FHE, consuming only 3.00 × 10−3 MB (3 KB) at 80-bit security and doubling to just 6.00 × 10−3 MB (6 KB) at 112-bit security. While this key size is inherently larger than a pure, non-pairing elliptic curve scheme, it represents a remarkably clean structural overhead compared to the expanding output sizes of lattice-based alternatives. Thus, while BGN mathematically promises rich theoretical homomorphic operations (boundless additions and a single multiplication), it remains heavily penalized in practice: it behaves as a computationally slow framework that delivers elliptic-curve functionality tied directly to the heavy key scaling requirements of RSA-level security. A critical design choice in practical homomorphic systems involves tuning the floating-point decimal precision, as it directly governs both numerical accuracy and computational overhead. In our previous experiments utilizing Partially Homomorphic Encryption (PHE) schemes, the precision was configured at a high tier of 19 decimal places. However, for the Boneh-Goh-Nissim (BGN) cryptosystem, the experiments were intentionally evaluated at a precision of 2 decimal places. This drastic variation is driven by the underlying mathematical structure of the BGN scheme. Unlike PHE schemes where decryption is instantaneous regardless of precision, BGN decryption requires solving a discrete logarithm problem in the target algebraic group after a homomorphic multiplication has occurred. As the precision increases, the underlying plaintexts expand exponentially, increasing the plaintext encoding range enlarges the discrete logarithm search space during decryption, resulting in substantially higher computational cost. Crucially, our empirical validation confirmed that configuring BGN with a precision of 2 was entirely sufficient for the vector analytics pipeline; the homomorphic evaluation yielded identical similarity metrics and distance rankings when compared directly against the unencrypted plaintext baseline. Therefore, while higher precision configurations inherently minimize quantization loss at the cost of exponential decryption delays, the precision of 2 emerged as the optimal empirical threshold, providing identical ranking results and negligible numerical deviation compared with the plaintext baseline.
11
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
Table 4: Performance Comparison of SWHE and FHE for Encrypted × Encrypted Vector Operations (128-d Vectors) Cs BGN BGN BGN BGN TenSEAL #1 TenSEAL #1 TenSEAL #2 TenSEAL #2
Security (Bits) 80 80 112 112 128 128 128 128
Op Cos Euc Cos Euc Cos Euc Cos Euc
Encryption (secs) 1.8766 ± 0.1151 2.6876 ± 0.1622 6.9905 ± 0.0652 13.3939 ± 0.7976 0.00772 ± 0.00028 0.00719 ± 0.00024 0.02439 ± 0.00078 0.02563 ± 0.00084
Hom. Op. (secs) 209.6305 ± 3.3305 209.8915 ± 2.5877 1451.2582 ± 1.7972 1468.6477 ± 21.3966 0.02936 ± 0.00085 0.02918 ± 0.00081 0.23664 ± 0.00612 0.23981 ± 0.00645
Decryption (secs) 152.3210 ± 4.1741 159.4251 ± 3.8359 1020.9711 ± 2.6884 1064.1078 ± 20.4271 0.00199 ± 0.00007 0.00185 ± 0.00006 0.01311 ± 0.00045 0.01521 ± 0.00052
Public Key (MB) 0.0030 0.0030 0.0060 0.0060 45.1060 45.1060 451.0100 451.0100
Similarity (MB) 0.00002 0.00005 0.00005 0.00005 0.29930 0.29930 1.84870 1.84870
When both vectors must remain strictly confidential (Encrypted × Encrypted), standard PHE schemes fail due to their inability to process ciphertext-ciphertext multiplications. In this domain, BGN’s SWHE capabilities are benchmarked against TenSEAL, an optimized FHE library utilizing vector-packing and SIMD (Single Instruction, Multiple Data) paradigms under the CKKS scheme. To ensure a rigorous and standardized evaluation, we configured two distinct parameter sets for TenSEAL, both compliant with the Homomorphic Encryption Security Standard for the 128-bit security tier. It is critical to note a structural constraint in this comparative setup: TenSEAL (and CKKS-based systems in general) does not support or operate at lower security tiers such as 80-bit or 112-bit, as its polynomial and modular parameter spaces are strictly bound to a minimum of 128-bit compliance to remain secure. Conversely, due to the extreme computational overhead of bilinear pairings, the newly integrated BGN scheme exhibits severe latency even at 80-bit and 112-bit security levels. Because executing BGN at a 128-bit security tier (which requires a highly expensive 3072-bit composite RSA-like modulus) yields practically prohibitive running times, we intentionally restricted our BGN experiments to 80-bit and 112-bit tiers and refrained from executing it at 128-bit. • TenSEAL #1: Configured with a polynomial modulus degree n = 213 , a total ciphertext modulus bit-length log2 q = 200, and a scale factor g = 240 . • TenSEAL #2: Configured with a larger polynomial modulus degree n = 214 , a total ciphertext modulus bit-length log2 q = 422, and a scale factor g = 260 to accommodate deeper multiplicative circuits. We evaluated both Cosine Similarity (Cos) and Squared Euclidean Distance (Euc) over 128-dimensional vectors, as reported in Table 4. The empirical results expose a profound and fascinating paradox in modern secure computation—the Computation vs. Communication Bottleneck: • The Computation Perspective (The Heavy Latency Bottleneck): Our empirical results unapologetically highlight the major operational deficit of the BGN cryptosystem: it is dramatically slower than both its PHE predecessors and state-of-the-art FHE frameworks. While traditional PHE pipelines operate comfortably in subsecond regimes, BGN requires highly intensive bilinear pairing computations. Most glaringly, when compared to modern FHE, TenSEAL delivers blindingly fast execution speeds. Even under its most complex and secure configuration (TenSEAL #2), FHE completes the homomorphic operations in less than 0.24 seconds with near-instantaneous decryption (0.013–0.015 seconds). In stark contrast, BGN, running in a single-threaded Python environment within lightphe, demands 209.63 seconds at 80-bit security and spirals upwards to a staggering 1451.25 seconds at the 112-bit security tier. TenSEAL achieves this immense computational advantage by leveraging native C++ compiled subroutines and highly parallelized SIMD vector batching structures. • The Communication and Accessibility Perspective (The BGN Triumph): However, this severe computational penalty is fundamentally offset by BGN’s unparalleled architectural and developmental simplicity. FHE frameworks such as TenSEAL demand astronomical public keys (45.106 MB to 451.01 MB) to support their deep algebraic circuits, creating massive transmission delays and immense storage overheads over commercial networks. Conversely, our lightphe BGN implementation operates with a microscopic public key footprint of just 3 to 6 KB—representing an unprecedented improvement of up to five orders of magnitude. Furthermore, the resulting ciphertext payload for BGN is practically non-existent, requiring a mere 24 to 56 bytes (2.29 × 10−5 MB), whereas TenSEAL demands between 0.2993 MB and 1.8487 MB per result vector. Crucially, lightphe abstracts all mathematical pairing complexities behind a highly intuitive, native Python API. Developers do not need to manage deep C++ compilers, complicated noise parameters, or extensive slot allocations; a fully functional somewhat homomorphic pipeline can be deployed in just a few lines of clean, standard Python code. 12
Bridging PHE and FHE: Performance Analysis of BGN
4.1
A P REPRINT
Discussion and Architectural Trade-offs
The empirical data gathered from our implementation underscores a critical design choice for security engineers deploying privacy-preserving machine learning algorithms. While BGN is undeniably the slowest option computationally across the spectrum, it shines precisely where FHE introduces severe architectural penalties: developer accessibility and communication overhead. • The "Developer-First" Python Integration: BGN’s definitive integration into lightphe democratizes homomorphic encryption. Historically, deploying BGN meant wrestling with archaic, low-level C++ academic proofs-of-concept. By encapsulating these underlying mathematical layers within an operator-overloaded Python library, data scientists can write standard Python code to perform non-linear vector analytics without needing deep cryptographic domain expertise to configure FHE polynomial spaces or track algebraic noise budgets. • Dual-Mode Adaptability (PHE vs. FHE-like on Demand): Unlike traditional schemes that lock a developer into a single algebraic property, BGN allows a system to adapt dynamically to the task at hand. If a computational step only requires linear combinations (such as adding ciphertexts or multiplying a ciphertext by a plaintext scalar), BGN can be utilized exactly like Paillier or Okamoto-Uchiyama, maintaining low structural complexity and a near-zero communication footprint. The moment the system encounters a nonlinear bottleneck—such as a ciphertext-ciphertext multiplication required for calculating squared distances or dot products—BGN seamlessly transitions into an FHE-like behavior by supporting a single multiplicative depth, without requiring the developer to switch libraries, re-encrypt the data, or manage entirely new keys. • The "Compute-Bound" Edge Scenario (Pro-BGN): In decentralized architectures where data is captured by low-power IoT sensors or mobile clients and transmitted to a cloud server, network bandwidth is frequently the dominant bottleneck, not server-side CPU time. In such environments, forcing an edge node to download a half-gigabyte (451 MB) TenSEAL public key or upload heavily expanded polynomial ciphertexts is a structural impossibility. BGN emerges as the optimal choice here: the client downloads a microscopic 3 KB key, uploads highly compressed ciphertexts, and offloads the heavy pairing computations to the scalable, high-performance cloud infrastructure. • Setup Overhead vs. Operational Throughput: Key generation in BGN introduces a non-trivial offline setup cost compared to additive PHE algorithms. While traditional PHE schemes (e.g., Paillier, Damgård-Jurik) generate keys in milliseconds, BGN requires ∼ 90.5 s for 1024-bit keys and up to ∼ 954.1 s (≈ 15.9 minutes) for 2048-bit keys due to composite-order group generation and bilinear pairing setups. System architects must treat BGN’s key setup as a strictly one-time, offline bootstrapping step to ensure it does not bottleneck online evaluation throughput. • The Encrypted-vs-Plain Decision Rule (PHE Dominance): A critical architectural guideline derived from our benchmarks is that whenever an application permits Encrypted × Plain vector operations, BGN should be strictly avoided in favor of traditional PHE schemes. If one of the vectors (such as a database point or a regression weight) remains unencrypted, the multivariate dot product collapses into a sequence of homomorphic additions and scalar multiplications. Traditional PHE pipelines, such as Paillier or OkamotoUchiyama, natively support these linear operations with blistering efficiency (sub-second execution) while maintaining an ultra-high decimal precision of up to 19 digits. Deploying BGN in an Encrypted × Plain scenario introduces unnecessary performance degradation due to its heavy bilinear pairings and forces the developer into a restrictive 2-digit decimal precision to bypass the target-group discrete logarithm bottleneck. Therefore, BGN must be reserved exclusively for strict Encrypted × Encrypted pipelines where non-linear ciphertext-ciphertext multiplications are an absolute mathematical necessity. • The "Latency-Critical" Enterprise Scenario (Pro-TenSEAL): Conversely, if the application is deployed within a high-speed data center where network latency is negligible and real-time inference (sub-second response) is mandatory, the SIMD capabilities of FHE frameworks like TenSEAL remain irreplaceable, provided the local infrastructure can easily absorb the massive memory footprint and key distribution channels. • The Latency-Critical Decision Rule (FHE Dominance for Speed): In strict Encrypted × Encrypted configurations, if execution speed, real-time throughput, or sub-second latency is the primary operational requirement, practitioners must absolutely deploy general-purpose FHE frameworks like TenSEAL instead of BGN. Our benchmarks demonstrate that for a 128-dimensional vector space, TenSEAL’s compiled C++ back-end and SIMD polynomial batching process ciphertext-ciphertext operations in mere fractions of a second (0.029 to 0.239 seconds) with near-instantaneous decryption. BGN, hampered by the expensive computational overhead of bilinear pairing groups in native Python, requires hundreds or even thousands of seconds to evaluate identical circuits. Therefore, if the deployment architecture can absorb the massive 13
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
memory overhead and network bandwidth required to distribute half-gigabyte public keys, FHE remains the irreplaceable paradigm for latency-critical enterprise pipelines. BGN should only be favored when these massive FHE key sizes introduce an insurmountable communication bottleneck. • Post-Quantum Resilience and Migration Roadmaps: A critical forward-looking consideration in modern system architecture is the transition toward Post-Quantum Cryptography (PQC). In this domain, the trade-off between BGN and FHE becomes absolute. The TenSEAL framework, utilizing the CKKS scheme, is built upon lattice-based Ring Learning with Errors (RLWE) hard problems, making it inherently resilient to quantum cryptanalysis (Post-Quantum Secure) [29]. Conversely, BGN relies on the integer factorization of a composite modulus n = q1 × q2 and the discrete logarithm problem over elliptic curve pairings. Both mathematical foundations are completely vulnerable to polynomial-time evaluation via Shor’s algorithm on cryptographically relevant quantum computers (CRQCs). Therefore, the massive key sizes and ciphertext expansion of FHE can be conceptually interpreted as the "cryptographic tax" required to purchase quantum immunity. For enterprise pipelines drafting long-term, future-proof "store-now-decrypt-later" defense architectures, an immediate migration to lattice-based FHE is mandatory. However, for short-to-medium term deployments, or in highly resource-constrained IoT environments where immediate PQC-compliance is not an operational bottleneck, our BGN integration offers an exceptionally lightweight and practical alternative before a full post-quantum migration is enforced. • The Bandwidth-Constrained Edge Scenario: In real-world decentralized transactions—such as Point-ofSale (POS) terminals, cellular IoT nodes, and low-power embedded devices—network bandwidth constraints make distributing FHE’s massive 45-to-451 MB public keys completely impractical. In contrast, our BGN or PHE implementations impose a microscopic 3-to-6 KB communication footprint, enabling bandwidthconstrained edge hardware to offload single-multiplication encrypted queries (e.g., biometric authentication or risk evaluation) to cloud servers without paralyzing the network channel. By successfully incorporating BGN into lightphe, we provide developers with the unique ability to seamlessly toggle between these distinct cryptographic behaviors based on their specific hardware and network constraints, filling a massive gap in the practical open-source ecosystem.
5
Conclusion and Future Work
In this paper, we have systematically dismantled the long-standing software barrier surrounding the Boneh-Goh-Nissim (BGN) cryptosystem by introducing its first production-ready, high-level implementation within the open-source lightphe Python framework. Our rigorous empirical evaluation mapped the exact multi-dimensional trade-offs between Partially Homomorphic Encryption (PHE), SWHE (via BGN), and Fully Homomorphic Encryption (FHE via TenSEAL’s CKKS). The empirical results expose a stark reality that we explicitly acknowledge: computationally, BGN is significantly slower than both its PHE counterparts and modern FHE frameworks. While PHE schemes leverage simple linear algebra and FHE frameworks utilize highly optimized, compiled C++ SIMD routines to achieve sub-second latencies, BGN’s reliance on bilinear pairings in a native Python environment introduces severe execution delays. However, this high computational cost buys something invaluable: sheer developmental simplicity, minimal communication overhead, and architectural elegance. We demonstrated that the BGN cryptosystem perfectly navigates the paralyzing computation-communication paradox. While FHE frameworks demand massive public keys scaling up to 451 MB—rendering them practically unusable in bandwidth-constrained, mobile edge computing, or IoT environments—our integrated BGN engine maintains a microscopic public key footprint of just 3 to 6 KB. More importantly, we have successfully transformed BGN from an archaic, purely theoretical mathematical construct into a highly accessible, developer-friendly tool. By encapsulating the complex pairing logic and target-group discrete logarithm evaluations behind an operator-overloaded Python API, data scientists can now evaluate complex multivariate algorithms—including linear regression inference, Cosine Similarity, and Squared Euclidean Distance—over fully encrypted vectors with just a few lines of standard Python code. Furthermore, by tuning the decimal configuration to an optimized threshold of 2, we successfully mitigated the target-group decryption bottleneck while maintaining absolute numerical ranking fidelity against unencrypted plaintext baselines. Ultimately, lightphe establishes that raw computational speed is not the sole metric for cryptographic utility. By prioritizing an ultra-compact communication footprint and native Python accessibility despite the computational latency, this work democratizes advanced homomorphic operations, providing a vital, reproducible foundation that empowers the broader scientific community to transition advanced homomorphic structures from theoretical literature into practical, decentralized privacy-preserving architectures. 14
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
Empirical results demonstrate that while BGN successfully bridges the functional gap by supporting homomorphic multiplication, its integration requires accounting for a substantial one-time key generation overhead (≈ 954 s at 2048-bit security) compared to additive PHE schemes. Consequently, BGN emerges as the ideal cryptographic compromise when developers seek to bypass the prohibitive key sizes and ciphertext expansion overheads of FHE, yet find the standard PHE instruction set mathematically insufficient to support necessary multiplicative operations. Future extensions of this work will explore: • Privacy-Preserving Vector Search in Vector Databases: Deploying our BGN engine as an encrypted similarity indexer for Retrieval-Augmented Generation (RAG) and Large Language Model (LLM) pipelines, allowing secure vector embedding lookups without exposing user queries or document embeddings. • Federated Learning (FL) Aggregations: Integrating this vector analytics pipeline into horizontal and vertical Federated Learning frameworks to orchestrate privacy-preserving gradient aggregations, loss evaluations, and global model updates without server-side decryption. • Edge-to-Cloud PPML Deployments: Evaluating lightweight BGN pipelines on resource-constrained Internet of Things (IoT) nodes and edge devices for real-time Privacy-Preserving Machine Learning (PPML) inference, where distributing multi-megabyte FHE keys is bandwidth-prohibitive. • Algorithmic Optimization: Enhancing the target-group discrete logarithm solver utilizing parallelized Pollard’s rho or index calculus variants to expand decimal precision boundaries without inducing prohibitive runtime delays.
References [1] Cetin Kaya Koc, Funda Ozdemir, and Zeynep Odemis Ozger. Partially Homomorphic Encryption. Springer, 2021. [2] Craig Gentry. Fully homomorphic encryption using ideal lattices. In Proceedings of the 41st Annual ACM Symposium on Theory of Computing, pages 169–178, 2009. doi:10.1145/1536414.1536440. [3] Jung Hee Cheon, Andrey Kim, Miran Kim, and Yongsoo Song. Homomorphic encryption for arithmetic of approximate numbers. In International conference on the theory and application of cryptology and information security, pages 409–437. Springer, 2017. [4] Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan. (leveled) fully homomorphic encryption without bootstrapping. ACM Transactions on Computation Theory (TOCT), 6(3):1–36, 2014. [5] Dan Boneh, Eu-Jin Goh, and Kobbi Nissim. Evaluating 2-dnf formulas on ciphertexts. In Theory of cryptography conference, pages 325–341. Springer, 2005. [6] Alper Ozpinar and Sefik Ilkin Serengil. Sustainable cryptography: Carbon asymmetry in partially homomorphic encryption in the cloud. Symmetry, 18(5):832, 2026. doi:10.3390/sym18050832. URL https://www.mdpi. com/2073-8994/18/5/832. Special Issue: Symmetry in Cryptography and Cybersecurity. [7] Ronald L. Rivest, Adi Shamir, and Leonard Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120–126, 1978. doi:10.1145/359340.359342. [8] Taher ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE Transactions on Information Theory, 31(4):469–472, 1985. doi:10.1109/TIT.1985.1057074. [9] S. Sutikno, A. Surya, and R. Effendi. An implementation of elgamal elliptic curves cryptosystems. In IEEE Asia-Pacific Conference on Circuits and Systems, pages 483–486, 1998. doi:10.1109/APCCAS.1998.743829. [10] Victor S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology. CRYPTO 1985, pages 417–426. Springer, 1985. doi:10.1007/3-540-39799-X_31. [11] Neal Koblitz. Elliptic curve cryptosystems. Mathematics of Computation, 48(177):203–209, 1987. doi:10.1090/S0025-5718-1987-0866109-5. [12] Harold M. Edwards. A normal form for elliptic curves. Bulletin of the American Mathematical Society, 44(3): 393–422, 2007. doi:10.1090/S0273-0979-07-01153-6. [13] Pascal Paillier. Public-key cryptosystems based on composite degree residuosity classes. In Advances in Cryptology. EUROCRYPT 1999, pages 223–238. Springer, 1999. doi:10.1007/3-540-48910-X_16. [14] Ivan Damgård and Mads Jurik. A generalisation, a simplification and some applications of paillier’s probabilistic public-key system. In Public Key Cryptography. PKC 2001, pages 119–136. Springer, 2001. doi:10.1007/3-54044586-2_9. 15
Bridging PHE and FHE: Performance Analysis of BGN
A P REPRINT
[15] Tatsuaki Okamoto and Shigenori Uchiyama. A new public-key cryptosystem as secure as factoring. In Advances in Cryptology. EUROCRYPT 1998, pages 308–318. Springer, 1998. doi:10.1007/BFb0054135. [16] Josh Benaloh. Dense probabilistic encryption. In Selected Areas in Cryptography, pages 120–128, 1994. [17] David Naccache and Jacques Stern. A new public key cryptosystem based on higher residues. In Proceedings of the 5th ACM Conference on Computer and Communications Security, pages 59–66. ACM, 1998. doi:10.1145/288090.288106. [18] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. Journal of Computer and System Sciences, 28(2): 270–299, 1984. ISSN 0022-0000. doi:10.1016/0022-0000(84)90070-9. [19] Tomas Sander, Adam Young, and Moti Yung. Non-interactive cryptocomputing for nc/sup 1. In 40th Annual Symposium on Foundations of Computer Science (Cat. No. 99CB37039), pages 554–566. IEEE, 1999. [20] Ayoub Benaissa, Bilal Retiat, Bogdan Cebere, and Alaa Eddine Belfedhal. Tenseal: A library for encrypted tensor operations using homomorphic encryption, 2021. [21] Victor S. Miller. The Weil pairing, and its efficient calculation. Journal of Cryptology, 17(4):235–261, 2004. doi:10.1007/s00145-004-0315-8. Presented at CRYPTO 1985. [22] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the Weil pairing. In Colin Boyd, editor, Advances in Cryptology — ASIACRYPT 2001, volume 2248 of Lecture Notes in Computer Science, pages 514–532. Springer, 2001. doi:10.1007/3-540-45682-1_3. [23] D Aranha. Pairings are not dead, just resting. In 21st Workshop on Elliptic Curve Cryptography, (November 2017), 2017. URL https://ecc2017.cs.ru.nl/slides/ecc2017-aranha.pdf. [24] Sefik Serengil and Alper Ozpinar. Encrypted vector similarity computations using partially homomorphic encryption: Applications and performance analysis. arXiv preprint arXiv:2503.05850, 2025. doi: 10.48550/arXiv.2503.05850. [Online]. Available: https://arxiv.org/abs/2503.05850. [25] Sefik Serengil and Alper Ozpinar. Cipherface: A fully homomorphic encryption-driven framework for secure cloud-based facial recognition. arXiv preprint arXiv:2502.18514, 2025. doi: 10.48550/arXiv.2502.18514. [Online]. Available: https://arxiv.org/abs/2502.18514. [26] Gary B Huang, Manu Ramesh, Tamara Berg, and Erik Learned-Miller. Labeled faces in the wild: A database for studying face recognition in unconstrained environments. Technical Report 07-49, University of Massachusetts, Amherst, 2007. [27] Florian Schroff, Dmitry Kalenichenko, and James Philbin. Facenet: A unified embedding for face recognition and clustering. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR), pages 815–823, 2015. [28] Sefik Ilkin Serengil and Alper Ozpinar. Lightface: A hybrid deep face recognition framework. In 2020 innovations in intelligent systems and applications conference (ASYU), pages 1–5. IEEE, 2020. [29] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. On ideal lattices and learning with errors over rings. In Annual international conference on the theory and applications of cryptographic techniques, pages 1–23. Springer, 2010.
16