Partially Homomorphic Encryption

An additively homomorphic public-key cryptosystem where the product of two ciphertexts decrypts to the sum of their corresponding plaintexts. It is defined as: Decrypt(Encrypt(m1) * Encrypt(m2) mod n²) = m1 + m2 mod n.

• Key Use Case: Secure electronic voting and privacy-preserving data aggregation.
• Security Basis: Relies on the decisional composite residuosity assumption.

A multiplicative homomorphic scheme where the product of two ciphertexts decrypts to the product of the plaintexts: Decrypt(Encrypt(m1) * Encrypt(m2)) = m1 * m2.

• Key Use Case: Foundational for more complex protocols like threshold cryptography.
• Variant: The exponential ElGamal variant is additively homomorphic, making it useful for e-voting.
• Security Basis: Relies on the computational Diffie-Hellman assumption.

The first provably secure public-key cryptosystem, which is xor-homomorphic (additive homomorphic over bits). It allows for the encryption of single bits (0 or 1).

• Operation: The product of two ciphertexts decrypts to the bitwise XOR of the two plaintext bits.
• Key Use Case: Primarily theoretical, demonstrating the feasibility of semantic security.
• Security Basis: Relies on the quadratic residuosity problem.

Exhibits a multiplicative homomorphic property in its basic, unpadded form. The product of two ciphertexts is an encryption of the product of the plaintexts: (m1^e * m2^e) mod n = (m1*m2)^e mod n.

• Critical Warning: This property is a major security flaw for standard encryption, as it is malleable.
• Practical Use: This property is exploited in certain cryptographic signatures and proofs, like RSA blind signatures.

The core distinction between PHE schemes is the single operation they preserve under encryption.

• Additive (e.g., Paillier): Enables secure summation of encrypted values without decryption. Essential for private analytics and federated learning.
• Multiplicative (e.g., basic ElGamal): Enables the multiplication of encrypted values. Often used as a building block rather than for direct private computation.

Partially Homomorphic Encryption is limited to one type of operation, restricting complex computations.

• Key Limitation: Cannot compute both addition and multiplication on encrypted data, preventing evaluation of arbitrary functions.
• Evolution: This limitation drove the development of Somewhat Homomorphic Encryption (SHE) and Fully Homomorphic Encryption (FHE), which support a limited or unlimited number of both operations.

PHE enables confidential smart contracts where contract logic can be executed on encrypted inputs, revealing only the final result. This is foundational for private voting, sealed-bid auctions, and confidential financial agreements on-chain.

• Zcash's zk-SNARKs utilize PHE principles for shielded transactions.
• Aztec Protocol uses PHE to enable private DeFi interactions.
• Allows validation of conditions (e.g., "balance > X") without revealing the actual balance.

Oracles can deliver and process sensitive off-chain data (e.g., credit scores, medical data, KYC information) in encrypted form. Smart contracts use PHE to perform computations on this data to trigger actions without ever decrypting it.

• Enables privacy-preserving identity verification.
• Allows for conditional payments based on private real-world events.
• Protects data providers' commercial sensitivity while enabling on-chain utility.

While fully homomorphic encryption (FHE) is ideal, specific PHE schemes like Paillier encryption (additively homomorphic) are used to hide transaction amounts. This allows the network to verify that a transaction is valid (e.g., inputs ≥ outputs, no double-spend) without knowing the actual values.

• Mimblewimble and related protocols use cryptographic commitments with homomorphic properties.
• Enables auditable privacy where regulators can verify totals without seeing individual transactions.

PHE allows model training on data pooled from multiple users without exposing their raw datasets. Each participant encrypts their data locally; the model trains on the aggregated, encrypted gradients.

• Preserves data sovereignty in collaborative AI.
• Mitigates risks of centralized data silos and breaches.
• Enables federated learning on blockchain with verifiable, privacy-preserving aggregation.

PHE is used in layer-2 rollups and sidechains to batch and process private state updates off-chain. A succinct proof or the final state is then posted to the main chain, compressing privacy overhead.

• Reduces on-chain footprint of private computations.
• zk-Rollups leverage PHE within zero-knowledge proof systems for scalability.
• Enables private payment channels and state channels with complex logic.

For tokenized real-world assets (RWAs) like securities or real estate, PHE allows for compliance checks against encrypted investor accreditation status or jurisdictional rules. The compliance logic runs without exposing sensitive investor data on a public ledger.

• Enables programmable compliance with privacy.
• Allows for confidential dividend calculations and voting rights management.
• Critical for bridging TradFi regulatory requirements with DeFi transparency.

A PHE scheme supports only one type of mathematical operation (e.g., addition or multiplication) on ciphertexts, not both. This is its defining limitation compared to Fully Homomorphic Encryption (FHE).

• Additive PHE (e.g., Paillier): Supports addition of ciphertexts.
• Multiplicative PHE (e.g., ElGamal): Supports multiplication of ciphertexts. This restriction means complex computations requiring both operations cannot be performed directly, often requiring complex workarounds or protocol redesign.

Homomorphic operations are significantly more computationally intensive than their plaintext equivalents. This results in:

• Slower Processing: Operations can be orders of magnitude slower, making PHE unsuitable for high-frequency, real-time applications.
• Increased Bandwidth: Ciphertexts are much larger than plaintexts (ciphertext expansion), increasing storage and transmission costs.
• Energy Consumption: The cryptographic operations consume more power, a critical factor for mobile or IoT devices.

PHE lacks the widespread, battle-tested standardization of traditional encryption (like AES). Key considerations include:

• Implementation Risks: Novel cryptographic code is prone to subtle bugs and side-channel attacks.
• Parameter Selection: Choosing secure, efficient parameters (key size, noise parameters) is complex and non-standardized.
• Limited Library Support: While libraries exist (e.g., Microsoft SEAL, PALISADE), integration is more complex than using standard AES or RSA modules.

Using PHE introduces specific trust models and cryptographic assumptions that must be validated.

• Trusted Setup: Some schemes require a trusted party to generate initial parameters, creating a potential single point of failure.
• Cryptographic Assumptions: Security relies on hardness assumptions like Decisional Composite Residuosity (DCR) for Paillier or Decisional Diffie-Hellman (DDH). A future break in these assumptions would compromise the system.
• Information Leakage: While data remains encrypted, access patterns or the result of a computation itself may leak metadata.

Designing a system with PHE requires navigating its inherent constraints.

• Circuit Depth Limitation: For schemes that support limited multiplicative depth (a step towards FHE), complex computations may "run out of noise budget" and fail.
• Precision & Data Types: Most PHE schemes work over integers or finite fields, not native floating-point numbers, requiring fixed-point encoding which adds complexity and can introduce rounding errors.
• Key Management Complexity: Managing encryption keys for multiple parties in a computation (e.g., in secure multi-party computation) adds significant protocol overhead.