Janus: Dual-server Multi-Round Secure Aggregation with Verifiability for Federated Learning

Thank you for your valuable feedback, and we address your concerns as follows.

$**1. Security (Q1, Q2, Q5, Q13-15) **$.

Q1: Unlike existing single-server schemes (e.g., VeriFL), which require the server to aggregate results and thus fail to resist MIA, our Janus scheme enables dynamic user participation while resisting MIA and ensuring verifiability. Additionally, Janus is more efficient, relying on simple one-time pads (OTP) and SHC, rather than complex cryptographic tools like homomorphic encryption or secret sharing. We will highlight these advantages in the revised version.

Q2: Janus resists collusion of up to $n-2$ clients. If $n-1$ clients collude, they can trivially deduce the remaining client’s information. However, with $n-2$colluding clients, they can only obtain the additive result of two uncolluding clients. This result is an aggregation of two encrypted or obfuscated values, making it impossible to recover each uncolluding user's specific gradient information. We will provide a detailed analysis of this property for clarity.

Q5: The masking technique used in $*Janus*$ is OTP. As long as each secret key ($sk$) is used only once per round, the masked inputs reveal no information about the original values, even a single bit. Therefore, differential analysis is ineffective in this context.

Q13–15: Our theoretical analysis supports the claimed properties of resisting MIA, supporting multiple rounds, and tolerating a maximum number of colluding clients. This is similar to the approaches used in Flamingo (SP’23) and Securing Secure Aggregation (AAAI’23), where theoretical analysis is also employed.

$**2. SHC (Q6-7, Q16)**$.

In Section 3.1, we clarify that SHC requires completeness, binding, hiding, separability, and homomorphism. The hash-based commitment you mentioned does not meet these requirements, so length extension attacks do not apply. Our design does not require additional properties like trapdoors or equivalence (as in VeriFL), which simplifies the design and improves performance without compromising security. The Pedersen commitment, a widely used SHC, serves as a strong example of our approach’s security, as demonstrated in blockchain systems like Monero and ZCash.

$**3. Dropout (Q3, Q4)**$.

Q3: In traditional schemes, all users need to negotiate a shared key as a mask before communication. If a user fails to upload masked parameters in later stages, the mask cannot be canceled across the system. However, our scheme avoids establishing complex communication graphs and only requires a single interaction with the server, thus eliminating the dropout issues present in traditional schemes. The only potential problem arises if a user fails to update both servers, but this is trivially avoided by ensuring synchronization between the two servers. This ensures that both servers either receive the message or don’t receive it at all, thus maintaining atomicity. However, traditional schemes cannot resolve dropout issues via this simply synchronization method.

Q4: We will include experiments with varying dropout rates in the revised version. These do not involve complex techniques and will help validate our claims.

$**4. Experiments (Q8-Q12)**$.

In lines 438-443, we have explained the specific parameters used in the experimental setup to ensure reproducibility. Our scheme is not limited to specific models or datasets, and the paper includes theoretical analysis and experimental comparisons of each scheme’s performance across different models and datasets (lines 362-564). The theoretical analysis shows that our scheme significantly improves computational efficiency. To further highlight the advantages of $*Janus*$, we will add experiments validating performance in terms of computational and communication costs. We have already conducted multi-round aggregation experiments, which are similar to those with varying numbers of users. Additionally, we will include new datasets (e.g., CIFAR-100, Fashion-MNIST) and advanced comparison schemes (e.g., Elsa (SP’23), VeriFL (2020)) in the updated version.

We greatly appreciate your feedback and will ensure these clarifications are included in the revised manuscript. If you have any further concerns, please let us know.

Thank you for your insightful feedback. Below, we address your concerns.

1. $**Versatility**$. This property highlights that our scheme is a generic construction, not limited to specific cryptographic tools like Separable Homomorphic Commitments (SHC) or one-time pads (OTP). In contrast, other schemes rely on specific tools, lacking such flexibility. We will add a description of this versatility in the revised paper.

2. $**Comparison with 2PC and Other Schemes**$. While 2PC is simple and direct, it often relies on resource-intensive homomorphic encryption and zero-knowledge proofs. In contrast, our scheme uses lightweight cryptographic primitives (SHC and OTP). ELSA assumes at least one honest server, whereas our scheme only requires two uncolluding servers, allowing for malicious server aggregation. We will correct the threat model in the revised paper to reflect that servers can be malicious. Our scheme can detect malicious aggregation through its built-in verifiability, which provides an advantage over these approaches.

3. $**Advantages**$. In addition to comparing accuracy and loss, we evaluate the single-round computational cost of each scheme across different models and datasets (lines 483–524). Our analysis shows that while secure aggregation inevitably increases computational cost compared to plaintext aggregation, our scheme achieves substantial efficiency improvements over other advanced secure aggregation schemes of the same type.

4. $**User Join and Sybil Attacks Resistance**$. In lines 23–25 and lines 301-308, we explain how new users can join the training process. A new user simply needs to acquire the system’s public parameters, generate a public-private key pair, and obtain the server’s public key. The key is certified by authorities to authenticate the user’s identity. This approach avoids the need for rebuilding the communication graph when users leave, which distinguishes our scheme from others. An adversary attempting a Sybil attack could obtain encrypted data, but would not be able to perform a MIA, as controlling at least $n-1$ users would be required to access private input. Additionally, our scheme’s reliance on Public Key Infrastructure (PKI) and the use of certificates makes Sybil attacks even more difficult, as forgeries would require creating valid certificates from authorities. Thus, our scheme effectively mitigates Sybil attack risks.

We greatly appreciate your feedback and will incorporate these clarifications in the revised paper. Thank you again, and we look forward to your response.

We sincerely thank you for your time and valuable feedback. Below, we address the technical and theoretical concerns you raised.

1. $**Security Assumption**$. The specific assumptions in our paper are as follows: The two servers will not collude but may perform incorrect aggregation. The scheme also allows for up to $n-2$ clients to collude. Specifically, even if the server aggregates incorrect results, our scheme provides verifiability, which enables us to detect such behavior and mitigate the associated risks. If the server colludes with up to $n-2$ clients, it can only obtain the additive result of the remaining two uncolluding clients. This result is an aggregation of two encrypted or obfuscated values, making it impossible to recover each uncolluding user's specific gradient information. This ensures that the colluding entities cannot initiate a Model Inconsistency Attacks (MIA) or access the private information of the remaining two non-colluding clients. When $n-2$ clients collude, this assumption is even weaker, as the absence of server involvement further limits the accessible information, making it even harder to extract useful data. If only a single server is corrupted, this does not compromise individual user privacy. For instance, with server $S_0$, as long as the underlying encryption algorithm is secure, the server cannot access the user-submitted private data without the user's private key. Similarly, for server $S_1$, the security of the underlying Separable Homomorphic Commitment (SHC) ensures that its hiding properties prevent $S_1$ from obtaining any private information. In conclusion, the assumptions of our scheme are reasonable and well-supported. We will incorporate these clarifications in the revised version to better highlight the theoretical advantages of our approach.

2. $**Adding Experiments**$. Our scheme is not limited to specific models or datasets. In the paper, we have conducted theoretical analysis and experimental comparisons of each scheme's performance under various models and datasets (lines 362-564). Theoretical analysis indicates that our scheme significantly improves computational efficiency. However, to better showcase the advantages of our scheme, we will include additional experiments in future versions to verify performance from the perspectives of computational and communication costs. Furthermore, to address your concerns, we will add more datasets, such as CIFAR-100 and Fashion-MNIST, and include new SOTA comparison schemes like Elsa (SP’23) and VeriFL (IEEE TIFS’20) in the updated version.

3. $**Comparison with Other Schemes**$. We have already included several representative advanced schemes of the same type in the paper, but we will still add Elsa (SP’23) and VeriFL (IEEE TIFS’20) as comparison schemes. Compared to Elsa (SP’23), our scheme makes weaker assumptions, resulting in higher security while supporting multi-round aggregation with a significant performance improvement. Compared to VeriFL (IEEE TIFS’20), our scheme does not require constructing complex communication graphs or performing time-consuming secret sharing operations, which leads to substantial performance gains.

4. $**Additional Experiments**$. Thank you for your suggestion. In the paper, we have already provided single-round timing statistics for both the client and server across different models and datasets. The experiment you mentioned is feasible to add, and we will include these updated metrics in the revised version. We greatly appreciate your feedback and will ensure these clarifications are incorporated in the revised paper. Thank you once again, and we look forward to your response.

We sincerely thank you for your time and valuable feedback. Below, we address the technical and theoretical concerns you raised.

1. $**Uncolluding Assumption**$. The assumption of two uncolluding servers is common in federated learning research, as demonstrated by works like Elsa (SP’23), VeriFL (IEEE TIFS’20), and Flamingo (SP’23), all of which make similar assumptions. In our scheme, while we assume the servers are uncolluding, they are allowed to behave maliciously during aggregation. This design choice is supported by our scheme’s verifiability mechanism, which ensures that any malicious aggregation results can be detected. Furthermore, our scheme allows for up to $n-2$ colluding clients, which is a reasonable and sufficient level of security, even in environments where trust is limited.
2. $**Server Aggregation Verification**$. As outlined in our previous response, our scheme includes a verification mechanism to ensure the correctness of the server’s aggregation results. If an incorrect aggregation occurs, our system can detect the anomaly through this verification. To further incentivize accurate aggregation by the servers, future research could introduce mechanisms such as reputation scores, rewarding servers that perform correct aggregation. Additionally, we will revise the paper to correct the assumption of semi-honest servers, clarifying that servers can act maliciously, which is fully accounted for in our design.
3. $**SHC Instantiation and Explanation**$. To aid reader understanding, we provide an instantiation of Separable Homomorphic Commitments (SHC) in lines 245–289. We also offer a more detailed description of the SHC instantiation in lines 803–863. To improve the clarity of our explanation, we will revise the paper to include a more intuitive explanation of SHC and the other cryptographic concepts used in our scheme.

We greatly appreciate your feedback and will incorporate these clarifications in the revised version of the paper. Thank you again, and we look forward to your response.