Composable Privacy-Preserving Framework for Stakes-Based Online Peer-to-Peer Applications

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper introduces a hybrid back-end framework that combines the advantages of both models by leveraging cryptography algorithms and secure multi-party computation (MPC) protocols. The benchmark solution is lightweight and fully composable, enabling the use of different, more sophisticated plug-in MPC technologies. Although the proposed framework demonstrates its effectiveness with a simplified two-player game of spades, it is perfectly generalizable to any application scenario.

To further improve the quality of this paper, I advise the authors to incorporate the following comments.

1.The paper mentions that existing P2P solutions lack solutions for "stakes-based" scenarios, but similar studies have been conducted in the literature review. It is recommended to compare the differences between the solution in this article and the existing work more clearly, such as: Is there a significant improvement in efficiency, application scenarios, or security? Is the design of "Lazy Server" innovative? The resource savings need to be quantified.

2.The current discussion focuses on the benefits of the solution, suggesting additional limitations: for example, when the percentage of malicious users is extremely high (e.g., > 50%), an increase in server relay frequency can lead to an increase in network latency; the circuit complexity of GCs, the adaptability to large-scale applications, etc. The practical challenges of "VOPRF optimization" can be further explained, such as the hardware compatibility of elliptic curve encryption and the computational overhead of zero-knowledge proofs.

3.Although the concepts such as "lazy server" and "encrypted data block" mentioned in the article are described in text, they lack schematic diagrams. It is recommended to add architecture diagrams (such as the flowchart of P2P communication and server intervention in a hybrid architecture) and the schematic diagram of the encryption process combining GCs and OTP to help readers quickly understand the logic of technology combination. For example, in Section 2.3.3, "Encrypting Data Blocks", you can draw an interactive flowchart of OTP encryption and GC verification, and mark the key nodes of key generation, ciphertext transmission, and verification steps.

4. Some related works should be discussed, such as 10.1109/TCSVT.2022.3204753, 10.1109/TCSVT.2023.3278310, 10.1109/TCSVT.2024.3510355, 10.1109/TMM.2024.3415415

Author Response

We would like to sincerely thank the reviewer for their thoughtful and constructive feedback. We fully agree with all the comments provided, and we believe these suggestions have helped us significantly improve the quality and clarity of our paper.

In addition to addressing the technical feedback, we have conducted a thorough language review to improve the clarity and flow of the manuscript. This included careful revisions for grammar, syntax, and phrasing throughout the text.

In response to the reviewer’s points, we have made the following modifications:

Comment 1: The paper mentions that existing P2P solutions lack solutions for "stakes-based" scenarios, but similar studies have been conducted in the literature review. It is recommended to compare the differences between the solution in this article and the existing work more clearly, such as: Is there a significant improvement in efficiency, application scenarios, or security? Is the design of "Lazy Server" innovative? The resource savings need to be quantified.

Response 1: A dedicated subsection titled “Comparison with Related Work” (subsection 4.3) has been added to the Discussion section. It outlines the key differences between our approach and related work, highlighting improvements in security, efficiency, and applicability to stake-sensitive environments. We also clarify the novelty of the Lazy Server mechanism and provide an estimation of resource savings where applicable.

Added Text (subsection 1.1):

“We contrast our hybrid stakes-aware framework with the discussed state-of-the-art as well as additional research in P2P security. The analysis is split into three groups: 

Overlay–level defenses. Initial surveys and frameworks secure message routing, admission control or privacy but stop short of handling tangible stakes. The survey by Chopra et al. [6] catalogs reputation systems and encrypted signaling for VoIP overlays; Qureshi et al. [7] protect copyright in P2P content distribution through collusion-resistant fingerprinting; and Kumar et al. [8] propose a key-establishment layer for IoT peers. Follow-up work enhances trust by using SGX enclaves [9], ant-inspired reputation [10], or blockchain ledgers [11]. All these approaches improve communication security but do not resolve session-level fairness: if a peer cheats, honest users still lack an authoritative path to recover their stake. Our lazy-server fills that gap: it stays dormant during honest play yet becomes an online arbiter when misbehavior is detected, producing incontrovertible proofs that let the victim claim damages. 

Efficient cheat resolution. Time-cheat detection via game-time modeling [18], hybrid Voronoi/DHT overlays for load balancing [19], Lockstep and asynchronous playout protocols [20], and more recent WebRTC-based cryptographic engines [21] all thwart specific exploits (e.g. look-ahead or message reordering). However, none provide a general, composable mechanism to enforce penalties; most simply abort the match or rely on out-of- band moderation. Card-game systems such as Kaleidoscope [55] and Royale [56] do enforce deposits but hard-wire blockchain contracts, incurring continuous on-chain fees. Our framework attains comparable fairness while preserving pure P2P latency in the typical case by invoking heavy cryptography or trusted arbitration only on demand. 

Cryptographic fairness protocols. Fair-MPC with cheater detection [16] and identifiable-abort MPC [17] guarantee that a corrupted party cannot learn the output after deviating, yet the session ends in an abort that forfeits everyone’s effort. By contrast, our stakes-based design lets the honest peer finish the session (or obtain restitution) through the relay’s signed transcript, offering both cryptographic privacy and practical recourse. 

Relative to overlay defenses and cheat-specific engines, we supply the missing fairness layer for stake-centric applications; relative to abort-based MPC, we deliver an outcome without deadlock. The lazy-server’s trigger-on-dispute model keeps common-case overhead minimal (benchmarks show up-to-100 x CPU and bandwidth savings when cheaters are rare) while its OTP-based glue permits easy insertion of MPC sub-protocols for stricter privacy. These properties collectively advance the state of the art in secure, cost-efficient P2P back-ends.”

6. Chopra, D.; Schulzrinne, H.; Marocco, E.; Ivov, E. Peer-to-peer overlays for real-time communication: security issues and solutions. IEEE Communications Surveys & Tutorials 2009, 11, 4–12. https://doi.org/10.1109/SURV.2009.090102

7. Qureshi, A.; Megías, D.; Rifà-Pous, H. Framework for preserving security and privacy in peer-to-peer content distribution systems. Expert Systems with Applications 2015, 42, 1391–1408. https://doi.org/https://doi.org/10.1016/j.eswa.2014.08.053.

8. Vijaya Kumar, V.; Devi, M.; Vishnu Raja, P.; Kanmani, P.; Priya, V.; Sudhakar, S.; Sujatha, K. Design of peer-to-peer protocol with sensible and secure IoT communication for future internet architecture. Microprocessors and Microsystems 2020, 78, 103216.  https://doi.org/https://doi.org/10.1016/j.micpro.2020.103216

9. Jia, Y.; Tople, S.; Moataz, T.; Gong, D.; Saxena, P.; Liang, Z. Robust P2P Primitives Using SGX Enclaves. In Proceedings of the 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020); Egele, M.; Bilge, L., Eds., San Sebastián, Spain, 2020; pp. 209–224. 

10. Al-Otaiby, N.; Alhindi, A.; Kurdi, H. AntTrust: An Ant-Inspired Trust Management System for Peer-to-Peer Networks. Sensors 2022, 22, 533. https://doi.org/10.3390/s22020533

11. Ahmed, W.; Di, W.; Mukathe, D. Blockchain-Assisted Privacy-Preserving and Context-Aware Trust Management Framework for Secure Communications in VANETs. Sensors 2023, 23, 5766. https://doi.org/10.3390/s23125766

16. Seo, M. Fair and Secure Multi-Party Computation with Cheater Detection. Cryptography 2021, 5, 19. https://doi.org/10.3390/cryptography5030019

17. Baum, C.; Melissaris, N.; Rachuri, R.; Scholl, P. Cheater Identification on a Budget: MPC with Identifiable Abort from Pairwise MACs. In Proceedings of the Proceedings of CRYPTO 2024. Springer-Verlag, 2024. https://doi.org/10.1007/978-3-031-68397-8_14
18. Ferretti, S. Cheating detection through game time modeling: A better way to avoid time cheats in P2P MOGs? Multimedia Tools and Applications 2008, 37, 339–363. https://doi.org/10.1007/s11042-007-0163-2

19. Buyukkaya, E.; Abdallah, M.; Cavagna, R. VoroGame: A Hybrid P2P Architecture for Massively Multiplayer Games. In Proceedings of the 2009 6th IEEE Consumer Communications and Networking Conference, 2009. https://doi.org/10.1109/CCNC.2009.4784788

20. Baughman, N.E.; Liberatore, M.; Levine, B.N. Cheat-Proof Playout for Centralized and Peer-to-Peer Gaming. IEEE/ACM Transactions on Networking 2007, 15, 1–13. https://doi.org/10.1109/TNET.2006.886289

21. Han, H.; Sun, Y. A Cryptographically Secured Real-Time Peer-to-Peer Multiplayer Framework For Browser WebRTC. Computer Science & Information Technology (CS & IT) 2022, 12, 93–105. 

55. David, B.; Dowsley, R.; Larangeira, M. Kaleidoscope: An Efficient Poker Protocol with Payment Distribution and Penalty Enforcement. In Proceedings of the Financial Cryptography and Data Security (FC 2018), Revised Selected Papers. Springer, 2018, Vol. 10957, Lecture Notes in Computer Science, pp. 500–519. https://doi.org/10.1007/978-3-662-58387-6_33

56. David, B.; Dowsley, R.; Larangeira, M. ROYALE: A Framework for Universally Composable Card Games with Financial Rewards and Penalties Enforcement. In Proceedings of the Financial Cryptography and Data Security (FC 2019). Springer, 2019, Vol. 11598, Lecture Notes in Computer Science, pp. 282–300. https://doi.org/10.1007/978-3-030-32101-7_18

Comment 2: The current discussion focuses on the benefits of the solution, suggesting additional limitations: for example, when the percentage of malicious users is extremely high (e.g., > 50%), an increase in server relay frequency can lead to an increase in network latency; the circuit complexity of GCs, the adaptability to large-scale applications, etc. The practical challenges of "VOPRF optimization" can be further explained, such as the hardware compatibility of elliptic curve encryption and the computational overhead of zero-knowledge proofs.

Response 2: We have expanded the Methods and Materials section and revised the Conclusion to address limitations more clearly. These include potential issues with elliptic curve hardware compatibility, the computational cost of zk proofs, and scalability concerns such as latency under high adversarial participation and the complexity of garbled circuits.

Added Text (in subsection 2.1.2): “A practical limitation of this VOPRF optimization is its reliance on fast elliptic-curve arithmetic and Chaum–Pedersen DLEQ proofs. Hardware acceleration for the recommended curves (e.g., Ristretto255 or P-384) is inconsistent: many mobile SoCs expose constant-time multipliers only for P-256, while low-power IoT microcontrollers lack any dedicated support, forcing all group operations into slower, potentially side-channel-vulnerable software. The DLEQ proof roughly doubles the number of scalar multiplications per evaluation, one to blind, one to sign, and two to verify, so the client incurs several milliseconds of extra CPU time and a few kilobytes of transient RAM per key on commodity ARM cores. When hundreds of keys are pre-committed, this cost scales linearly and can dominate start-up latency and battery usage on devices without specialized cryptographic engines.”

Added Text (in section 5): “These results indicate that the efficiency of the proposed framework is proportional to the complexity of the application. Scenarios with larger amounts of private data and longer-lasting sessions achieve greater improvements with the hybrid back-end. Even in simpler cases, where some deterioration occurs, the impact is isolated to the initialization phase. We argue that this localized spike in resource usage is less critical than a sustained increase throughout the session. Furthermore, we propose an alternative VORPG setup for complete server detachment. This more complex scheme can be implemented if initialization becomes a bottleneck.”

Comment 3: Although the concepts such as "lazy server" and "encrypted data block" mentioned in the article are described in text, they lack schematic diagrams. It is recommended to add architecture diagrams (such as the flowchart of P2P communication and server intervention in a hybrid architecture) and the schematic diagram of the encryption process combining GCs and OTP to help readers quickly understand the logic of technology combination. For example, in Section 2.3.3, "Encrypting Data Blocks", you can draw an interactive flowchart of OTP encryption and GC verification, and mark the key nodes of key generation, ciphertext transmission, and verification steps.

Response 3: A new figure has been added (Figure 5) in subsection 2.3.5. “VOPRF Key Hashing” showcasing a basic flowchart of VOPR initialization. Additionally, some of the existing flowcharts have been modified to more clearly showcase the process. Specifically Figure 2 which gives a general overview of the algorithm has been updated to improve its clarity and Figure 6 (previously Figure 5) has also been upgraded.

Comment 4: Some related works should be discussed, such as 10.1109/TCSVT.2022.3204753, 10.1109/TCSVT.2023.3278310, 10.1109/TCSVT.2024.3510355, 10.1109/TMM.2024.3415415.

Response 4: We have incorporated two of the suggested references (10.1109/TCSVT.2022.3204753 and 10.1109/TCSVT.2023.3278310) into the State-of-the-Art subsection, particularly in relation to content-layer detection mechanisms for identifying malicious activity. These additions help provide further context for our proposed contributions.

Added Text (in subsection 1.1): “Beyond these safeguards, recent studies have proposed complementary detection mechanisms that flag malicious activity and network breaches at the content layer, further broadening the defense surface of centralized and decentralized systems [12,13].”

12. Chen, J.; Liao, X.; Wang, W.; Qian, Z.; Qin, Z.; Wang, Y. SNIS: A Signal Noise Separation-Based Network for Post-Processed Image Forgery Detection. IEEE Transactions on Circuits and Systems for Video Technology 2023, 33, 935–951. https://doi.org/10.1109/TCSVT.2022.3204753.

13. Liao, X.; Wang, Y.; Wang, T.; Hu, J.; Wu, X. FAMM: Facial Muscle Motions for Detecting Compressed Deepfake Videos Over Social Networks. IEEE Transactions on Circuits and Systems for Video Technology 2023, 33, 7236–7251. https://doi.org/10.1109/TCSVT.2023.3278310.

Reviewer 2 Report

Comments and Suggestions for Authors

This paper presents a hybrid privacy-preserving framework for stakes-based P2P applications, combining cryptographic techniques and a lazy server to handle disputes. It ensures fairness and security with minimal overhead, demonstrated through a Spades game case study. There are several issues in this paper that should be clarified and addressed:

1、While the paper presents a promising hybrid P2P framework combining cryptographic techniques and secure multi-party computation protocols for stakes-based applications, one important aspect that requires clarification is the security model assumed throughout the work. The current manuscript discusses several security primitives (e.g., OTP, VOPRF, Garbled Circuits, FSS) and outlines their integration in specific scenarios; however, it does not clearly define the overall security assumptions and threat model adopted by the framework prior to the algorithmic descriptions. Specifically, it remains unclear whether the proposed system assumes a semi-honest (honest-but-curious) or fully malicious adversarial model in its baseline implementation, and to what extent the current protocol variants can resist active attacks such as message forgery, replay, data tampering, or denial-of-service within the P2P environment. I recommend that the authors explicitly introduce and formalize the security model in a dedicated subsection within the Introduction or before Section 2.

2、The proposed framework effectively prevents continued malicious behavior once the Relay Fallback mechanism is triggered. However, it does not address cases where an adversarial player strategically stops cheating upon entering relay mode, thereby avoiding detection and consequences. Since the system currently lacks retroactive auditing of prior P2P interactions and does not penalize frequent relay triggers themselves, a malicious user could exploit this by intermittently cheating and halting when challenged. I suggest the authors consider extending their framework to account for this type of strategic adversary, perhaps by incorporating relay trigger frequency tracking, reputation scoring, or probabilistic auditing mechanisms to discourage such behavior and better enforce fairness over time.

Author Response

We appreciate the reviewer’s careful analysis and constructive remarks. The points raised have provided valuable guidance in clarifying and strengthening the presentation and technical depth of our manuscript. In response to the reviewer’s points, we have made the following modifications:

Comment 1: While the paper presents a promising hybrid P2P framework combining cryptographic techniques and secure multi-party computation protocols for stakes-based applications, one important aspect that requires clarification is the security model assumed throughout the work. The current manuscript discusses several security primitives (e.g., OTP, VOPRF, Garbled Circuits, FSS) and outlines their integration in specific scenarios; however, it does not clearly define the overall security assumptions and threat model adopted by the framework prior to the algorithmic descriptions. Specifically, it remains unclear whether the proposed system assumes a semi-honest (honest-but-curious) or fully malicious adversarial model in its baseline implementation, and to what extent the current protocol variants can resist active attacks such as message forgery, replay, data tampering, or denial-of-service within the P2P environment. I recommend that the authors explicitly introduce and formalize the security model in a dedicated subsection within the Introduction or before Section 2.

Response 1: A new subsection titled “Security Model and Threat Analysis” (subection 2.4) has been added at the end of Section 2. This subsection defines the assumed adversarial model (including both semi-honest and malicious actors), outlines the primary security goals of the system, and provides an analysis of how the proposed framework mitigates various attack vectors.

Added Text (subsection 2.4): 

“To complete Section 2 we state the exact assumptions under which our hybrid framework is secure and explain how the protocol is compiled from a semi–honest design into a maliciously secure one with identifiable abort, as long as the dormant lazy relay behaves honestly.

Each session involves two peers A and B who exchange messages through a fully adversarial network and, when necessary, interact with a third party S that stores pre-commitments and relays traffic after a timeout. The adversary controls scheduling, can delay or drop packets, and may statically corrupt one of the peers. Baseline analysis is performed in the universally-composable (UC) semi–honest model, where a corrupted party follows the code but inspects the entire transcript.

Malicious behavior is detected by binding every secret input to a session-unique tag before any computation starts; when the real value is later revealed, an honest verifier checks that it matches the original tag, and any mismatch exposes the cheater with probability 1-2^(-\lambda).  Two alternative binding channels are implemented and exactly one is chosen per deployment. Either variant suffices to lift the whole protocol to the malicious model:

Hash pre-commitment: the relay sends each opponent a single Merkle-style digest h = H( c_0 || c_1 || c_2 \dots || h_{k0} || h_{k1} || h_{k2} \dots) that covers every ciphertext and every key hash. Verification is purely deterministic hashing.

VOPRF pre-commitment: the relay holds a static secret key k_(OPRF) and returns to each player a blinded evaluation F_k(x\Vert i) together with a Chaum–Pedersen proof. The resulting tag is a keyed hash that can only be reproduced with the same key, giving sound binding and zero-knowledge privacy.

Above the tag layer, every message is encrypted under an XOR one-time pad, so any two-party primitive that outputs authenticated additive shares can be slotted in without additional cryptographic glue. Typical choices are Free-XOR/half-gate garbled circuits hardened by modern cut-and-choose schedules; IKNP or Ferret OT extension with correlation checks; and two-party function-secret-sharing for comparisons. Each primitive has a known compilation path to malicious security with constant-factor overhead, hence the framework inherits privacy, correctness, and fairness in the strong adversarial setting.

All security arguments presented above implicitly require the relay to behave with perfect honesty. The server chooses the per-player seeds s_a, s_b that expand into every ciphertext, one-time-pad key and Merkle/VOPRF tag; it also stores the sole authoritative copy of those tags and, once a fallback is triggered, mediates every subsequent message. If the relay deviates from the prescribed code or secretly colludes with a corrupted peer, both the semi-honest and malicious guarantees collapse entirely. A cheating server can inject biased seeds that allow it (or its confederate) to reconstruct private inputs, swap the public hash or substitute a fresh VOPRF secret key so that forged data looks legitimate, and finally reorder, drop, or fabricate relay traffic so that the observable transcript matches any outcome it wishes. In such a scenario confidentiality, integrity, fairness and non-repudiation all fail: the server can learn, publicize, or arbitrarily alter user inputs and session results, while honest players lack any cryptographic evidence to prove misconduct.

Under the hardness of discrete logarithms in the chosen elliptic-curve group, the collision resistance of the hash, and the secrecy of the XOR one-time pad, the protocol UC-realises the ideal stakes-based two-party functionality: (i) a coalition of one corrupted peer plus the network learns nothing beyond its prescribed output; (ii) honest peers either agree on the same deterministic result or obtain a cryptographic proof that identifies a cheater; and (iii) the construction remains secure when several instances run concurrently.”

Comment 2: The proposed framework effectively prevents continued malicious behavior once the Relay Fallback mechanism is triggered. However, it does not address cases where an adversarial player strategically stops cheating upon entering relay mode, thereby avoiding detection and consequences. Since the system currently lacks retroactive auditing of prior P2P interactions and does not penalize frequent relay triggers themselves, a malicious user could exploit this by intermittently cheating and halting when challenged. I suggest the authors consider extending their framework to account for this type of strategic adversary, perhaps by incorporating relay trigger frequency tracking, reputation scoring, or probabilistic auditing mechanisms to discourage such behavior and better enforce fairness over time.

Response 2: We have added a new subsection at the end of the Discussion section titled “Mitigating Strategic Relay Abuse” (subection 4.2). This section discusses potential mechanisms to counteract the behavior of strategic adversaries, including suggestions such as a trigger frequency ledger, reputation staking, and probabilistic post-mortems that discourage repeated exploitation of fallback transitions.

Added Text (subsection 4.2): 

“Although entering relay mode prevents further deviations, the very first cheating attempt inside an optimistic P2P phase leaves no cryptographic proof for the server to punish the instigator. A determined attacker could therefore mount a “single-probe” strategy: try a speculative deviation once per session, and, if challenged, immediately behave honestly under the relay. While the attempt itself always fails, it still wastes time, leaks side–channel information about edge cases, and consumes relay resources if repeated across many sessions.

A natural extension is to layer a meta-protocol that deters abusive relay triggers without altering the core cryptographic flow:

• Trigger frequency ledger. The relay already authenticates users and can therefore maintain a per-identity counter of how often a session escalates. Thresholds may map to exponential back-off, higher escrow requirements, or temporary blacklisting, echoing reputation schemes in decentralized networks [53].

• Reputation staking. Each account locks a small stake that is slashed if its relay-trigger rate exceeds a moving average. Honest users rarely pay, whereas serial abusers face an ever-growing cost.
• Probabilistic post-mortems. On a randomly chosen fraction of relay activations, the server demands the last k P2P messages together with their one-time-pad keys (which the honest party can safely reveal after escalation). A cheater caught by this spot audit forfeits a larger penalty; the probability can be tuned so that the expected loss outweighs any putative gain from probing, conceptually similar to [54].

Because these defenses operate above the existing protocol, they require only minor changes to the relay’s bookkeeping and no extra cryptographic assumptions. Future work will quantify the optimal audit probability and stake schedule that minimizes false positives while strongly discouraging strategic relay abuse.”

53. Kamvar, S.D.; Schlosser, M.T.; Garcia-Molina, H. The Eigentrust algorithm for reputation management in P2P networks. In Proceedings of the Proceedings of the 12th International Conference on World Wide Web, New York, NY, USA, 2003; p. 640–651.  https://doi.org/10.1145/775152.775242

54. Cunningham, R.; Fuller, B.; Yakoubov, S. Catching MPC Cheaters: Identification and Openability. In Proceedings of the Information Theoretic Security: 10th International Conference, ICITS 2017, Hong Kong, China, November 29 – December 2, 2017, Proceedings, Berlin, Heidelberg, 2017; p. 110–134. https://doi.org/10.1007/978-3-319-72089-0_7

Reviewer 3 Report

Comments and Suggestions for Authors

This manuscript proposes a composable, privacy-preserving hybrid backend framework designed for online peer-to-peer (P2P) applications involving stake-based interactions. Using online games as a motivating example, the authors introduce a system that combines a “lazy” server with lightweight cryptographic primitives and secure multi-party computation techniques. The framework systematically addresses key challenges in pure P2P architectures, including the lack of trusted arbitration, privacy leakage, and false accusations. Experimental results demonstrate performance benefits across various usage scenarios.

While the manuscript is generally well-structured and the proposed methodology forward-looking, several issues remain that should be addressed:

1. Although the paper references various security techniques, it lacks a unified security model and formal analysis. In particular, the trust assumptions around the lazy server and the security boundaries of the relay fallback mode are not clearly defined. I suggest adding a dedicated section on threat modeling and security analysis, discussing the framework’s guarantees under both semi-honest and malicious adversary models.

2. The manuscript emphasizes the composability of the framework but does not specify how it interfaces with existing MPC systems such as SPDZ, EMP, or ABY. It would be helpful to include example integrations or interface guidelines that clarify the slot-in requirements and compatibility layers for such systems.

3. The experiments are based on emulation using a single-threaded CPU, and do not evaluate the system’s behavior under real network conditions—such as latency, packet loss, or user churn. Additionally, the case studies focus on a simplified two-player game, without testing more complex P2P scenarios like multi-party coordination or large-scale collaborative applications. Expanding the experimental section to cover these dimensions would significantly strengthen the work.

Author Response

We thank the reviewer for their insightful feedback and valuable suggestions. These comments have helped us further refine the manuscript, and we have made several targeted revisions to address the points raised. In response to the reviewer’s points, we have made the following modifications:

Comment 1: Although the paper references various security techniques, it lacks a unified security model and formal analysis. In particular, the trust assumptions around the lazy server and the security boundaries of the relay fallback mode are not clearly defined. I suggest adding a dedicated section on threat modeling and security analysis, discussing the framework’s guarantees under both semi-honest and malicious adversary models.

Response 1: A new subsection titled “Security Model and Threat Analysis” (subection 2.4) has been added at the end of Section 2. This subsection defines the assumed adversarial model (including both semi-honest and malicious actors), outlines the primary security goals of the system, and provides an analysis of how the proposed framework mitigates various attack vectors.

Added Text (subsection 2.4): 

“To complete Section 2 we state the exact assumptions under which our hybrid framework is secure and explain how the protocol is compiled from a semi–honest design into a maliciously secure one with identifiable abort, as long as the dormant lazy relay behaves honestly.

Each session involves two peers A and B who exchange messages through a fully adversarial network and, when necessary, interact with a third party S that stores pre-commitments and relays traffic after a timeout. The adversary controls scheduling, can delay or drop packets, and may statically corrupt one of the peers. Baseline analysis is performed in the universally-composable (UC) semi–honest model, where a corrupted party follows the code but inspects the entire transcript.

Malicious behavior is detected by binding every secret input to a session-unique tag before any computation starts; when the real value is later revealed, an honest verifier checks that it matches the original tag, and any mismatch exposes the cheater with probability 1-2^(-\lambda).  Two alternative binding channels are implemented and exactly one is chosen per deployment. Either variant suffices to lift the whole protocol to the malicious model:

Hash pre-commitment: the relay sends each opponent a single Merkle-style digest h = H( c_0 || c_1 || c_2 \dots || h_{k0} || h_{k1} || h_{k2} \dots) that covers every ciphertext and every key hash. Verification is purely deterministic hashing.

VOPRF pre-commitment: the relay holds a static secret key k_(OPRF) and returns to each player a blinded evaluation F_k(x\Vert i) together with a Chaum–Pedersen proof. The resulting tag is a keyed hash that can only be reproduced with the same key, giving sound binding and zero-knowledge privacy.

Above the tag layer, every message is encrypted under an XOR one-time pad, so any two-party primitive that outputs authenticated additive shares can be slotted in without additional cryptographic glue. Typical choices are Free-XOR/half-gate garbled circuits hardened by modern cut-and-choose schedules; IKNP or Ferret OT extension with correlation checks; and two-party function-secret-sharing for comparisons. Each primitive has a known compilation path to malicious security with constant-factor overhead, hence the framework inherits privacy, correctness, and fairness in the strong adversarial setting.

All security arguments presented above implicitly require the relay to behave with perfect honesty. The server chooses the per-player seeds s_a, s_b that expand into every ciphertext, one-time-pad key and Merkle/VOPRF tag; it also stores the sole authoritative copy of those tags and, once a fallback is triggered, mediates every subsequent message. If the relay deviates from the prescribed code or secretly colludes with a corrupted peer, both the semi-honest and malicious guarantees collapse entirely. A cheating server can inject biased seeds that allow it (or its confederate) to reconstruct private inputs, swap the public hash or substitute a fresh VOPRF secret key so that forged data looks legitimate, and finally reorder, drop, or fabricate relay traffic so that the observable transcript matches any outcome it wishes. In such a scenario confidentiality, integrity, fairness and non-repudiation all fail: the server can learn, publicize, or arbitrarily alter user inputs and session results, while honest players lack any cryptographic evidence to prove misconduct.

Under the hardness of discrete logarithms in the chosen elliptic-curve group, the collision resistance of the hash, and the secrecy of the XOR one-time pad, the protocol UC-realises the ideal stakes-based two-party functionality: (i) a coalition of one corrupted peer plus the network learns nothing beyond its prescribed output; (ii) honest peers either agree on the same deterministic result or obtain a cryptographic proof that identifies a cheater; and (iii) the construction remains secure when several instances run concurrently.”

Comment 2: The manuscript emphasizes the composability of the framework but does not specify how it interfaces with existing MPC systems such as SPDZ, EMP, or ABY. It would be helpful to include example integrations or interface guidelines that clarify the slot-in requirements and compatibility layers for such systems.

Response 2: We have expanded the Privacy-Preserving Processor subsection (2.3.6) to include a dedicated explanation of how the framework interfaces with existing MPC systems, including SPDZ, EMP, and ABY. This addition highlights the minimal integration overhead required and the compatibility mechanisms that make composability with these frameworks straightforward. Additionally, we have included several mentions throughout the text to emphasize support for these established platforms.

Added Text (in subsection 2.3.6):  “To finalize this subsection, some speculation is provided on the compatibility of our slotabble solution with existing well-established MPC frameworks. As stated, every intermediate word in the protocol is protected by an XOR OTP, so a value can be exported from the processor and imported into an external MPC engine with a single XOR operation. This constant-time glue layer lets the processor embed directly inside widely used tool chains such as SPDZ, EMP-toolkit, and ABY—without modifying their internals.

SPDZ [47]. Values under the OTP are interpreted as field elements mod p. On entry to SPDZ, the global session MAC key is added once; on exit, the value is re-masked with the OTP. The standard SPDZ workflow regarding offline triple generation, online computation, and reveal, runs unchanged. Like future research, the same solution can be implemented with additive OTP, reducing external computation even further.

EMP-toolkit [48]. EMP already works in the XOR domain. The OTP key can be treated directly as the garbled-wire mask bit vector, so no conversion is required: pass the ciphertext as a garbled label, evaluate the circuit, then XOR with the same key before transmission.

ABY [49]. For Boolean shares, the procedure is identical to EMP. For arithmetic shares, the same trick as SPDZ applies. For Yao shares, the OTP mask can serve as the global offset Delta. ABY's built-in converters allow seamless switching between share types while the OTP remains the outer envelope. Once more, future work can examine an additive OTP for additional speedup.

The XOR-OTP layer remains advantageous: it adds only a single XOR for masking or unmasking, regardless of field size or circuit width, so no extra cryptography is incurred; the same OTP uniformly protects Boolean and arithmetic data, simplifying auditing and fallback logic.”

47. Damgård, I.; Pastro, V.; Smart, N.; Zakarias, S. Multiparty Computation from Somewhat Homomorphic Encryption. In Proceedings of the Advances in Cryptology – CRYPTO 2012, Berlin, Heidelberg, 2012; pp. 643–662. 

48. Wang, X.; Malozemoff, A.J.; Katz, J. EMP-toolkit: Efficient Multi-Party Computation Toolkit. https://github.com/emp-toolkit

49. Demmler, D.; Schneider, T.; Zohner, M. ABY: A Framework for Efficient Mixed-Protocol Secure Two-Party Computation. In Proceedings of the 22nd NDSS Symposium 2015. Internet Society, 2015, pp. 1–18. https://doi.org/10.14722/ndss.2015.23113

Comment 3: The experiments are based on emulation using a single-threaded CPU, and do not evaluate the system’s behavior under real network conditions—such as latency, packet loss, or user churn. Additionally, the case studies focus on a simplified two-player game, without testing more complex P2P scenarios like multi-party coordination or large-scale collaborative applications. Expanding the experimental section to cover these dimensions would significantly strengthen the work.

Response 3: A new paragraph has been added to the Discussion section addressing the limitations of our current experimental setup, including the use of a single-threaded environment and the absence of real-world networking factors such as latency and churn. We acknowledge that these are important considerations and clarify that while they are beyond the present paper’s scope, they will be a focus of future work aimed at evaluating the system under more realistic and large-scale deployment conditions.

Added Text (in section 4): “... our current experiments use a single-threaded CPU emulator that runs all parties on one machine. This choice simplifies instrumentation but omits key practical aftereffects such as network latency, packet loss, and user churn, and it restricts the evaluation to a two-player scenario.  As a result, we do not yet measure real-world overhead or potential advantages of parallel message processing and concurrent MPC engines. Future work will deploy the framework on a distributed testbed with variable RTTs and fault injection, extend the case studies to n-player coordination tasks, and enable true multi-threaded execution so that parties can overlap cryptographic work with network I/O. Such experiments will expose scalability bottlenecks and allow us to quantify how far parallel code paths, both within an MPC engine and across independent engines running simultaneously, can hide individual cryptographic latencies.”

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors have successfully addressed my major concerns. I recommend accepting this manuscript.

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have adequately addressed the concerns I raised in the previous round of review. The revisions improve the clarity and completeness of the paper. I am satisfied with the current version and recommend acceptance of this work.