Preprints

Peer-reviewed published articles

1. Dejaeghere, J., Goffaux, L., Luycx, P., Elkoulak, H., & Rochet, F. (2026, November). Sociotechnical Aspects of Tor Relay Rejection. Proceedings of the 25th Workshop on Privacy in the Electronic Society (WPES ’26).
   PDF DOI BIB ABSTRACT

   @inproceedings{relay_rejection,
     author = {Dejaeghere, Jules and Goffaux, Lionel and Luycx, Pierre and Elkoulak, Hosam and Rochet, Florentin},
     title = {{Sociotechnical Aspects of Tor Relay Rejection}},
     year = {2026},
     month = nov,
     publisher = {Association for Computing Machinery},
     address = {New York, NY, USA},
     doi = {10.1145/3847192.3847370},
     booktitle = {Proceedings of the 25th Workshop on Privacy in the Electronic Society (WPES '26)},
     keywords = {Tor; Software release life cycle; Anonymity; Tor relay; Internet exchange point (IXP); Autonomous system (AS)},
     location = {The Hague, Netherlands},
     series = {WPES '26},
     file = {relay_rejection.pdf}
   }
   

   In 2019, the Tor Project enforced an end-of-life (EoL) policy for Tor versions, leading to the rejection of outdated relays, amounting to a notable fraction of consensus weight. While this policy aids network maintenance, reduces backporting efforts, and shortens vulnerability exposure, its sociotechnical implications remain unstudied.
   A user study (N=26) reveals that relay operators, though not universally aware of the EoL policy, generally view it favorably. Operational practices vary, occasionally excluding newly installed relays from the network.
   Network simulations, grounded in historical data, assess the policy’s immediate impact on Tor clients against common adversaries. Results indicate a marginal adversarial advantage, with network churn (i.e., relays entering and exiting) exerting a more pronounced effect on user anonymity. Security metrics are introduced to evaluate relay contributions against two adversary models, enabling ranking by individual utility and security. Analysis of four exclusion rounds shows that a minority of rejected relays typically account for over 50% of the security provided by all excluded relays.
   Recommendations for EoL policy implementation are proposed to mitigate potential drawbacks. 

2. Rochet, F. (2026). Contiguous Zero-Copy for Encrypted Transport Protocols. SIGCOMM Computer Communication Review, 55(3), 2–18.
   PDF DOI BIB ABSTRACT

   @inproceedings{reverso,
     author = {Rochet, Florentin},
     title = {Contiguous Zero-Copy for Encrypted Transport Protocols},
     year = {2026},
     month = jan,
     issue_date = {July 2025},
     publisher = {Association for Computing Machinery},
     address = {New York, NY, USA},
     volume = {55},
     number = {3},
     issn = {0146-4833},
     doi = {10.1145/3787927.3787929},
     journal = {SIGCOMM Computer Communication Review},
     pages = {2–18},
     numpages = {17},
     keywords = {security and privacy, network security, security protocols},
     file = {reverso.pdf}
   }
   

   We propose in this paper to revisit the design of existing encrypted transport protocols to improve their efficiency. We call the methodology ’Reverso’ from reversing the order of field elements within a protocol specification. We detail how such a benign-looking change within the specifications may unlock contiguous zero-copy for encrypted protocols during data transport. To demonstrate our findings, we release quiceh, a QUIC implementation of QUIC VReverso, an extension of the QUIC V1 standard (RFC9000). Our methodology applied to the QUIC protocol reports ≈ 30% of CPU efficiency improvement for processing packets at no added cost on the sender side and without relaxing any security guarantee from QUIC V1. We also implement a fork of Cloudflare’s HTTP/3 module and client/server demonstrator using quiceh and show our optimizations to directly transfer to HTTP/3 as well, resulting in our new HTTP/3 to be ≈ 38% more efficient than the baseline implementation using QUIC V1. We argue that Reverso applies to any modern encrypted protocol and its implementations and that similar efficiency improvement can also be unlocked for them, independently of the layer in which they operate. Indeed, this research shows that the ability to implement contiguous zero-copy on the receiver side inherently depends on the specified encrypted protocol wire image, and that we may need to reverse how we are used to write them.

3. Rochet, F., Dejaeghere, J., & Elahi, T. (2024). Towards Flexible Anonymous Networks. Proceedings of the 23rd Workshop on Privacy in the Electronic Society (WPES ’24).
   PDF DOI BIB ABSTRACT

   @inproceedings{fan,
     title = {Towards Flexible Anonymous Networks},
     keywords = {Tor, Anonymous Communications, Software Design},
     author = {Rochet, Florentin and Dejaeghere, Jules and Elahi, Tariq},
     year = {2024},
     doi = {10.1145/3689943.3695038},
     language = {English},
     series = {Proceedings of the 23rd Workshop on Privacy in the Electronic Society},
     publisher = {ACM Press},
     booktitle = {Proceedings of the 23rd Workshop on Privacy in the Electronic Society (WPES '24)},
     address = {United States},
     file = {fan.pdf}
   }
   

   Anonymous Communication designs such as Tor build their security on distributed trust over many volunteers running relays in diverse global locations. In practice, this distribution leads to a heterogeneous network in which many versions of the Tor software co-exist, each with differing sets of protocol features. Because of this heterogeneity, Tor developers employ forward-compatible protocol design as a strategy to maintain network extensibility. This strategy aims to guarantee that different versions of the Tor software interact without unrecoverable errors. In this work, we cast protocol tolerance that is enabled by forward-compatible protocol considerations as a fundamental security issue. We argue that, while being beneficial for the developers, protocol tolerance has resulted in a number of strong attacks against Tor in the past fifteen years.To address this issue, we propose Flexible Anonymous Network (FAN), a new software architecture for volunteer-based distributed networks that shifts the dependence away from protocol tolerance without losing the ability for developers to ensure the continuous evolution of their software. We i) instantiate an implementation, ii) evaluate its overheads and, iii) experiment with several of FAN’s benefits to defend against a severe attack still applicable to Tor today.

4. Dejaeghere, J., Gbadamosi, B., Pulls, T., & Rochet, F. (2023). Comparing Security in eBPF and WebAssembly. Proceedings of the 1st Workshop on EBPF and Kernel Extensions, 35–41.
   PDF DOI BIB ABSTRACT

   @inproceedings{ebpf_wasm,
     author = {Dejaeghere, Jules and Gbadamosi, Bolaji and Pulls, Tobias and Rochet, Florentin},
     title = {Comparing Security in eBPF and WebAssembly},
     year = {2023},
     isbn = {9798400702938},
     publisher = {Association for Computing Machinery},
     address = {New York, NY, USA},
     doi = {10.1145/3609021.3609306},
     booktitle = {Proceedings of the 1st Workshop on EBPF and Kernel Extensions},
     pages = {35–41},
     numpages = {7},
     keywords = {side-channels, API access, control flow integrity, memory safety, threat model, security comparison, webassembly, eBPF},
     location = {New York, NY, USA},
     series = {eBPF '23},
     file = {ebpf_wasm.pdf}
   }
   

   This paper examines the security of eBPF and WebAssembly (Wasm), two technologies that have gained widespread adoption in recent years, despite being designed for very different use cases and environments. While eBPF is a technology primarily used within operating system kernels such as Linux, Wasm is a binary instruction format designed for a stack-based virtual machine with use cases extending beyond the web. Recognizing the growth and expanding ambitions of eBPF, Wasm may provide instructive insights, given its design around securely executing arbitrary untrusted programs in complex and hostile environments such as web browsers and clouds. We analyze the security goals, community evolution, memory models, and execution models of both technologies, and conduct a comparative security assessment, exploring memory safety, control flow integrity, API access, and side-channels. Our results show that eBPF has a history of focusing on performance first and security second, while Wasm puts more emphasis on security at the cost of some runtime overheads. Considering language-based restrictions for eBPF and a security model for API access are fruitful directions for future work.