💻 computer science

Exploring CKKS Parameter Trade-offs for Privacy-Preserving Personalized Federated Learning

This paper introduces pFedCKKS, a framework that integrates the CKKS homomorphic encryption scheme into Personalized Federated Learning and provides the first systematic guide for selecting its parameters to balance privacy, precision, and computational efficiency.

Original authors: Kamolchanok Saengtong, Phanwadee Sinthong, Norrathep Rattanavipanon

Published 2026-06-09

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Kamolchanok Saengtong, Phanwadee Sinthong, Norrathep Rattanavipanon

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a group of doctors, each working in a different hospital, who want to build a super-smart AI to diagnose diseases. They all have patient data, but privacy laws (like GDPR) and ethical rules mean they can't send their patients' actual medical records to a central server.

Federated Learning (FL) is the solution they use: instead of sharing the data, they share the "lessons learned" (model updates) from their local AI. However, there's a catch. Even these "lessons" can sometimes be reverse-engineered to reveal private patient details.

Personalized Federated Learning (PFL) takes this a step further. In standard FL, everyone ends up with the exact same AI model. But in PFL, each doctor gets a model tailored specifically to their own hospital's patient mix, while still learning from the group.

The Problem: The "Honest-but-Curious" Server

In this setup, there is a central server that coordinates the training. The paper assumes this server is "honest-but-curious." It follows the rules and doesn't steal data, but it is curious. It might try to peek at the "lessons" sent by the doctors to figure out private details about their patients.

The Solution: The "Magic Envelope" (CKKS)

To stop the server from peeking, the authors introduce a "Magic Envelope" called CKKS (a type of Homomorphic Encryption).

How it works: Imagine you can put a letter inside a locked, transparent box. You can perform math on the outside of the box (adding or multiplying the contents) without ever opening it. The server aggregates these locked boxes. Only the doctors have the key to open the final box and read the result.
Why CKKS? Most encryption is great for whole numbers (like counting apples), but AI models use decimals (like 3.14159). CKKS is special because it can do math on these decimal numbers while they are still locked in the box.

The Big Discovery: The "Goldilocks" Settings

The paper's main contribution is figuring out how to configure these Magic Envelopes. The authors found that the "size" of the lock (called primes) creates a trade-off:

Small Locks: Fast to lock/unlock and small to send over the internet, but the math inside gets "fuzzy" (low precision). The AI might get confused and make mistakes.
Huge Locks: Very precise math, but they are heavy, slow to process, and take up a lot of internet bandwidth.

The authors tested this with three different AI strategies (FedFinetune, FedPer, and Ditto) on three different types of data (handwritten letters, celebrity faces, and tweet sentiments).

The "Sweet Spot" Finding:
They discovered that you don't need the biggest, heaviest locks to get good results.

If the lock is too small (18 bits), the AI breaks and performs terribly.
If the lock is huge (38+ bits), the AI works perfectly, but it's so slow and heavy that it's impractical for real-world use.
The Recommendation: They found a "Goldilocks" setting: 28-bit outer locks and 26-bit inner locks.

At this specific setting:

The AI is just as accurate as if no encryption were used at all.
The speed and internet usage are low enough to be practical.

The Takeaway

The paper presents a framework called pFedCKKS. It proves that you can have your cake and eat it too: you can train personalized AI models on private data without the central server ever seeing the raw data, and without slowing down the system too much.

The key lesson for anyone building this system is: Don't just pick the biggest, safest numbers you can find. Instead, pick the specific "28 and 26" numbers the authors found, which balance security, speed, and accuracy perfectly for this specific job.

Technical Summary: Exploring CKKS Parameter Trade-offs for Privacy-Preserving Personalized Federated Learning

Problem Statement

Personalized Federated Learning (PFL) allows clients to collaboratively train models tailored to their local, heterogeneous data without sharing raw datasets. However, standard PFL remains vulnerable to inference attacks from "honest-but-curious" servers, which can reconstruct private training data or infer sensitive properties from exchanged model updates. While Homomorphic Encryption (HE), specifically the CKKS scheme, offers a solution by enabling server-side aggregation on encrypted updates, its application in PFL lacks systematic guidance. Practitioners face a critical gap: there is no principled framework for configuring CKKS parameters (such as ciphertext moduli) that balances the competing demands of privacy, decryption precision, and computational/communication efficiency in PFL deployments.

Methodology

The authors introduce pFedCKKS, a generic framework that integrates the CKKS HE scheme into PFL workflows. The methodology involves:

System and Threat Model: The framework operates in a cross-silo setting with an honest-but-curious server and honest clients. A trusted leader (or third party) generates CKKS keys, distributing the public and evaluation keys to the server and the secret key to clients.
Workflow Integration: The training process involves clients decrypting global parameters, performing local PFL updates (using FedFinetune, FedPer, or Ditto algorithms), encrypting the updated global parameters, and sending them to the server. The server performs homomorphic weighted aggregation of these ciphertexts without decryption.
Parameter Analysis: The authors derive constraints for CKKS parameters under a 128-bit security level. They identify that for the PFL setting (requiring only one homomorphic multiplication), the problem reduces to selecting two values: the inner prime ( $q_1$ $q_{1}$ ) and the outer prime ( $q_0 = q_2$ $q_{0} = q_{2}$ ).
- $N = 8192$ (fixed for security).
- $L = 1$ (multiplicative depth).
- Constraints: $q_0 > q_1$ and $\log_2(q_0) + \log_2(q_1) + \log_2(q_2) < 218$ .
Empirical Evaluation: The framework is implemented using the Flower FL framework and the TenSEAL library. Experiments are conducted on three datasets (FEMNIST, CelebA, Sentiment140) across three PFL algorithms. The study systematically varies the inner and outer prime bit sizes to measure:
- Communication: Bandwidth usage and overhead relative to unencrypted baselines.
- Computation: Runtime overhead (encryption/decryption vs. local training).
- Precision: Parameter-level error ( $L_1$ norm) and model-level test accuracy.

Key Contributions

pFedCKKS Framework: The first generic framework integrating CKKS into PFL, demonstrating compatibility with major PFL strategies (FedFinetune, FedPer, and Ditto).
Systematic Parameter Guide: A derivation of full CKKS parameter constraints for PFL, reducing the selection complexity to choosing just the inner and outer primes.
Trade-off Analysis: An extensive empirical evaluation revealing the inherent trade-off between precision and cost. The study identifies that the inner prime is the dominant factor for decryption precision, while both primes significantly influence communication and computation costs.
Practical Guidelines: The identification of an optimal operating point that balances efficiency and accuracy.

Results

Communication: Communication overhead increases linearly with the size of both inner and outer primes. For example, increasing the inner prime from 18 to 38 bits (with a fixed 40-bit outer prime) resulted in over 100% additional overhead. The choice of PFL algorithm also impacts absolute bandwidth; FedPer significantly reduced overhead on FEMNIST by transmitting only shared base layers, but increased it on Sentiment140 where the shared layers constituted nearly the entire model.
Computation: Computation overhead is significant only when CKKS operations (encryption/decryption) dominate local training time. In settings with small models (e.g., CelebA) or small encrypted subsets (FedPer on FEMNIST), local training masked the CKKS overhead, resulting in negligible total runtime increases. However, when CKKS operations were dominant, larger primes led to higher runtimes.
Precision:
- Inner Prime: This is the critical factor for precision. An 18-bit inner prime caused severe accuracy degradation (up to 80% drop in some cases) due to numerical instability and overflow. Increasing the inner prime to 22 bits improved accuracy but still showed observable drops. 26 bits or higher consistently maintained model accuracy comparable to the unencrypted baseline.
- Outer Prime: Had a negligible impact on both parameter-level and model-level precision.
- Convergence: Models with 22-bit inner primes showed accuracy degradation after prolonged training (accumulated noise), whereas 26-bit and higher configurations converged similarly to the baseline.

Significance and Recommendations

The paper concludes that while CKKS enables privacy-preserving PFL, naive parameter selection can lead to prohibitive costs or unusable model accuracy. The authors provide a concrete guideline for practitioners:

Recommended Configuration: A ciphertext modulus configuration of (28, 26, 28) (28-bit outer primes, 26-bit inner prime).
Rationale: This configuration minimizes communication and computational overheads while ensuring that model-level accuracy remains comparable to the unencrypted baseline. It represents the "sweet spot" where increasing the inner prime further yields diminishing returns in accuracy but incurs higher costs.

The work validates that privacy preservation in PFL is achievable with efficient performance when CKKS parameters are carefully tuned, filling a critical gap in the deployment of privacy-enhancing technologies for personalized federated learning.