Application of Homomorphic Encryption for a Secure-by-Design Approach to Protect the Confidentiality of Data in Proficiency Testing and Interlaboratory Comparisons

Abstract

Accredited laboratories participating in Proficiency Testing (PT) and Interlaboratory Comparison (ILC) typically submit measurement results (and associated uncertainties) to an organizer for performance evaluation using statistics such as the z-score and the En value. This requirement can undermine confidentiality when the disclosed plaintext values reveal commercially sensitive methods or client-related information. This paper proposes a secure-by-design PT/ILC workflow based on fully homomorphic encryption (FHE), enabling the required scoring computations to be executed directly on ciphertexts. Using the CKKS scheme (Microsoft SEAL), the organizer distributes encrypted assigned values and a public/evaluation key set; each participant locally encrypts pre-processed measurement data, evaluates encrypted z-score and En value, and returns only encrypted performance metrics. The organizer decrypts the metrics without receiving the ciphertexts of participants’ raw measurement values. We quantify feasibility via execution time, run-to-run variability across fresh key generations (coefficient of variation), and relative calculation error versus plaintext scoring. On commodity hardware, end-to-end score computation takes 1 to 8 s, the coefficient of variation can be reduced below 1e⁻¹⁰, and the relative error remains below 1e⁻⁶, indicating practical deployability and numerical stability for PT/ILC decision-making. Given that PT/ILC reporting cycles are typically on the order of days to weeks, a per-participant computation time of seconds is operationally negligible, while the observed coefficient of variation and relative error indicate that the CKKS approximation and key-dependent variability are far below typical decision thresholds used for pass/fail classification.

1. Introduction

Accredited laboratories are one of the stakeholders in metrology and quality assurance. In order to validate their measurement accuracy, demonstrate competence, and continuously enhance processes, accredited laboratories shall monitor its performance by comparison with results of other laboratories, where available and appropriate [1]. The two most common tests are Interlaboratory Comparison (ILC) and Proficiency Testing (PT) [2,3]. In both (ILC and PT), two or more laboratories are measuring the same value and are comparing their measurements with the assigned value.

The assigned value can be determined in various ways [2,3,4] and our method is at the moment not applicable in cases when the participant’s result is compared with combined results from a group in the same round, i.e., it is applicable in all methods when the assigned value is determined independently of participants’ results.

The participating laboratories are sending their measurement results to the PT provider or ILC organizer, which we will refer to in the remaining text as the “organizer”. The organizer calculates the metrics used for laboratory evaluation. The two common metrics used for laboratory evaluation during ILC and PT are z-score and En score [4,5,6,7,8]. From a practical PT/ILC perspective, the z-score is a widely used dispersion-based performance statistic, whereas the En score explicitly incorporates the participant’s and assigned value’s (expanded) measurement uncertainties and is therefore frequently used in calibration-oriented comparisons where uncertainties are routinely reported [4,5]. To calculate these metrics, the participating laboratories (participants) that are being evaluated must disclose their plaintext measured values to the organizer, hence affecting data confidentiality. This could be an issue for the following reasons:

-

Laboratories may be reluctant to share plaintext measured values that could reveal to competitors their methodological or technological advantages;

-

Sharing plaintext data could inadvertently expose sensitive information, in sectors governed by strict data protection regulations;

-

Laboratories handling client-specific samples must ensure that data shared during PT or ILCs do not compromise client confidentiality, especially when results are linked to identifiable client information;

-

Laboratories might be concerned that sharing plaintext data could be misused or used in ways beyond the intended scope of quality assessment, leading to biased assessments.

The aspect of confidentiality is part of relevant standards [1,2] and it is the responsibility of the organizer to fulfill legal obligations related to the confidentiality.

Conventional encryption (e.g., TLS for transport and disk encryption for storage) protects PT/ILC submissions in transit and at rest, but the organizer must still decrypt the results to compute performance statistics; thus, plaintext exposure remains inherent to the computation step.

In this paper we are proposing a secure-by-design solution that inherently safeguards data confidence even during the computation step. This approach ensures that participants can trust the confidentiality of their data without depending entirely on the organizer’s mechanisms. Our solution is based on the usage of fully homomorphic encryption (FHE) [9] to achieve data confidentiality while simultaneously allowing the calculation of required metrics. Homomorphic encryption is a form of encryption that makes it possible to perform calculations on encrypted data without having to decrypt it, meaning that the data can remain confidential while it is being processed, which could be particularly useful in scenarios such as ILC/PC. This unique feature of FHE is achieved by using so-called homomorphic schemes, each with its own pros and cons.

The two most common FHE schemes are BGV (Brakerski–Gentry–Vaikuntanathan) [10] and CKKS (Cheon–Kim–Kim–Song) [11]. BGV is a fully homomorphic encryption scheme that supports efficient arithmetic operations over integers. It is suitable for a wide range of applications due to its flexibility and efficiency. It is more precise than the CKKS scheme which is designed for approximate arithmetic, making it particularly useful for machine learning tasks [12] where exact precision is not required.

Historically, the FHE grew from being able to handle only additions, then subtractions, up to a point where it can handle multiplications and machine learning algorithms [13,14,15]. FHE is extensively evaluated as a promising candidate for secure cloud computing [16,17,18], privacy-preserving third-party data analytics [19,20], and also for sensitive use cases such as healthcare [21,22]. With homomorphic encryption, basic arithmetic operations such as addition and multiplication can be performed directly on encrypted data. More complex operations can be developed from these primitives. However, due to its nature, homomorphic encryption causes a significant computational overhead compared to unencrypted operations. Operations on encrypted data are significantly slower compared to operations on plaintext.

Schemes such as BGV and CKKS allow a certain number of operations based on the initial parameters specified during encryption. These parameters determine the allowed computation depth. Computation depth refers to the number of sequential operations, especially multiplications, that can be performed on encrypted data before the noise in the ciphertext becomes too large to cope with. In homomorphic encryption, noise is a byproduct of encryption and computation operations. Each operation, especially multiplications, introduces additional noise into the ciphertext. As more operations are performed, this noise accumulates. If the noise becomes too large, it can corrupt the ciphertext and make decryption impossible or lead to incorrect results.

The computation depth effectively limits the number of operations that can be performed before the ciphertext has to decrypted. For most homomorphic encryption schemes, there is a maximum depth beyond which no operations can be performed without failing or requiring techniques such as bootstrapping. Bootstrapping is a technique for resetting the noise in a ciphertext that enables further operations. Bootstrapping enables unlimited computation depth, but is computationally expensive and increases the size of the ciphertext. In practice, understanding the computation depth is crucial for the development of algorithms that are to run on encrypted data. Operations must be structured to stay within the allowed depth, or bootstrapping must be carefully managed to ensure correctness without excessive overhead.

FHE is an asymmetrical encryption technique which employs a public and private key pair. The public key is used for encrypting data and performing operations on the encrypted data. The private key is used to decrypt the final result after the calculation is complete. Regarding the security aspect, homomorphic encryption relies on well-established hard problems in mathematics, such as the Learning With Errors (LWE) problem, making it cryptographically secure under the current state of knowledge. The security also depends on the implementation of the FHE. There is a number of available FHE libraries and for this work Microsoft SEAL is used, which supports 128-bit, 192-bit, and 256-bit security levels [23].

FHE has seen rapid progress in recent years. In [24], the authors extended the OpenFHE library (CKKS scheme) to support advanced functions (division, square root, logarithm) homomorphically, demonstrating that complex transformations can be performed on encrypted data. Other studies have applied homomorphic encryption and related cryptographic techniques in multi-party settings—e.g., ref. [25] introduced a multiparty HE framework for federated medical data analysis—underscoring the feasibility of privacy-preserving computations in practice. However, to our knowledge, no prior work has specifically addressed confidentiality in interlaboratory proficiency tests using FHE, which is the focus of this paper.

Thereby, applying FHE to Proficiency Testing presents several challenges that must be addressed. First, FHE incurs significant computational overhead (encryption and homomorphic computation are far slower than plaintext processing), which could affect the efficiency of PT programs. Second, current FHE schemes support only basic arithmetic (addition and multiplication)—more complex operations (e.g., computing a mean or a standard deviation) are not straightforward. For instance, our scheme uses an iterative Newton–Raphson method to perform division on encrypted data [24], since no direct division operation exists in CKKS. Third, the CKKS FHE scheme produces approximate results; thus, we must ensure that encryption-induced numerical errors are minimized so that PT outcomes (like assigned En values and z-scores) remain accurate [26]. Finally, a secure key management strategy is needed in a multi-party setting: all participants and the organizer could use a common public key, but decryption rights must be handled carefully (e.g., via a trusted party or threshold decryption) to prevent any single semi-trusted entity from accessing plaintext results.

In Section 2, the proposed solution for ILC/PT using fully homomorphic encryption is described. A solution overview is given followed by a detailed explanation of required calculations, both regular calculations in plaintext and encrypted calculations using FHE. Special attention is given to the application of the Newton–Raphson method which is used to implement encrypted division. Section 3 describes the implementation of the proposed solution using the Microsoft SEAL homomorphic library [27]. Implementation is tested and the results for execution time, coefficient of variance, and relative calculation error are presented. At the end of the paper, a conclusion and references are given.

The main contributions of this work are as follows:

(1)

A secure-by-design PT/ILC workflow that preserves the confidentiality of participants’ measurement data while still enabling the organizer to obtain required performance metrics.

(2)

A computation-efficient homomorphic formulation of z-score and En score based on plaintext pre-/post-processing plus ciphertext arithmetic, including a Newton–Raphson-based encrypted inversion to implement division without bootstrapping.

(3)

A reference implementation in Microsoft SEAL (CKKS) together with an evaluation of practical feasibility, reporting runtime, coefficient of variation across fresh key generations, and relative scoring error as a function of CKKS parameter choices.

2. Proposed Solution for ILC/PT Using Fully Homomorphic Encryption

In Interlaboratory Comparison (ILC) and Proficiency Testing (PT), at least two laboratories must participate—the organizer and the participant that is being evaluated. The organizer provides assigned values and the participant provides measured values. For ILC/PT, two metrics are commonly used: z-score and En score. Equations for the calculation of z-score and En score are given below:

$$z={\displaystyle \frac{{\overline{X}}_{MV} - {\overline{X}}_{AV}}{{\sigma }_{RD}}},$$

(1)

${\overline{X}}_{MV}$—average value of measured values

${\overline{X}}_{AV}$—average value of assigned values

${\sigma }_{AV}$—standard deviation of assigned values

$$E_n={\displaystyle \frac{{\overline{X}}_{MV}-{\overline{X}}_{AV}}{\sqrt{{U_{MV}}^2+{U_{AV}}^2}}}$$

(2)

$U_{MV}$—expanded measurement uncertainty of measured values

$U_{AV}$—expanded measurement uncertainty of assigned values

It can be seen that for the calculation of z-score and En score, both assigned and measured values are required. Currently, at least one laboratory (this is usually the participant) must send its data to the other laboratory (this is usually the organizer). It is a necessary step, but one that negatively affects data confidentiality. Our proposed solution uses homomorphic encryption to ensure data confidentiality and at the same time enable the calculations of required metrics. As briefly explained in the Introduction, the homomorphic encryption enables calculations on encrypted data. This feature comes with a certain cost: the encrypted data size is significantly larger than plaintext data size, and also the calculations are computation-heavy. But, in the current state-of-the-art, it is the only solution to achieve data confidentiality in Interlaboratory Comparison (ILC) and Proficiency Testing (PT). The only approach that offers a certain level of data confidentiality is a concept called multi-party distributed calculation [28,29], but it does not use encrypted calculations and is therefore less secure and more prone to intentional miscalculations.

2.1. Solution Overview

In this work, we use the CKKS FHE scheme for encrypting real-number data. CKKS supports arithmetic on encrypted real-valued vectors but yields results with slight approximation error due to its design. We chose CKKS for its efficient handling of floating-point operations, which suits the numeric data in Proficiency Testing. To enable operations like division on ciphertexts (which FHE does not natively support), we employ an iterative Newton–Raphson algorithm. This method finds reciprocals or square roots by iteration: starting from an initial guess and refining it via multiplication and addition operations (which are supported homomorphically). We adopt this approach following prior research that showed its efficiency in the encrypted domain [24], and we detail its use in our context (e.g., computing 1/σ for standard deviation calculation) in Section 2.3.

The proposed high-level solution overview is given in Figure 1. There are two roles in ILC/PT—one organizer, who provides the assigned values, and one or more participating laboratories. When the ILC/PT is concluded, the organizer writes a report for each participant where their calculated performance metric is given. To calculate performance metrics, the common practice is that each participant sends its plaintext measured values to the organizer. With our proposed solution which uses FHE, the participant does not need to disclose its plaintext data to the organizer in order to have performance metrics calculated.

2.2. Key Management and Threat Model

In the proposed solution, the homomorphic encryption key pair is generated by the organizer, who retains the private key and never shares it. The organizer distributes only the public key (along with its assigned values encrypted under that key) to all participants. Each participant uses this public key to encrypt its own measured values and then performs the homomorphic computations locally on these encrypted inputs. Crucially, the encrypted measured data never leave the participant’s domain during this process. Only the final encrypted performance metrics (e.g., z-score and En scores) are sent back to the organizer. Since only the organizer holds the private key, it alone can decrypt these results to obtain the plaintext metrics. This key management scheme ensures that participants’ raw data remain confidential at all times, as all intermediate values stay encrypted and confined to the participant’s environment.

We assume an honest-but-curious model: the PT Organizer and all participants follow the protocol faithfully but are curious to learn additional information. They do not tamper with data or deviate from the protocol (no malicious forgery or DOS attacks), but they will analyze any information they see to glean secrets. We also assume no collusion beyond what the protocol allows (e.g., participants do not share their secret keys with the organizer). From the organizer’s perspective, all participant results are received in encrypted form. Our use of the CKKS FHE scheme ensures that these ciphertexts appear as random data; without the decryption key, the organizer cannot distinguish or decode any individual result. From a participant’s perspective, the only information ultimately revealed to all parties is the final PT summary (and each participant’s own performance score). A participant might attempt to infer a competitor’s result by analyzing changes in the reported statistics. However, since each individual contribution remains concealed by encryption during processing, and only aggregate results (like mean and SD) are published, it is computationally infeasible to extract an exact peer value from these aggregates unless the group size is extremely small. Our protocol does not output any individual encrypted result or intermediate value that could be decrypted by others. Therefore, under the honest-but-curious assumption, participants gain no advantage in guessing others’ data beyond what the official outcomes imply.

However, it is important to note that even when only encrypted performance metrics (such as z- and En scores) are revealed, an organizer observing these metrics over multiple Proficiency Testing rounds could potentially infer meta-information about a participant’s measurements. In other words, consistent patterns in the metrics (e.g., a laboratory’s scores being repeatedly on one side of the assigned value) might allow the organizer to approximate the participant’s measurement mean or identify a systematic bias. We acknowledge this potential leakage of information as a limitation of the current secure-by-design scheme. Potential strategies to further protect participant confidentiality include introducing random obfuscation or differential privacy techniques into the reported metrics (to reduce the accuracy of any inferences), as well as rotating encryption keys or protocols between successive PT/ILC rounds to limit cross-round correlation of results. These measures fall outside the scope of our present study, but we identify them as important directions for enhancing the threat model in future implementations.

2.3. Data Processing and Homomorphic Calculations

The data in Figure 1 is color coded. Red blocks represent plaintext (unencrypted) data. Encrypted data is shown with two colors: green and orange. Green blocks represent “secure” encrypted data (e.g., encrypted assigned values that organizer encrypted with its own public key), while orange blocks represent “unsecure” encrypted data (e.g., encrypted measured values that participant encrypted with organizer’s public key). To ensure that the proposed solution is secure-by-design, the orange data (participant data encrypted with organizer’s public key) should never leave the participant’s own data space. Therefore, the encrypted calculations are performed on the participant’s side. The calculated (encrypted) values for z-score and En score are considered “secure” encrypted data (marked by green block) because the participant’s raw measured values cannot be extracted. The blue block represents the decrypted calculation result, i.e., performance metrics, and white blocks are FHE keys (public and private).

To reduce the number and complexity of homomorphic operations, the solution offloads most of the z-score and En score calculations to plaintext pre-processing by both the organizer and participant. Only the final computation steps occur on encrypted data, which keeps the overall computational complexity low and guarantees that the raw measurement data from both parties remain confidential.

Plaintext input data consist of the following data sets and values:

-

Measured values x_MV1 … x_MVm;

-

Measurement uncertainty of type B for measured values U_{B_MV};

-

Assigned values x_AV1 … x_AVn;

-

Measurement uncertainty of type B for assigned values U_{B_AV};

-

Expansion factor k.

The plaintext input data is first pre-processed to simplify the homomorphic calculations that are performed on pre-processed data.

Measured values pre-processing consists of calculating the average of measured values ${\overline{X}}_{MV}$, standard deviation of measured values ${\sigma }_{MV}$, inverse value of standard deviation, measurement uncertainty of type A for measured values $U_{A\_MV}$, expanded measurement uncertainty of measured values $U_{MV}$, and squared value of expanded measurement uncertainty of measured values, Equations (3)–(8).

$${\overline{X}}_{MV}={\displaystyle \frac{{{\displaystyle \sum }}_{i=1}^m{x}_{MVi}}{m}},$$

(3)

$${\sigma }_{MV}=\sqrt{{\displaystyle \frac{{{\displaystyle \sum }}_{i=1}^m{\left(x_{MVi}-{\overline{X}}_{MV}\right)}^2}{m}}},$$

(4)

$${\sigma }_{MV\_INVERSE}={\displaystyle \frac{1}{{\sigma }_{MV}}},$$

(5)

$$U_{A\_MV}={\displaystyle \frac{{\sigma }_{MV}}{\sqrt{m}}},$$

(6)

$$U_{MV}=k\times \sqrt{{U_{A\_MV}}^2+{U_{B\_MV}}^2},$$

(7)

$$U_{MV^2}={U_{MV}}^2,$$

(8)

Assigned values pre-processing consists of calculating the average of assigned values ${\overline{X}}_{AV}$ standard deviation of assigned values ${\sigma }_{AV}$, inverse value of standard deviation, measurement uncertainty of type A for assigned values $U_{A\_AV}$, expanded measurement uncertainty of assigned values $U_{AV}$, and squared value of expanded measurement uncertainty of assigned values, Equations (9)–(14).

$${\overline{X}}_{AV}={\displaystyle \frac{{{\displaystyle \sum }}_{i=1}^n{x}_{AVi}}{n}},$$

(9)

$${\sigma }_{AV}=\sqrt{{\displaystyle \frac{{{\displaystyle \sum }}_{i=1}^n{\left(x_{AVi}-{\overline{X}}_{AV}\right)}^2}{n}}},$$

(10)

$${\sigma }_{AV\_INVERSE}={\displaystyle \frac{1}{{\sigma }_{AV}}},$$

(11)

$$U_{A\_AV}={\displaystyle \frac{{\sigma }_{AV}}{\sqrt{n}}},$$

(12)

$$U_{AV}=k\times \sqrt{{U_{A\_AV}}^2+{U_{B\_AV}}^2},$$

(13)

$$U_{AV^2}={U_{AV}}^2,$$

(14)

Encryption is performed on both sides. The participant and organizer are encrypting their pre-processed data: ${\overline{X}}_{MV}$, ${\overline{X}}_{AV}$, ${\sigma }_{AV\_INVERSE}$, $U_{MV^2}$, $U_{AV^2}$. Since the data can only be decrypted by the organizer, the organizer can safely send its encrypted data to the participant.

Homomorphic calculations are performed by participant who calculates the z-score value, and squared value of En score En_^2, (15) and (16). Symbols in formulas that are marked bold indicate encrypted values.

$$\mathit{z}=\left({\overline{\mathit{X}}}_{\mathit{M}\mathit{V}}-{\overline{\mathit{X}}}_{\mathit{A}\mathit{V}}\right)\times {\mathit{\sigma }}_{\mathit{A}\mathit{V}\_\mathit{I}\mathit{N}\mathit{V}\mathit{E}\mathit{R}\mathit{S}\mathit{E}},$$

(15)

$${\mathit{E}}_{\mathit{n}^2}={\left({\overline{\mathit{X}}}_{\mathit{M}\mathit{V}}-{\overline{\mathit{X}}}_{\mathit{A}\mathit{V}}\right)}^2\times {\left({\mathit{U}}_{\mathit{M}\mathit{V}^2}+{\mathit{U}}_{\mathit{A}\mathit{V}^2}\right)}_{\mathit{I}\mathit{N}\mathit{V}\mathit{E}\mathit{R}\mathit{S}\mathit{E}},$$

(16)

The methodology for calculation of the inverse value of ($U_{MV^2}+U_{AV^2}$) is given in Section 2.4.

Decryption and data post-processing are performed by the organizer.

$$z=decrypt\left(\mathit{z}\right),$$

(17)

$$E_{n^2}=decrypt\left({\mathit{E}}_{\mathit{n}^2}\right),$$

(18)

$$E_n=\sqrt{E_{n^2}},$$

(19)

No additional post-processing is required for the z-score calculation. For En score, an additional calculation step is required during post-processing. The square root is not a native function in FHE and is therefore performed during post-processing of the data. The only drawback of such an approach is that the calculated En score is actually its absolute value and the sign of the En score cannot be determined. However, with ILC/PT, the sign of the En score is not crucial information; the metric only uses its absolute value.

2.4. Newton–Raphson Method for Homomorphic Division

In the presented use case, where homomorphic calculations are used in ILC/PT to calculate z-score and En score, the homomorphic division must be implemented for En score calculation (2). Since the square root is not a native calculation in FHE, the homomorphic calculations are used to calculate En_^2 (16), which is then in plaintext square rooted to obtain the absolute value of En score (19). But we still need to homomorphically calculate the inverse of $U_{MV^2}+U_{AV^2}$ (16).

Division is also not a native operation in FHE, and has to be implemented separately. For this use case, a division is achieved as a multiplication with the inverse of a number, where a Newton–Raphson method is used to calculate the inverse of a number.

$$division={\displaystyle \frac{A}{B}}=A\times B_{INVERSE},$$

(20)

In a Newton–Raphson method, to calculate an inverse value of B (x = 1/B), a function f(x) must be defined in such a way that is equals zero:

$$f\left(x\right)=0,$$

(21)

The value of x is then calculated by an iterative process:

$$x_{n+1}=x_n-{\displaystyle \frac{f\left(x_n\right)}{f^{\prime }\left(x_n\right)}},$$

(22)

For the calculation of the inverse of number B, the following function f(x) is used:

$$f\left(x\right)={\displaystyle \frac{1}{x}}-B,$$

(23)

$$f^{\prime }\left(x\right)=-{\displaystyle \frac{1}{x^2}},$$

(24)

When combined with Equation (22), it results in an iterative function:

$$x_{n+1}=x_n\left(2-B\times x_n\right),$$

(25)

In the Newton–Raphson method, the correct choice of the initial value x₀ is decisive for the convergence of an iterative function.

For the Newton–Raphson method to work properly, the following two conditions must be met. The first condition is that the initial value must be chosen correctly. The second condition is that the sign of the number whose inverse is calculated must be known or it must always be the same. The second condition is always met in the proposed use case. The number will always be positive because it is a sum of two squared values (16).

As shown in Figure 2, the Newton–Raphson method converges for a narrow range of initial value x₀. The initial value must be selected such that it is between zero and 2/B [30]. The border values (0 and 2/B) should not be selected as they result in null value,

Table 1. Impact of initial value on the convergence of Newton–Raphson method.

For Positive Number B		For Negative Number B
Initial Value Range	Result	Initial Value Range	Result
(−∞ to 0)	diverges to −∞	(−∞ to 2/B)	diverges to +∞
0	0	2/B	0
(0 to 2/B)	converges to 1/B	(2/B to 0)	converges to 1/B
2/B	0	0	0
(2/B to +∞)	diverges to −∞	(0 to +∞)	diverges to +∞

. To solve the problem of the initial value selection, the approach presented here uses the premise that is inherent for the ILC/PT procedures. The organizer is expected to be more accurate/precise than the participant. This implies that the expanded measurement uncertainty of assigned values U_AV is lower compared to the expanded measurement uncertainty of measured values U_MV.

As mentioned in Section 2.3, the homomorphic calculations are performed by the participant. Therefore, the participant must select the initial value. The participant knows the exact value of the expanded measurement uncertainty of its own measured values U_MV and it knows that it is larger than the expanded measurement uncertainty of assigned values U_AV. So, theoretically, the measurement uncertainty of assigned values U_AV can only be in the range of zero to U_MV. This is sufficient to place the initial value within the desired range (0 to 2/B).

But, even with the initial value properly selected, the number of iterations required for a convergence with a certain accuracy varies. Figure 3 shows the number of iterations required for convergence of the solution. With each consecutive iteration, the error between the iterative value and correct values decreases. To define convergence, we have used a relative error under 0.1%. The number of required iterations increases significantly as the initial value approaches zero or 2/B.

The most appropriate initial value x₀ is 1/(1.5*U_MV²) because it converges the fastest for the entire possible range (from 1/(2*U_MV²) to 1/U_MV²). This initial value ranges from 0.67/B to 1.33/B and it significantly reduces the number of required iterations for convergence, Figure 4. With initial value x₀ selected in a such way, after three iterations, the maximal error in the calculated inverse value of 1/(U_MV² + U_AV²) is less than 0.0153%. A relative error distribution across the initial value range after three iterations is given in Figure 5.

It can be seen that for the majority of the initial value range, the relative error is significantly lower than 0.0153%. This is because the relative error has the highest values for the borderline scenarios (U_AV = 0 → x₀ = 0.67/B and U_AV = U_MV → x₀ = 1.33/B). It is important to emphasize that the borderline scenarios are purely theoretical, since the expanded measurement uncertainty of assigned values U_AV is always higher than zero and lower than the expanded measurement uncertainty of measured values U_MV. If even lower relative error is required, it can be achieved by additional iterations, Figure 6.

3. Implementation and Verification

The proposed method for ILC/PT using FHE is implemented using the Microsoft SEAL library. Microsoft SEAL is a homomorphic encryption library that allows additions and multiplications to be performed on encrypted integers or real numbers [27]. It supports two different types of FHE schemes: BFV and BGV schemes allow modular arithmetic to be performed on encrypted integers, and the CKKS scheme allows additions and multiplications on encrypted real or complex numbers, but yields only approximate results.

3.1. Implementation Specifics of SEAL Library

For the proposed use case, we opted for the CKKS scheme because the calculation of z-score and En score requires mathematical operations on real numbers. As CKKS yields only approximate results, this section will also address the accuracy of the implemented homomorphic calculation method. The calculations are implemented as described in Section 2, and for inverse number calculation, three iterations are chosen.

To implement homomorphic calculations using the SEAL library, two parameters for setting the CKKS scheme must be selected: poly_modulus_degree and coeff_modulus. The poly_modulus_degree must be a positive power of 2 [27], where larger values of poly_modulus_degree enable more complex encrypted computations, but make ciphertext sizes larger and all operations slower. Recommended values for poly_modulus_degree are 1024, 2048, 4096, 8192, 16,384, and 32,768.

After the poly_modulus_degree has been selected, the coeff_modulus can be chosen. It is a large integer, which is a product of distinct prime numbers, each up to 60 bits in size. The coef_modulus is represented as a vector of these prime numbers. The bit-length of coeff_modulus is equal to the sum of the bit-lengths of its prime factors. A larger coeff_modulus enables more complex encrypted computation, but there is an upper bound for the total bit-length of the coeff_modulus. It is determined by the poly_modulus_degree; see max coeff_modulus bit-length in

Table 2. Initial SEAL CKKS encryption parameter combinations used for testing (failed parameter combinations marked in gray).

Poly_ Modulus_ Degree	Max Bit-Length of Coeff_ Modulus	Chosen Coeff_Modulus	Chosen Bit-Length of Coeff_ Modulus
2048	54	5, 5, 5, 5, 5, 5, 5, 5, 5, 5	50
4096	109	10, 10, 10, 10, 10, 10, 10, 10, 10, 10	100
8192	218	20, 20, 20, 20, 20, 20, 20, 20, 20, 20	200
16,384	438	40, 40, 40, 40, 40, 40, 40, 40, 40, 40	400
32,768	881	60, 60, 60, 60, 60, 60, 60, 60, 60, 60	600

. For example, if poly_modulus_degree is 8192, the coeff_modulus could consist of six 36-bit primes (216 bits).

The selected values of poly_modulus_degree and coeff_modulus impact the precision and the execution speed. As explained in the Introduction, homomorphic multiplications are “expensive”, so the number of consecutive multiplication operations determines the size of coeff_modulus. Namely, coeff_modulus is a product of several large prime numbers. In our implementation with three iterations for inverse number calculation, eight consecutive multiplication operations are used, and therefore the coeff_modulus must be a product of at least 10 prime numbers—one for key generation, eight for each consecutive multiplication, and one for decryption.

To keep the computational complexity, ciphertext sizes, and calculation time as low as possible, and at the same time to achieve the required precision, it is necessary to choose the most suitable combination of poly_modulus_degree and coeff_modulus.

3.2. Testing and Verification Results

The initial selection of coeff_modulus values for each poly_modulus_degree is given in Table 2. The calculation requires that the coeff_modulus is a product of 10 prime numbers, the largest of which is then selected. More precisely, the largest possible prime number size is selected for poly_modulus degree 2048, and for each consecutive poly_modulus_degree, the size of primes is doubled. The only exception is for a poly_modulus_degree of 32,768, where each coeff_modulus is 60 (instead of 80), because 60 is the maximum allowed size of primes used for coeff_modulus.

For the poly_modulus_degree sizes of 2048, 4096, and 8192, the proposed solution could not be implemented because it fails to find enough qualifying primes (prime numbers) with the selected bit-length (5 for 2048, 10 for 4096, 20 for 8192). Additional tests showed that the smallest bit-length of each prime number must be at least 23 bits. While the solution can be implemented with 23-bit primes, the computation error is quite high. Therefore, in further tests, the lowest size of prime numbers was set to 30 bits.

Tests evaluated the impact of the selected poly_modulus_degree, coeff_modulus, and number of iterations used for inverse number calculation on the following three parameters: execution time, coefficient of variance, and relative error of calculation. Coefficient of variance was added because the calculation results differ when the same calculation is repeated with different cryptographic keys. All test were carried out on a Lenovo ThinkBook 16p Gen2 laptop with AMD Ryzen 9 5900HX with Radeon Graphics 3.30 GHz processor, 32 GB of RAM, and 64-bit Windows 10 Pro operating system.

Testing results have shown that the execution time increases with larger poly_modulus_degree and with the number of iterations used for inverse number calculation, Figure 7. To achieve higher repeatability of calculations, larger prime numbers should be used in coef_modulus, Figure 8.

The En score calculation is more complex than the z-score calculation, and this is also evident in the coefficient of variance, where z-score achieves better results, i.e., lower values of coefficient of variance. The selection of poly_modulus_degree does not have a significant impact on the coefficient of variance, but it can be observed that smaller poly_modulus_degree results in slightly better performance.

When observing the relative calculation error for z-score, the results are very similar for both tested values of poly_modulus_degree (16,384 and 32,768). The main impact on the relative error was the size of prime numbers used in coeff_modulus, Figure 9.

Situation is somewhat different for relative calculation error for En score. Namely, to calculate En score, an iterative method for inverse number calculation is used, and these additional computation steps add significant error to the calculation result, Figure 10 and Figure 11. The size of prime numbers used in coeff_modulus has the same impact as in z-score calculation. Larger primes result in lower error, but the overall error values are three orders of magnitude higher compared to the relative calculation error for z-score, Figure 10. Results shown in Figure 11 may look as they are not “complete” compared to Figure 10. This is due to the lower poly_modulus_degree (in Figure 11) which does not support required coeff_modulus values for test cases with a large number of iterations and large primes.

In PT/ILC practice, En values are commonly interpreted with a decision threshold around |En| ≤ 1 due to the use of expanded uncertainties [5]. Consequently, the relative computational errors observed here (≈1e⁻⁶) are unlikely to affect pass/fail decisions except for borderline cases very close to |En| ≈ 1; in such cases, additional Newton–Raphson iterations and/or more conservative CKKS parameterization can be used at the expense of runtime. Future work will focus on optimizing the encrypted En computation (e.g., improved inverse approximation and parameter tuning) to reduce runtime and error sensitivity.

4. Conclusions

This work addresses the confidentiality gap in Proficiency Testing and Interlaboratory Comparison (PT/ILC), where performance evaluation traditionally requires participants to disclose plaintext measurement results (and uncertainties) to the organizer for scoring. We proposed a secure-by-design workflow based on fully homomorphic encryption (FHE) that keeps participants’ raw measurement values within the participants’ domain while still enabling the organizer to obtain the required performance metrics (z-score and En score). The workflow combines plaintext pre-/post-processing with ciphertext arithmetic (including Newton–Raphson-based ciphertext inversion for division) and is implemented using the CKKS scheme in Microsoft SEAL. Experimental evaluation shows that encrypted scoring is feasible on commodity hardware (1 to 8 s runtime) with negligible run-to-run variability (coefficient of variation down to 1e⁻¹⁰) and small approximation error (relative error below 1e⁻⁶), supporting practical PT/ILC deployment where confidentiality requirements are strict.

These results can be achieved by a suitable selection of the two FHE parameters: poly_modulus_degree and coeff_modulus. As a rule of thumb, a larger poly_modulus_degree leads to a longer execution time and a lower relative computation error. As far as the coefficient of variance is concerned, the best results are achieved when a lower value for poly_modulus_degree and a higher value for coeff_modulus are used. This is a contradictory requirement, because a large poly_modulus_degree enables a large coeff_modulus.

To summarize, the proposed solution achieves data confidentiality by using encrypted homomorphic calculations with a low relative computational error (below 1e⁻⁶). Thus, calculated scores accurately reflect the performance of the laboratory without being affected by computational inaccuracies. The proposed approach can be generalized to facilitate applications in other domains (e.g., finance, health, …) and to ensure the credibility of the data when using “third party” data analysis.

Future work will focus on enhancing both the security and efficiency of encrypted En computations by exploring stronger privacy-preserving techniques and optimizing computational accuracy and performance.